Checking the following code with Pyright:
from typing import Union, TypeVar
T = TypeVar('T')
X_or_RecurListOf = Union[T, list['X_or_RecurListOf']]
x: X_or_RecurListOf[str] = ['asd']
produces the error:
5:28 - error: Expression of type "list[str]" cannot be assigned to declared type "X_or_RecurListOf[str]"
Type "list[str]" cannot be assigned to type "X_or_RecurListOf[str]"
"list[str]" is incompatible with "str"
TypeVar "_T#list" is invariant
Type "str" cannot be assigned to type "X_or_RecurListOf[Type[T#X_or_RecurListOf]]"
Type "str" cannot be assigned to type "T#X_or_RecurListOf"
"str" is incompatible with "list[X_or_RecurListOf]" (reportGeneralTypeIssues)
1 error, 0 warnings, 0 infos
Completed in 0.677sec
Am I doing something wrong?
Or have I misunderstood the announcement for support of recursive types in Pyright?
Oh, I've found what Pyright stumbles over!
It wants to have the type parameter in the recursive definition:
X_or_RecurListOf = Union[T, list['X_or_RecurListOf[T]']] - pay attention to the [T]!
I don't see why this is necessary but it works for me, especially as I really meant X_or_RecurListOf[T] and not X_or_RecurListOf[Any].
Related
I'm confused because when I define a type from 1 to maxint in Pascal and I make the choice "0" which should return back to the repeat loop. Here is my code:
program Tanken;
type
tZahl = 1..maxint;
var
tag1 : tZahl;
wahl : tZahl;
liter,
p : real;
BEGIN
repeat
write ('Bitte Tag eingeben 1=Mon 2=Die 3=Mit 4=Don 5=Fre 6=Sam 7=Son: ');
readln (tag1);
writeln(tag1);
until tag1 <= 7;
....
end
This is how my constant, type and variable looks. Si I define tag1 as tZahl which should be from 1 to maxint but how ever when I run this at the first repeat loop when I type "0" it is accepted. I found this a bit confusing any ideas?
To force type range checking at runtime you need to explicitly tell the compiler to with most used compilers by adding {$R+} to the top of the program.
However this will only throw a runtime error, which is not the input validation that you want. You will really need to program input validation yourself. E.g. by reading a string, and then converting it to a number using the VAL() procedure and checking the code argument for errors.
I was making a simple maths calculator in kotlin, an error appeared on my screen when I tried to initialize the value of one of the variables used as 0.00 for float integer.
var x:Float= readLine()!!.toFloat()
var y:Float= readLine()!!.toFloat()
var sum:Float=0.00// the error message is showcased in this line
sum=x+y
println("Addition " + sum)
This is a key difference between Java and Kotlin. Kotlin does not do numeric type promotion like Java does. The comments to your question are showing you how to deal with this, by either matching up the two types Double and/or Float to begin with, or by explicitly converting one or the other so that the two types match up.
Your problems goes away if you make use of Kotlin's ability to infer variable types by taking the type specifications off of your variable definitions. The fact that Kotlin infers types is one reason it does not promote numeric types. Mixing the two would lead to a lot of confusion.
Here's an example of how to fix and simplify your code's type mismatch issues using type inference:
var x = readLine()!!.toFloat()
var y = readLine()!!.toFloat()
var sum = x + y
println("Addition " + sum)
I understand that this may be just test code that you're using to understand Kotlin better. With that said, I'll point out that this code will crash if your user types in non-numeric input. You could fix this by putting a try/catch around your input lines, and providing an nice error message. You might want to put each input in a loop, continuing to ask for an input until the user does provide a response that is of the expected format.
So when I try to compile (activate), the compiler throws this error message:
Different number of parameters in FORM and PERFORM (routine:
CALL_CALCULATE_TAX_ITEM, number of formal parameters: 7, number of
actual parameters: 6)
It refers to the line 169 in the include LJ_1B_NFE_INF3B, where there is this statement:
PERFORM call_calculate_tax_item
USING
ls_rbkpv
ls_drseg
ls_j_lbaa
ls_lfa1
ls_xmlpo
abap_true
CHANGING
et_bapiret2[].
Here is the form code:
FORM call_calculate_tax_item
USING ls_rbkpv TYPE mrm_rbkpv
ls_drseg TYPE mmcr_drseg
ls_j_1baa TYPE j_1baa
ls_lfa1 TYPE lfa1
ls_xmlpo TYPE ty_xmlpo_ext "1843823
lv_get_conditions TYPE flag "2142110
CHANGING et_bapiret2 TYPE bapirettab.
So, it's obvious that there are 7 parameters both in PERFORM and FORM, why does the compiler say that there are only 6 actual parameters?
Thanks and sorry for broken English.
Usually such problems result from a not fully implemented SAP Note or not activating all the changes made by the note at the very same time.
In your case I see that either SAP Note 2142110 is not fully implemented or some of the changes resulting from the implementation of it have not been activated.
Here is one for you.
Why does the following piece of code not end with a short dump GETWA_NOT_ASSIGNED and instead return type C with length 2?
FIELD-SYMBOLS: <fs_any> TYPE any.
DESCRIBE FIELD <fs_any>
TYPE DATA(l_type)
LENGTH DATA(l_length) IN BYTE MODE
DECIMALS DATA(l_decimals).
I could not find anything in the ABAP documentation about this behaviour.
EDIT:
It looks like the short dump is never to be expected. I tried it also with
FIELD-SYMBOLS: <fs_any> TYPE i.
and
FIELD-SYMBOLS: <fs_any> TYPE but000.
so vwegert's answer looks to be plausible, because declaring a variable without any type like that DATA: var. defaults it to c with length 1.
Personal opinion, not backed by documentation either: Since DATA foo. will create a variable of TYPE C LENGTH 1 implicitly, this is what DESCRIBE FIELD does return in this case. You're probably on a Unicode system - on my system, it returns length 1. I'd say you've triggered some undocumented behavior, maybe even a bug. I'd strongly suggest NOT to rely on this - I suppose it might be changed at any time.
Why does this fail:
<CFIF isdefined("URL.3dfile")>...</CFIF>
with following message:
Parameter 1 of function IsDefined, which is now URL.3dfile, must be a syntactically valid variable name.
and this won't:
<CFIF structkeyexists(URL,"3dfile")>...</CFIF>
Is the way it get's parsed not much the same? And .. are variables starting with numbers invalid or aren't they?
Seybsen - variables names should not begin with a number. This is likely a legacy of older non-java version of CF Where a variable was not part of an object.
However, in the java world everything IS an object. This leads to a syntactical nuance. If you are using variable names in dotted notation your var name will likely throw an error. But use it in other ways and it will succeed.
So this sort of syntax works
url['33foo']
But setting a variable name directly - 33foo = true - will not work.
Here's a post with a full explanation.
http://www.coldfusionmuse.com/index.cfm/2005/9/8/isdefined%20vs%20structkeyexists