Mailman 3 May 2004 - Python-Dev

horrible thought
by David Abrahams 07 May '04

07 May '04

Remember the vote on adding conditional expressions? I'm afraid that the imminent proliferation of xxxcomps may indicate the "right" syntax for this feature, if it ever does get added. Something like (a else b if condition) Now I've done my bad deed for the day. Cheers, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

Python 2.3.4 schedule
by Anthony Baxter 06 May '04

06 May '04

My plan is to cut a release candidate for 2.3.4 next Thursday (13th April) Australian time (so Wednesday night for the merkins), and a release the following Thursday (the 20th). Can we say that the 2.3 branch is frozen from Tuesday? As this is likely to be the final 2.3 release (modulo any suprising new bugs), I'd like the time to try and nail this one. As per normal, I'll be on #python-dev on freenode for the next two weeks or so. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

11 17

Re: [Python-Dev] PEP 289 - Generator Expressions - Let's Move For ward
by Jewett, Jim J 06 May '04

06 May '04

Guido van Rossum: > My counter to that is that *any* use of genexps where the consumer > doesn't consume (or discard) the iterator before the next line is > reached is extremely advanced use. This might be worth putting in the PEP and the docs -- Normal usage of a generator expression is to immediately consume the entire sequence, or to discard the remainder. If portions of a generator *are* used later, programmers may need some extra precautions to ensure that all names still have the desired bindings. -jJ

8 10

Passing compile(...,'exec') code to 'eval'
by Brett C. 06 May '04

06 May '04

In preparations for my coding my thesis I have been trying to figure out how a local variable could be assigned to without me explicitly knowing during compilation. Obviously 'exec' can. But I wasn't sure about 'eval'. Reading the docs, I didn't think it could since 'eval', when taking a string, only evaluates expressions. But what about code objects? The docs say, "The code object must have been compiled passing 'eval' as the kind argument". But I didn't read that when I started testing. This is when I discovered you *can* pass in something using 'compile' with the kind argument of "exec":: >>> x Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'x' is not defined [16425 refs] >>> eval(compile("x = 1", "<string>", "exec")) [16426 refs] >>> x 1 Is this a bug, or are the docs wrong? I am hoping it is the former since if it is the latter my thesis just got a big caveat pasted into it about how 'eval' can cause problems and invalidate the type inferencing in irreparable ways. -Brett

3 2

distutils problem: /usr/lib64/python2.3 on x86_64
by Neal Becker 05 May '04

05 May '04

I just tried to build wxPython on x86_64 (athlon64) on Fedora core3 test 3. It didn't work. It looks like python is a 64-bit exec on this platform, and there is /usr/lib64/python2.3/ with what looks like the usual stuff. There is also a /usr/lib/python2.3, with not much in it, but I guess if you install a 32-bit python it would go there. Anyway, distutils/sysconfig.py def get_python_lib(... if os.name == "posix": libpython = os.path.join(prefix, "lib", "python" + get_python_version()) This is wrong, and it doesn't seem to give me anyway to overide the choice. Is there a fix?

2 2

PEP 289 - Generator Expressions - Let's Move Forward
by Guido van Rossum 05 May '04

05 May '04

