But since the for variable is really just a regular variable in the
same scope as whatever contains the for loop, Python programs are free
to make use of that fact. What do you propose for the following:
a=[1,2,3]
b=['ab','cd']
for i in a:
print i
print i # global integer
for i in b:
print i
print i # global string
i = 'ef'
I think it will be tough. I would guess there are plenty of cases I
haven't considered. But, if you can somehow manage to ensure that the
for variables are really only being used inside the loop, and accept
only those cases, then I think most ShedSkin users would welcome that
capability.
John
You could, instead of tracking integers like that, just make the
variables type-based:
int int_i;
char * char_ptr_i;
That way, any collisions are automatically ignored.
However, this should be a separate flag since it can cause unwanted
behavior. In many cases, I set, as a default, a variable to None. Then
later, I set it to whatever I get out of a dict or list, which sometimes
means an integer. If I'm not writing it for shedskin use at the time, I
won't hit a problem since None is 'falsey'. But when I later push it to
shedskin, None isn't an integer type but is null or '\0', causing type
collisions with an integer later. This is an actual problem that I
should fix by using 0 or -1, using two separate variables will just
cause huge errors when I use the char* version of the variable for
testing but assign to the int version since that comes later.
Will asked for warnings, that's one that I've run into basically every
time I moved from Python to shedskin as an afterthought to the code.
Though I do see the benefit, after all, I'm the creator of issue id 98 :)
--Fahrzin Hemmati
Perhaps. Issue 144 was specifically about loop variables, though. Of
course I trust Mark to merge issues he thinks are related, as he is
the most familiar with how things are implemented in ShedSkin. But in
my opinion, the situation described in issue 98 is more general and
more tricky to handle well than issue 144 (and its duplicate, 151).
So many people use a throwaway variable in for loops that it seems
like it would be easier to recognize this particular use case and make
a mechanism just for it.
John
Well, the point of ShedSkin is to do what Python does, as much as
possible, so in this case, m is local to func, and this is therefore
an UnboundLocalError.
> m = 0 <--- works because its aliasing the global
Maybe we understand "alias" differently. In Python, this is a local
variable that *masks* the global. It is completely different than the
global and can be freely assigned within func.
In general, I didn't follow your examples at all. But I haven't
really used ShedSkin other than some hello-world-type stuff, so my
understanding of ShedSkin could just be insufficient. I imagine
Fahrzin understood what you were saying.
John
Yes by 'alias' I meant 'mask' and you clarified the python scope rules for me.
At the moment shesdkin is a bit too restricted for my taste regards reusing a local variable name as a different type. By relegating a local variable to the tempvars when it is reassigned at the same ident/parent as the previous assignment i hope to broaden the python that shedakin accepts.
On Sep 30, 2011 11:43 PM, "John Yeung" <gallium....@gmail.com> wrote:
On Fri, Sep 30, 2011 at 5:18 PM, Will 'Varfar' <willv...@gmail.com> wrote:
> To explain my (possib...
Well, the point of ShedSkin is to do what Python does, as much as
possible, so in this case, m is local to func, and this is therefore
an UnboundLocalError.
Maybe we understand "alias" differently. In Python, this is a local
> m = 0 <--- works because its aliasing the global
variable that *masks* the global. It is completely different than the
global and can be freely assigned within func.
In general, I didn't follow your examples at all. But I haven't
really used ShedSkin other than some hello-world-type stuff, so my
understanding of ShedSkin could just be insufficient. I imagine
Fahrzin understood what you were saying.
John
--
You received this message because you are subscribed to the Google Groups "shedskin-discuss" gr...
def test(w_a,w_b=None,*args,**kwargs):
w_a=[1,2,3]
w_b=['ab','cd']
for w_i in w_a:
print w_i
for w_i in w_b:
print w_i
for w_i,w_j in w_b:
print w_i,w_j
w_j = 2
becomes (not sorted by line):
Function test
var w_i: #9: for w_i,w_j in w_b: (assign_from w_b[0])
<- w_i: #7: for w_i in w_b: (assign_from w_b)
<- w_i: #5: for w_i in w_a: (assign_from w_a)
var w_j: #11: w_j = 2 (is_a <type 'int'>)
<- w_j: #9: for w_i,w_j in w_b: (assign_from w_b[1])
var args: (is_a *args,is_a arg[2],is_a list)
var w_a: #3: w_a=[1,2,3] (assign_from (list_of ('is_a', <type
'int'>),is_a list))
<- w_a: (is_a arg[0])
var w_b: #4: w_b=['ab','cd'] (assign_from (list_of ('is_a', <type
'str'>),is_a list))
<- w_b: (is_a arg[1])
var kwargs: (is_a **kwargs,is_a arg[3],is_a dict)
Trying to work out how to make a inferred static typing from scratch
is a fun problem.
I currently walk the module looking for the first assignment to each
variable, or reassignment if unconditional, and noting them. I then
pass through a second time working out the references and noticing the
types, even if its just to say 'same as other variable'. I would
think its then to iterate over those variables who have 'assign_from'
and fold them in when the assigned from has no assign_from themselves,
until all are folded or until its a stalemate. How does this compare
to the shedskin approach?
Don't forget that in Python, for and with (and list comprehensions in
Python 2) do NOT create new scope. Genuine Python programs can rely
on this; if you make it so that they have their own scope, the program
is not genuine Python anymore.
On the other hand, def and class do create new scope, and they are the
idiomatic way to create closures in Python.
John
yes very much on my mind!
Interestingly def and class can be thought of as defining a type to go
with a name assignment. One of my test pieces is like this:
if .....:
def func():
b = 10
else:
def func():
b = 12
func()
This is departing slightly from the current shedskin restrictions but
I think this restriction can be lifted if, eventually after lots of
hacking and tedious testing, closures and inner functions generally
were modelled as c++ structs with the variables they refer to in the
struct and functions that are dereferenced or reassigned are modelled
as c++ functors. You could imagine that all working.
Well, in fact, as long as you don't have a compiler nor eval module,
you could imagine an entire introspection built into the c++ mapping
with true dynamic code (think more cython-like in that regard).
See, all projects grow until they exhaust reasonable attempts to start
on them :)
My mind jumps further ahead as I track the dereferencing of names it
becomes possible to know names that are never used, or to know the
index in tuples and such. A lot of python code uses tuples for
intermediate values and it would be able to spot them and turn them
into classic stack-based structs in the generated c++ code...
http://williamedwardscoder.tumblr.com/post/15203221199/less-restricted-python
I have tried to elaborate on my ideas about SSTA on my blog:
http://williamedwardscoder.tumblr.com/post/15203221199/less-restricted-python
Of course my hobby coding time is not really leaning towards hacking
Python compilers, however much I enjoy thinking about it abstractly ;/
/Will
my thought was that an SSTA is a sourcecode transform, and that it
could be done as a preprocessing step. This would be a good way of
validating its correctness - all shedskin programs should survive it
run the same output as without SSTA, and some programs that currently
fail in shedskin should compile with SSTA.
--
You received this message because you are subscribed to the Google Groups "shedskin-discuss" group.
To post to this group, send email to shedskin...@googlegroups.com.
To unsubscribe from this group, send email to shedskin-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/shedskin-discuss?hl=en.
A few quick notes:
Shed Skin is meant to compile a subset of valid Python 2 programs, but
it seems you are using Python 3. (Of course, a subset of valid Python
3 programs are also valid Python 2 programs, and a subset of these can
be compiled by Shed Skin.)
Shed Skin does not have built-in support for arbitrary-precision
integers like CPython has.
Your fractions.py source code has a syntax error near the bottom; it
seems like you used a right paren when you meant a single quote.
John