> I can say it stronger. Any resemblance between Python and Scheme or
> Lisp is purely a coincidence. Neither language is in Python's
> ancestry, at least not explicitly; I'd never used or tried to learn
> Scheme when I started Python (still haven't) and my Lisp experience
> was limited to copying
Neal Norwitz wrote:
> The current list of serious bugs are in the PEP:
>
> http://www.python.org/dev/peps/pep-0356/
>
> If there are any bugs you think should be considered show stoppers,
> mail them to the list and I will update the PEP.
http://www.python.org/sf/1519018
I believe this regres
On 6/30/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >
> >There are at least 6 bugs that really, really need to be fixed before
> >release. Several of these are AST bugs. Jeremy knows about them and
> >plans to fix them once he's back from vacation. Anyone else wanna
> >help out? One is
Neal Norwitz schrieb:
> On 7/4/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>> I would like to ask about the possibility to add some improvements to ctypes
>> in Python 2.5, although the feature freeze is now in effect. Hopefully
>> former
>> third-party libraries can have the freeze relaxed s
On 7/4/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> I would like to ask about the possibility to add some improvements to ctypes
> in Python 2.5, although the feature freeze is now in effect. Hopefully former
> third-party libraries can have the freeze relaxed somewhat;-).
Ok, former third-pa
Thomas Heller wrote:
> I would like to ask about the possibility to add some improvements to
> ctypes
> in Python 2.5, although the feature freeze is now in effect. Hopefully
> former third-party libraries can have the freeze relaxed somewhat;-).
>
> I intend to do these changes, the first is a
Neal Norwitz schrieb:
> I'm glad to see Anthony ratcheting down. At this point, we need to be
> fixing bugs and improving doc. Maybe Anthony and I should have a
> contest to see who can revert the most changes. :-)
>
Neal (and/or Anthony),
I would like to ask about the possibility to add some i
On 7/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> One thing to remember is that Python is not Scheme/Lisp. It borrows
> some ideas from Scheme/Lisp,
I can say it stronger. Any resemblance between Python and Scheme or
Lisp is purely a coincidence. Neither language is in Python's
ancestry, at
"Bill Chiles" <[EMAIL PROTECTED]> wrote:
>
> For Common Lispers and probably Schemers, Python has some surprising
> semantics around scope and lifetime extent of variables. Three that
> leap out at me are:
One thing to remember is that Python is not Scheme/Lisp. It borrows
some ideas from Sche
van Rossum; Tim Peters;
python-dev@python.org
Subject: Re: [Python-Dev] 2.5 and beyond
> >>> a = []
> >>> for i in range(10):
> ... a.append(lambda: i)
> ...
> >>> print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Isn't this exactly wha
Tim Peters wrote:
> Scheme has no loops in Python's sense --
> things like "do" are shorthand for expressing stylized recursion
But it does have foreach and map, which are the
moral equivalent of Python's for-loops and list
comprehensions. The body is a lambda which takes
the loop variable as a p
Giovanni Bajo wrote:
> I believe that names in
> lambdas/nested-functions referring to local names in the outer scope should
> really be bound at function definition time
No, you don't want that, because it would make functions that
call each other very awkward to arrange.
> And it's also handy t
At 01:58 PM 7/2/2006 +0200, [EMAIL PROTECTED] wrote:
>I believe the problem has nothing to do with how many scopes a block/function
>definition has, but with what the lambda does with the scope it's given.
>Currently it remembers the block and looks up the nescessary variables in it
>when it's invo
Hi everyone, Even though I'm new on this list I think I've got something
sensible to say on this one. (I've been following this list a bit through the
archives)
Andrew Koenig wrote:
> You seem to be right -- the problem is not that Python is lexically scoped,
> but that when you define a variabl
[Tim]
>> Don't recall what that was, but creating a new scope on each iteration
>> sounds hard to explain in Python.
[Andrew Koenig]
> I don't think it's particularly hard to explain. For example, one way to
> explain it is
> to say that
>
> for i in <>:
> body
>
> is equ
> Don't recall what that was, but creating a new scope on each iteration
> sounds hard to explain in Python.
I don't think it's particularly hard to explain. For example, one way to
explain it is to say that
for i in <>:
body
is equivalent to
for <> in <>:
Andrew Koenig wrote:
> Suppose I write
>
> x = []
> for i in range(10):
> x.append(lambda:i)
> print [f() for f in x]
>
> This example will print [9, 9, 9, 9, 9, 9, 9, 9, 9, 9], which I think
> is wildly unintuitive.
That is my point: to me, it's counter-intuitive just like the infamous
"except N
> a = []
> for i in range(10):
> a.append(lambda: i)
> print [x() for x in a]
>
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Aha! -- Thank you for jogging my memory.
You seem to be right -- the problem is not that Python is lexically scoped,
but that when you define a variable with =, it leaks out into
Anthony Baxter wrote:
> given the number of people and ways that this can emit a spurious
> warning, I think it should be reverted for 2.5. At _best_ we could
> maybe have a new -W switch to make it be generated, but this should
> be off by default.
Last line of warnings.py
Copy, paste, s/Pend
Giovanni Bajo wrote:
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
If you'd like each func
[Giovanni Bajo]
>> >>> a = []
>> >>> for i in range(10):
>>
>> ... a.append(lambda: i)
>> ...
>>
>> >>> print [x() for x in a]
>>
>> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>>
>> This subtle semantic of lambda is quite confusing, and still forces people to
>> use the "i=i" trick.
[Greg Ewing]
> This ha
On Saturday 01 July 2006 05:19, Martin v. Löwis wrote:
> James Y Knight wrote:
> > I just submitted http://python.org/sf/1515169 for the
> > ImportWarning issue previously discussed here. IMO it's
> > important.
>
> At the moment (i.e. without an acceptable alternative
> implementation) it's primar
[Tim Peters]
>> Note that this is quite unlike Scheme, in which declaration must
>> appear before use (ignoring fancy letrec cases),
[Greg Ewing]
> I think that's overstating things a bit --
So do I :-), but I don't really care about Scheme here.
> mutually recursive functions are quite easy to
Giovanni Bajo wrote:
a = []
for i in range(10):
>
> ... a.append(lambda: i)
> ...
>
print [x() for x in a]
>
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
This has *nothing* to do with
Tim Peters wrote:
> Note that this is quite unlike Scheme, in which declaration must
> appear before use (ignoring fancy letrec cases),
I think that's overstating things a bit -- mutually
recursive functions are quite easy to write in Scheme
and don't look at all "fancy" (unless you object for
so
Andrew Koenig wrote:
> Incidentally, I think that lexical scoping would also deal with the problem
> that people often encounter in which they have to write things like "lambda
> x=x:" where one would think "lambda x:" would suffice.
This is another red herring. Python's problem here
is not becau
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [Giovanni Bajo]
>> Yes but:
>>
> a = []
> for i in range(10):
>> ... a.append(lambda: i)
>> ...
> print [x() for x in a]
>> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>. Do you agree that it would be ideal if the
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces
>
[Giovanni Bajo]
> Yes but:
>
a = []
for i in range(10):
> ... a.append(lambda: i)
> ...
print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
[Tim Peters]
> So stay away fr
> >>> a = []
> >>> for i in range(10):
> ... a.append(lambda: i)
> ...
> >>> print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Isn't this exactly what you'd expect? Maybe I've been writing Python
for too long... :-).
Bill
___
Python-Dev maili
[Giovanni Bajo]
> Yes but:
>
> >>> a = []
> >>> for i in range(10):
> ... a.append(lambda: i)
> ...
> >>> print [x() for x in a]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>
> This subtle semantic of lambda is quite confusing, and still forces people to
> use the "i=i" trick.
So stay away from excruciat
Tim Peters <[EMAIL PROTECTED]> wrote:
>> ...
>> Incidentally, I think that lexical scoping would also deal with the
>> problem
>> that people often encounter in which they have to write things like
>> "lambda
>> x=x:" where one would think "lambda x:" would suffice.
>
> They _shouldn't_ encounter
[Andrew Koenig]
> Almost. What I really want is for it to be possible to determine the
> binding of every name by inspecting the source text of the program. Right
> now, it is often possible to do so, but sometimes it isn't.
Local names are always determined at compile-time in Python. What you
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> The fundamental principle is that the binding of every name is determined
> during compilation, not during execution. This property does not quite
> apply to Python at present.
I think this property does apply. In your example:
> def g():
>
On 6/30/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I read "a la Scheme" here as "actually nothing like Scheme, except I
> > want a non-tricky way to rebind a name from an enclosing scope within
> > an enclosed scope".
>
> Almost. What I really want is for it to be possible to determine the
>
[Andrew Koenig]
> ...
> Incidentally, I think that lexical scoping would also deal with the problem
> that people often encounter in which they have to write things like "lambda
> x=x:" where one would think "lambda x:" would suffice.
They _shouldn't_ encounter that at all anymore. For example,
At 07:04 PM 6/30/2006 -0400, Andrew Koenig wrote:
>However, if I write
>
> def g():
> return x
> x = 42
> g()
>
>the result is 42. With lexical scoping, I believe it should be undefined.
>
>The reason is that when the compiler encounters the definition of g,
> I read "a la Scheme" here as "actually nothing like Scheme, except I
> want a non-tricky way to rebind a name from an enclosing scope within
> an enclosed scope".
Almost. What I really want is for it to be possible to determine the
binding of every name by inspecting the source text of the prog
> That sounds like a bug, not a feature. It's frequently useful to have
> forward references in function bodies to names that are not yet globally
> bound, e.g. for classes, or mutually-recursive functions.
The trouble is that you don't necessarily know in what scope they will be
defined, so I t
[Andrew Koenig]
>>> I saw messages out of sequence and did not realize that this would be a
>>> change in behavior from 2.4. Sigh.
[Ka-Ping Yee]
>> Yes, this is not a good time to change it.
>>> I hope Py3000 has lexical scoping a la Scheme...
>> Me too -- that would be really nice.
[Guido]
>
Guido van Rossum wrote:
> On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> On Fri, 30 Jun 2006, Andrew Koenig wrote:
>>> I hope Py3000 has lexical scoping a la Scheme...
>> Me too -- that would be really nice.
>
> That's not a very constructive proposal (especially since I don't know
> Scheme
> That's not a very constructive proposal (especially since I don't know
> Scheme). Perhaps you could elaborate on what needs to change?
The fundamental principle is that the binding of every name is determined
during compilation, not during execution. This property does not quite
apply to Python
On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Jun 2006, Andrew Koenig wrote:
> > I saw messages out of sequence and did not realize that this would be a
> > change in behavior from 2.4. Sigh.
>
> Yes, this is not a good time to change it.
>
> > I hope Py3000 has lexical scoping a
On Fri, 30 Jun 2006, Andrew Koenig wrote:
> I saw messages out of sequence and did not realize that this would be a
> change in behavior from 2.4. Sigh.
Yes, this is not a good time to change it.
> I hope Py3000 has lexical scoping a la Scheme...
Me too -- that would be really nice.
-- ?!ng
_
James Y Knight wrote:
> On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
>> If there are any bugs you think should be considered show stoppers,
>> mail them to the list and I will update the PEP.
>
> I just submitted http://python.org/sf/1515169 for the ImportWarning
> issue previously discussed
[EMAIL PROTECTED] wrote:
> Ping> The question is, what behaviour is preferable for this code:
>
> Ping> g = 1
> Ping> def f():
> Ping> g += 1
>
> Ping> f()
>
> If you treat "g += 1" as "g = g + 1" then it should create a local variable
> with a value of 2.
> I think it should increment (i.e. rebind) g, for the same reason that
>
> g = [1]
> def f():
> g[0] += 1
> f()
>
> rebinds g[0].
I saw messages out of sequence and did not realize that this would be a
change in behavior from 2.4. Sigh.
I hope Py3000 has lexica
> The question is, what behaviour is preferable for this code:
>
> g = 1
> def f():
> g += 1
>
> f()
>
> Should this raise an UnboundLocalError or should it increment g?
I think it should increment (i.e. rebind) g, for the same reason that
g = [1]
def f():
On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
> If there are any bugs you think should be considered show stoppers,
> mail them to the list and I will update the PEP.
I just submitted http://python.org/sf/1515169 for the ImportWarning
issue previously discussed here. IMO it's important.
Jame
On Fri, 30 Jun 2006 00:05:10 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>I'm glad to see Anthony ratcheting down. At this point, we need to be
>fixing bugs and improving doc. Maybe Anthony and I should have a
>contest to see who can revert the most changes. :-)
>
>There are at least 6 bugs th
Ping> The question is, what behaviour is preferable for this code:
Ping> g = 1
Ping> def f():
Ping> g += 1
Ping> f()
If you treat "g += 1" as "g = g + 1" then it should create a local variable
with a value of 2. There being no global statement in f() it
Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> On Fri, 30 Jun 2006, Neal Norwitz wrote:
>> The current list of serious bugs are in the PEP:
>>
>> http://www.python.org/dev/peps/pep-0356/
>
> Among them is this one:
>
> Incorrect LOAD/STORE_GLOBAL generation
> http://python.org/sf/1501934
>
>
[Ka-Ping Yee, on
http://www.python.org/dev/peps/pep-0356/
]
> Among them is this one:
>
> Incorrect LOAD/STORE_GLOBAL generation
> http://python.org/sf/1501934
>
> The question is, what behaviour is preferable for this code:
>
> g = 1
> def f():
> g += 1
>
> f()
>
> Sh
On Fri, 30 Jun 2006, Neal Norwitz wrote:
> The current list of serious bugs are in the PEP:
>
> http://www.python.org/dev/peps/pep-0356/
Among them is this one:
Incorrect LOAD/STORE_GLOBAL generation
http://python.org/sf/1501934
The question is, what behaviour is preferable for this co
I'm glad to see Anthony ratcheting down. At this point, we need to be
fixing bugs and improving doc. Maybe Anthony and I should have a
contest to see who can revert the most changes. :-)
There are at least 6 bugs that really, really need to be fixed before
release. Several of these are AST bugs
55 matches
Mail list logo