I'd like to get generator expressions checked into CVS. Regarding the early-or-late binding issue, here's what I'd like to see happen: I'd like the late-binding (i.e. non-capture) version checked in and released with Python 2.4a1 and a2. If we find there are real problems with these semantics, we can switch to early-binding semantics in 2.4b1; this would be almost completely backwards compatible. But if it works in the alpha release, we'll stick with late binding. My reasons for (still!) preferring late binding are: (a) I find it hard to defend automatic variable capture given Python's general late-binding semantics (b) I believe that use cases needing early binding are uncommon and strained: they all involve creating a list of generator expressions, which IMO is a pretty unusual thing to do I cannot volunteer to do the final code review and checkin, and I believe Raymond is still on vacation (he's asked me to relieve him from the responsibility of shepherding this patch) so we need someone to volunteer. The patch is here: http://sf.net/tracker/?func=detail&aid=872326&group_id=5470&atid=305470 --Guido van Rossum (home page: http://www.python.org/~guido/)

11 29

RE: [Python-Dev] PEP 289 - Generator Expressions
by Jewett, Jim J 05 May '04

05 May '04

> Try a concrete example? t1 = (1,2,3) t2 = ("a", "b", "c") t3 = ("first", "second", "third") (x,y,z for x in t1 for y in t2 for z in t3) Do What I Mean is the crossproduct, 27 elements long, which you get with a list comprehension. This will happen if at least (all but one) generators are pre-evaluated. It will also happen if at least (all but one) generators are restarted after they raise StopIterator. Doing strictly what happens today gets only (1,'a',"first"), (1,'a',"second"), (1,'a',"third") because t3 has raised StopIteration by the time t1 or t2 advance. Effectively, only the last iterator matters. Keeping the last value of an iterator also adds (1, 'b', "third"), (1, 'c', "third"), (2, 'c', "third"), (3, '3', "third") for seven values -- but perhaps not a well-chosen seven. Pre-evaluating only the leftmost gets all combinations of (1,2,3) and ("first", "second", "third"), but still misses items like (2, 'b', "second"). Since these are in the middle of the series, they are the most likely to be forgotten during testing. Restarting the second (and later) iterators for each value of the first iterator does the right thing, without requiring any magical pre-evaluation. (Unless the iterator can't be restarted -- in which case there is no right thing, and the user should have decided what to cache.) Thus my suggestion of (x,y,z for x in t1 for y in t2 for z in t3) <==> for x in t1.__iter__(): for y in t2.__iter__(): for z in t3.__iter__(): yield x,y,z For the example data, this creates 3 separate iterators on the letters and nine iterators on the words - but produces the expected result, without having to store or pre-evaluate anything. -jJ

2 1

PEP 289 - Generator Expressions
by Jewett, Jim J 05 May '04

05 May '04

Guido van Rossum: >... mostly-late binding -- which is late binding, except that > the iterable in the leftmost for-clause is evaluated at once. Did you really mean leftmost, or all-but-the-rightmost? Special-casing the left-most causes the two-generator version to behave as expected, but it makes the three-generator case even more confusing. Perhaps the entire early/late binding problem comes from trying to treat multiple generators as a special case. For a single-generator expression, late binding makes sense (or why use a free variable), but early binding would also work most of the time. For multiple generators, the current behavior is that the final generator is exhausted by the first loop, so the other generators really only need one value each. The only problem with that is that it isn't usually what people want. If users do want a cross-product, then either the values have to be stored somewhere, or python has to create a whole series of "equivalent" generators. Python can't do this any better than the user, so why not make the storage explicit? (x,y,z for x in e1 for y in e2 for z in e3) <==> for x in e1.__iter__(): for x in e2.__iter__() for z in e3.__iter__() yield (x,y,z) It is the user's responsibility to ensure that e2 and e3 can return an iterator multiple times, perhaps by wrapping them in a list or tuple. -jJ

2 1

negative modular exponentiation
by Armin Rigo 04 May '04

04 May '04

Hello, SF patch 936813 (fast modular exponentiation) introduces some optimization of exponentiation with longs, including a new feature: in a pow(x,y,z), the exponent y is allowed to be negative when it makes mathematical sense. The result of (x ** -y) % z is a number that is the inverse of (x ** y) % z, i.e. multiplying the two gives 1 modulo z. This is a very convenient feature if you are doing modulo arithmetic. Quoting Trevor Perrin, the patch's author: Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). As this is a new feature it should be approved of. If it is, I'd volunteer to review the patch and make the necessary extension to the plain integer's pow() so that they work the same way. E.g. >>> pow(2,-1,9) 5 because (5*2)%9 == 1. Currently this gives a TypeError (why not a ValueError?) so changing the behaviour seems safe. Armin

4 3

RE: [Zope-dev] Segfault and Deadlock
by Tim Peters 04 May '04

04 May '04

As Andrew Langmead has already discovered, the LinuxThreads issue with SIGSEGV was reported on the Python bug tracker almost a year ago (well, reported, but not diagnosed): SIGSEGV causes hung threads (Linux) http://www.python.org/sf/756924 Looks like: can't CNTRL-C when running os.system in a thread http://www.python.org/sf/756940 is related. python-dev'ers, do we have a release manager for 2.3.4 (I didn't see a resolution to the brouhaha at the end of March)? If so, is 2.3.4 still planned for this month? tick-tock-tick-tock-ing-ly y'rs - tim

1 0