Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RELEASED Python 2.4, alpha 1

Reply
Thread Tools

RELEASED Python 2.4, alpha 1

 
 
Anthony Baxter
Guest
Posts: n/a
 
      07-09-2004
On behalf of the Python development team and the Python community, I'm
happy to announce the first alpha of Python 2.4.

Python 2.4a1 is an alpha release. We'd greatly appreciate it if you
could download it, kick the tires and let us know of any problems you
find, but it is not suitable for production usage.

http://www.python.org/2.4/

In this release we have a number of new modules, a number of existing
modules that have been reimplemented in C for speed, a large number of
improvements and additions to existing modules and an even larger list
of bugs squished. See either the highlights, the What's New in Python
2.4, or the detailed NEWS file -- all available from the Python 2.4
webpage.

There will be at least one more alpha release in a couple of weeks to
pick up a few new features that didn't make it into the first alpha,
before we release 2.4 betas and then the final release.

Please log any problems you have with this release in the SourceForge
bug tracker (noting that you're using 2.4a1):

http://sourceforge.net/bugs/?group_id=5470

Enjoy the new release,
Anthony

Anthony Baxter
http://www.velocityreviews.com/forums/(E-Mail Removed)
Python Release Manager
(on behalf of the entire python-dev team)
 
Reply With Quote
 
 
 
 
Iwan van der Kleyn
Guest
Posts: n/a
 
      07-09-2004
Anthony Baxter wrote:
> On behalf of the Python development team and the Python community, I'm
> happy to announce the first alpha of Python 2.4.


Congratulations on a terrific job, as always. Just to be curious:
clearly, function decorators didn't make it in this release. Will they
be incorporated in the beta?

Regards,

Iwan
 
Reply With Quote
 
 
 
 
Michele Simionato
Guest
Posts: n/a
 
      07-09-2004
Anthony Baxter <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> On behalf of the Python development team and the Python community, I'm
> happy to announce the first alpha of Python 2.4.
> <snip>


Uhm ... I see generator expressions have late bindings, just as list comprehensions:

>>> f1,f2,f3=tuple(lambda : i for i in [1,2,3])
>>> f1()

3
>>> f2()

3
>>> f3()

3

I was more in the camp of early bindings; I would like to know if late
bindings are final or subject to changes and it there a pronouncement
from Guido.


Michele Simionato
 
Reply With Quote
 
Christopher T King
Guest
Posts: n/a
 
      07-09-2004
On 9 Jul 2004, Michele Simionato wrote:

> Uhm ... I see generator expressions have late bindings, just as list
> comprehensions:
>
> >>> f1,f2,f3=tuple(lambda : i for i in [1,2,3])
> >>> f1()

> 3
> >>> f2()

> 3
> >>> f3()

> 3


I think this is a property of lambdas (or functions in general), rather
than comprehensions:

>>> i=1
>>> f1=lambda: i
>>> i=2
>>> f2=lambda: i
>>> i=3
>>> f3=lambda: i
>>> f1()

3
>>> f2()

3
>>> f3()

3

 
Reply With Quote
 
Irmen de Jong
Guest
Posts: n/a
 
      07-09-2004
Anthony Baxter wrote:
> On behalf of the Python development team and the Python community, I'm
> happy to announce the first alpha of Python 2.4.


Great stuff.

One thing ; the format test isn't working:
(Mandrake 10, gcc 3.3.2)

$ make test

....
test_format
test test_format produced unexpected output:
************************************************** ********************
*** line 2 of actual output doesn't appear in expected output after line 1:
+ u'%f' % (1.0,) == u'1,000000' != '1.000000'
************************************************** ********************
test_fpformat
....
test_zlib
249 tests OK.
1 test failed:
test_format
30 tests skipped:
test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
.....


I'm wondering where the u'1,000000' comes from... because when I type
on the interactive prompt:
Python 2.4a1 (#1, Jul 9 2004, 15:42:46)
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u'%f' % (1.0,)

u'1.000000'
>>>




--Irmen.
 
Reply With Quote
 
Tim Peters
Guest
Posts: n/a
 
      07-09-2004
[Michele Simionato]
> Uhm ... I see generator expressions have late bindings, just as list
> comprehensions:
>
> >>> f1,f2,f3=tuple(lambda : i for i in [1,2,3])
> >>> f1()

> 3
> >>> f2()

> 3
> >>> f3()

> 3
>
> I was more in the camp of early bindings; I would like to know if late
> bindings are final or subject to changes and it there a pronouncement
> from Guido.


Guido Pronounced: the expression in the leftmost "for" clause is
evaluated immediately, but all the rest is delayed. So in your
example, only "[1, 2, 3]" is evaluated at the time the genexp is
created. If you had tried to iterate instead over, say, range(1/0),
the ZeroDivisionError would have been raised immediately, which is the
real point of evaluating that one piece "early".

Don't ask me to justify the rest <wink>.

Guido doesn't really care about examples like yours. He thinks
genexps will overwhelmingly be consumed "on the same line" they're
created, and that people doing fancy-pants stuff like you're doing
there probably shouldn't (but could find more-or-less obvious
workarounds if they had to, given that they're obsessed enough to try
such fancy-pants stuff to begin with).

The world won't end either way (IMO), and (also IMO) Python has pushed
delayed code blocks in a scoped language without explicit scope
declarations about as far as it can without becoming plainly
incomprehensible.
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      07-10-2004
Christopher T King <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>
> I think this is a property of lambdas (or functions in general), rather
> than comprehensions:
>
> >>> i=1
> >>> f1=lambda: i
> >>> i=2
> >>> f2=lambda: i
> >>> i=3
> >>> f3=lambda: i
> >>> f1()

> 3
> >>> f2()

> 3
> >>> f3()

> 3


No, it is due to the fact that looping does not create a new lexical
scope. This was discussed in depth in the past. Google in this
newgroup.
Scheme does it right:

; scheme is the same as in Python here
msi> (define i 1)
msi> (define (f1) i)
msi> (set! i 2)
msi> (define (f2) i)
msi> (set! i 3)
msi> (define (f3) i)
msi> (f1)
3
msi> (f2)
3
msi> (f3)
3
; Scheme is different in looping constructs
msi> (define-values (f1 f2 f3) (apply values (map (lambda(i) (lambda()
i)) '(1 2 3))))
msi> (f1)
1
msi> (f2)
2
msi> (f3)
3

After long discussions in previous threads, I do understand well why
it is so;
I also understand why in regular "for" loops Python behavior has to be
the one
it is, since "for" does not create a new lexical scope. In my opinion,
however, it would have made more sense to have generator-expressions
with
early bindings.
But, anyway, Tim Peters is right that this issue does not make a
big difference for casual programmers and sophysticated programmers
know the workarounds.

Michele Simionato
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      07-10-2004
Tim Peters <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Guido Pronounced: the expression in the leftmost "for" clause is
> evaluated immediately, but all the rest is delayed. So in your
> example, only "[1, 2, 3]" is evaluated at the time the genexp is
> created. If you had tried to iterate instead over, say, range(1/0),
> the ZeroDivisionError would have been raised immediately, which is the
> real point of evaluating that one piece "early".
>
> Don't ask me to justify the rest <wink>.
>
> Guido doesn't really care about examples like yours. He thinks
> genexps will overwhelmingly be consumed "on the same line" they're
> created, and that people doing fancy-pants stuff like you're doing
> there probably shouldn't (but could find more-or-less obvious
> workarounds if they had to, given that they're obsessed enough to try
> such fancy-pants stuff to begin with).
>
> The world won't end either way (IMO), and (also IMO) Python has pushed
> delayed code blocks in a scoped language without explicit scope
> declarations about as far as it can without becoming plainly
> incomprehensible.


It happened to me more than once to think that Guido made something
wrong and to change my mind months later. So this maybe one of those
occasions. The problems is mostly for people coming from functional
languages. Incidentally, I got caught by this a couple of year ago
and this was the reason for my first post on the newsgroup (I was
playing with Tkinter at the time and lambda's are useful as callback
functions). At the time I had no experience with functional languages,
but still I had a functional mindset due to my strong mathematical
background and experience with Mathematica/Maple.

The simplest workaround is Pythonic in the sense that it is explicit

f1,f2,f3=tuple(lambda i=i: i for i in [1,2,3])

as one explicitly rebinds "i" at each iteration but still I cannot
find it other than hackish, since there is no point here in creating
a function with default arguments other than fixing the
binding-in-iteration
issue. What I would need is a better way to create function objects
than
lambda's; for instance I would like the ability to subclass the
function type and customize it to my needs (but I have already talked
about this in the
past
http://groups.google.it/groups?hl=it...gle.com&rnum=1
so I want repeat myself).
If I had that, the binding-in-iteration issue would be minor for me
and I
would not protest anymore. Actually I would probably think that it is
good
to have a broken binding-in-iteration behavior, so people are
encouraged
not to use lambda's and to generate their functions in other ways.

Michele Simionato
 
Reply With Quote
 
Denis S. Otkidach
Guest
Posts: n/a
 
      07-10-2004
On Sat, 9 Jul 2004, Michele Simionato wrote:

MS> The simplest workaround is Pythonic in the sense that it is
MS> explicit
MS>
MS> f1,f2,f3=tuple(lambda i=i: i for i in [1,2,3])
MS>
MS> as one explicitly rebinds "i" at each iteration but still I
MS> cannot
MS> find it other than hackish, since there is no point here in
MS> creating
MS> a function with default arguments other than fixing the
MS> binding-in-iteration

You can bind explicitly without default argument hack:
>>> f1, f2, f3 = [(lambda i: lambda: i)(i) for i in [1, 2, 3]]
>>> f1()

1
>>> f2()

2
>>> f3()

3

I think the same will apply to generator expression too.

--
Denis S. Otkidach
http://www.python.ru/ [ru]
 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      07-10-2004
On 9 Jul 2004 11:38:00 -0700, (E-Mail Removed) (Michele Simionato) wrote:

>Anthony Baxter <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> On behalf of the Python development team and the Python community, I'm
>> happy to announce the first alpha of Python 2.4.
>> <snip>

>
>Uhm ... I see generator expressions have late bindings, just as list comprehensions:
>
>>>> f1,f2,f3=tuple(lambda : i for i in [1,2,3])
>>>> f1()

>3
>>>> f2()

>3
>>>> f3()

>3
>

I guess I don't know what you mean by "late binding" -- i.e., I don't see
a semantic difference between (I don't have the generator expression version yet):

>>> f1,f2,f3=[lambda : i for i in [1,2,3]]
>>> f1(),f2(),f3()

(3, 3, 3)

and

>>> lamb = lambda : i
>>> f1,f2,f3=[lamb for i in [1,2,3]]
>>> f1(),f2(),f3()

(3, 3, 3)

ISTM it is a matter of late lookup, more than late binding. I.e.,
the lambda expression specifies lookup of a name "i" when it is executed:

>>> import dis
>>> dis.dis(lambda : i)

1 0 LOAD_GLOBAL 0 (i)
3 RETURN_VALUE

The list comprehension didn't generate a different lookup:
>>> f1,f2,f3=[lambda : i for i in [1,2,3]]
>>> dis.dis(f1)

1 0 LOAD_GLOBAL 0 (i)
3 RETURN_VALUE

BTW, if list comprehension variables bound in a loop-private scope instead of
the enclosing scope, the lookup of i would fail unless otherwise set
Will generator expressions bind in the eclosing scope too? Have the consequences been discussed?

Anyway, as I think you know, to get your desired end result, you have to create lambdas
that will do their lookups referring to different i's -- which you can do with closures, e.g.,

>>> f1,f2,f3=[(lambda i: lambda : i)(i) for i in [1,2,3]]
>>> f1(),f2(),f3()

(1, 2, 3)
>>> dis.dis(f1)

1 0 LOAD_DEREF 0 (i)
3 RETURN_VALUE

Or here's another of several other possible ways:

>>> f1,f2,f3=[(lambda i:i).__get__(i,int) for i in [1,2,3]]
>>> f1(),f2(),f3()

(1, 2, 3)
>>> dis.dis(f1)

1 0 LOAD_FAST 0 (i)
3 RETURN_VALUE

BTW, those are bound methods ...
>>> f1,f2,f3

(<bound method int.<lambda> of 1>, <bound method int.<lambda> of 2>, <bound method int.<lambda> of 3>)


>I was more in the camp of early bindings; I would like to know if late
>bindings are final or subject to changes and it there a pronouncement
>from Guido.
>
>
> Michele Simionato


Regards,
Bengt Richter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RELEASED Python 2.4, alpha 3 Anthony Baxter Python 0 09-03-2004 08:36 AM
Re: RELEASED Python 2.4, alpha 2 Anthony Baxter Python 29 08-11-2004 02:07 AM
Re: [Python-Dev] RELEASED Python 2.4, alpha 2 =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Python 9 08-10-2004 04:33 PM
RELEASED Python 2.4, alpha 2 Anthony Baxter Python 0 08-05-2004 01:10 PM
Re: RELEASED Python 2.4, alpha 1 Mike C. Fletcher Python 16 07-12-2004 10:50 PM



Advertisments