RELEASED Python 2.4, alpha 1

[Anthony Baxter]

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
an*****@python. org
Python Release Manager
(on behalf of the entire python-dev team)

[Michele Simionato]

bo**@oz.net (Bengt Richter) wrote in message

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:
Yes, I was unsure of the right term to use, I meant late lookup (so
I used the term "early binding" improperly, but you understood what
I asked anyway ;).

>>> 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?

Python 2.4a1 (#1, Jul 10 2004, 02:19:27)
[GCC 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

ls=[i for i in [1,2,3]]
i 3 it=(j for j in [1,2,3])
j

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'j' is not defined

I like this.
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>)

Yes Bengt, but would you seriously use such "solutions" ? The default argument
trick is ugly but far better than those horrors! ;) What I do in reality
is to I create a custom function factory (or a factory of callable
objects) and I pass it to the list comprehension with "i" as a parameter.
My complaint is that it is more verbose than I would like for short
functions where I would consider a "lambda".

Michele Simionato
Michele

[Anthony Baxter]

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

I think you'll find if you check the PEP that this is the decision of the BDFL.

The feeling was that early binding was too different and would lead to
more confusion than late binding. While late binding can give suprising
results if you're not aware of it, it is at least consistent with other language
features (such as lambdas and list comps)

Anthony

[Anthony Baxter]

On Fri, 09 Jul 2004 11:22:27 +0200, Iwan van der Kleyn <no**@none.ne t> wrote:

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?

They are planned for the next alpha. There will be at least one more
alpha release before the beta - possibly two! The more folks that download
the first alpha and let us know of problems _now_, the sooner a 2.4 final
will be done.

[Michael Hudson]

Irmen de Jong <[e-mail]> writes:

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'
*************** *************** *************** *************** **********

[snippety]

This has the foul, rotten stench of something involving locales. What
is the default locale on your system? There's probably some test that
runs before test_format on your system that is messing things up.
Binary chop?

Cheers,
mwh

--
MARVIN: Oh dear, I think you'll find reality's on the blink again.
-- The Hitch-Hikers Guide to the Galaxy, Episode 12

[Irmen de Jong]

Michael Hudson wrote:

Irmen de Jong <[e-mail]> writes:

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'
************* *************** *************** *************** ************

[snippety]

This has the foul, rotten stench of something involving locales. What
is the default locale on your system? There's probably some test that
runs before test_format on your system that is messing things up.

My default locale is NL_nl, which does indeed contain ',' for the decimal symbol.
And I have to agree with your feeling that an earlier test messes something up,
because when I run the test_format test by itself, it runs fine without error.

However, when I switch locales to en_US, the test still fails! (same error).

Binary chop?

Sorry, what do you mean by that?

--Irmen

[Martin v. Löwis]

Irmen de Jong wrote:

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' >>>

Does the test also fail if you run it as "python Lib/test/regrtest.py
test_format"? If not, does it fail if you run it as
python Lib/test/regrtest.py <all test cases that are executed before
test_format> test_format? If yes, please try to eliminate all prior
test cases that don't contribute to the failure, and report the
minimum sequence of test cases needed to make it fail.

Regards,
Martin

[Martin v. Löwis]

Irmen de Jong wrote:

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' >>>

Does the test also fail if you run it as "python Lib/test/regrtest.py
test_format"? If not, does it fail if you run it as
python Lib/test/regrtest.py <all test cases that are executed before
test_format> test_format? If yes, please try to eliminate all prior
test cases that don't contribute to the failure, and report the
minimum sequence of test cases needed to make it fail.

Regards,
Martin

[Tim Peters]

[Irmen de Jong]
,,,

As Michael Hudson pointed out it's probably a test that
messes with the locale settings and forgets to set them back,
or some such.

In case you don't already know it, regrtest.py's little-used -f
argument lets you specify a file, containing the names of the tests
you want to run. It ignore lines in the file starting with '#'. So
it's a convenient way to do a binary-search kind of reduction when
looking for a minimal *set* of failing tests: edit the file, run,
stick '#' in front of half the remaining lines if it still fails then,
etc.

[Martin v. Löwis]

Irmen de Jong wrote:

I'll try when I have some time for that...
As Michael Hudson pointed out it's probably a test that
messes with the locale settings and forgets to set them back,
or some such.

Rather "some such". If this was a systematic error, it would
fail for many more people.

Regards,
Martin

[Irmen de Jong]

Tim Peters wrote:

[Irmen de Jong]
,,,

As Michael Hudson pointed out it's probably a test that
messes with the locale settings and forgets to set them back,
or some such.

In case you don't already know it, regrtest.py's little-used -f
argument lets you specify a file, containing the names of the tests
you want to run.

That was great, I quickly found out that test__locale is the cause.
Not only test_format but also test_unicode fail on my Mandrake 10 box.
My default locale is nl_NL. Behold:

[irmen@atlantis Python-2.4a1]$ cat testcases.in
test__locale
test_format
test_unicode

[irmen@atlantis Python-2.4a1]$ ./python Lib/test/regrtest.py -f testcases.in
test__locale
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_unicode
test test_unicode failed -- Traceback (most recent call last):
File "/home/irmen/BUILD/Python-2.4a1/Lib/test/test_unicode.py ", line 358, in
test_formatt ing
string_tests.Mi xinStrUnicodeUs erStringTest.te st_formatting(s elf)
File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py ", line 615, in
test_formatt ing
self.checkequal ('0042.00', '%07.2f', '__mod__', 42)
File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py ", line 56, in checkequal
realresult
AssertionError: u'0042.00' != u'0042,00'

1 test OK.
2 tests failed:
test_format test_unicode
[irmen@atlantis Python-2.4a1]$
--Irmen