Mailman 3 November 2004 - Python-Dev

enhanced gdbinit file - looking for Python+Emacs+gdb users
by Skip Montanaro 21 Nov '04

21 Nov '04

I got a little carried away with the gdbinit file that lives in the Python distribution at Misc/gdbinit today. I decided there's no particular reason that gdb shouldn't display the current Python file when moving up and down the C stack any time it encounters PyEval_EvalFrame. After a little digging I realized this would be pretty easy. I made two changes to the gdbinit file: 1. I wrote a lineno command for gdb that calculates and prints the current Python line number. (It's PyCode_Addr2Line written in gdb's command language.) 2. Using that and the current file gleaned from PyEval_EvalFrame I emit the file:line info in the correct format for Emacs to display the Python line number at the right time using overridden up and down commands. There's one slight hitch. It works perfectly when travelling up the C stack using the up command, however in my environment at least (MacOSX w/ Apple's gcc and gdb) it causes gdb to segfault when travelling down the stack. I can't see anything that would make the behavior different going up instead of down. I need some people to try this thing out to see if it barfs for them as well. Maybe it's just something peculiar to my environment. OTOH, perhaps it's a bug in gdb. Since I can't really check this beast in given its current rather dicey behavior, I dropped a copy at http://www.musi-cal.com/~skip/python/gdbinit If you use Python with gdb via Emacs please give it a whirl and let me know how it works for you. Thanks, Skip P.S. I think I know how to make the gdb print command print Python objects as well...

2 1

Re: [Python-Dev] Re: syntactic shortcut - unpack to variably sizedlist
by Nick Coghlan 21 Nov '04

21 Nov '04

Raymond Hettinger wrote: >>I have no great problem with leaving the a, b, *c = L idea unPEPed if >>there is >>interest in leaving the idea 'open', though. > > > Yes. I would like to have it left open. OK, here's what I'll do in the next draft of the proposed PEP (PEPP?): 1. Add a discussion of the advantages of iunpack over islice: - guaranteed minimum length (handy for use with tuple unpacking) - return the iterator as the final object (this is nicer when the original object is an iterable, rather than an iterator - e.g. a list or tuple) 2. Summarise the use cases as given by the previous proponents of the "a, b, *c = S" syntax. 3. Soften the PEP's language regarding the "a, b *c = S" syntax. Point out that this is a way to get the functionality in a fairly easy to spell form for 2.5 that doesn't require changing Python's syntax. itertools.iunpack could serve as a reference for defining the behaviour of that syntax at a later date. I find the following to be rather readable: a, b, itr = iunpack(S, 2) "iunpack" is also easy to look up in the documentation index. If Carlos is amenable, I'll add him as a co-author on the PEP - after all, he's the one who sold *me* on the idea of iunpack, and most of the points defending it are originally his. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

1 0

Re: [Python-Dev] Re: syntactic shortcut - unpack to variably sizedlist
by Nick Coghlan 20 Nov '04

20 Nov '04

Raymond Hettinger wrote: >>Officially killing that syntax was actually one of the stated goals of > > the > >>PEP. > > I don't think that is a worthy goal. The is some merit to the a,b,*c > syntax. When the time is ripe, it should have its day in court. There's currently 3 things in the PEP draft: 1. Allow slice objects as arguments list.pop and array.pop 2. Add itertools.iunpack 3. Record the rejection of a, b, *c = L in a PEP (since it's been rejected three times now - once in 2001, and twice this year) The first of those could probably be done without a PEP (given that a strict reading of the documentation suggests that those methods *should* handle slices) The 2nd can certainly be separated out. Since I now know that, for actual iterators (rather than iterables), islice(n) will usually consume the first n elements, it loses some of its appeal (i.e. islice already has most of the features I like about iunpack). The 3rd - well, I thought Guido's rejection in August suggested his position was unlikely to change (the AST branch going in for 2.5 doesn't seem to be significant enough to prompt a change of heart, and I can't think of anything else likely to affect his stated reasons for rejection). I have no great problem with leaving the a, b, *c = L idea unPEPed if there is interest in leaving the idea 'open', though. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

1 0

Re: [Python-Dev] Re: syntactic shortcut - unpack to variably sizedlist
by Nick Coghlan 20 Nov '04

20 Nov '04

Raymond Hettinger wrote: > Also, the pep would likely kill the remote, but non-zero chance of ever > getting the a,b,*c syntax. IOW, the pep may be a step backwards. Officially killing that syntax was actually one of the stated goals of the PEP. However, the PEP editors would be well within their rights to reject the draft as 'lacking focus'. I wouldn't be offended given the whole 20 minutes it took to write it :) Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

2 1

syntactic shortcut - unpack to variably sized list
by Johan Hahn 20 Nov '04

20 Nov '04

Hi As far as I can tell from the archive, this has not been discussed before. This is the second time in less than a week that I have stumbled over the rather clumsy syntax of extracting some elements of a sequence and at the same time remove those from the sequence: >>> L = 'a b 1 2 3'.split(' ') >>> a,b,L = L[0], L[1], L[2:] I think it would be nice if the following was legal: >>> a,b,*L = 'a b 1 2 3'.split(' ') >>> a, b, L ('a', 'b', ['1', '2', '3']) Today, if the number of variables on both sides of the equal sign doesn't match, an exception is raised (for google reference): ValueError: unpack list of wrong size This new syntax is very similar to the special parameter in function definitions that catches all excess arguments, as in def func(p, --> *args <--, **kw):, and so the semantics should be what everyone expects. Then, if we leave this limiting analogy with the *args parameter and allow the catch-the-rest variable to be anywhere in the left-hand side, we arrive at a splice syntax that reminds me a little of how prolog deals with lists: >>> a,*b,c = 'a b 1 2 3'.split(' ') >>> *a,b,c = b.split(' ') >>> a,b,c (['b'], '1', '2') I believe this would make a nice addition to the language. (Please cc me in response as I'm not subscribed to py-dev.) ...johahn

9 23

print "%X" % id(object()) not so nice
by James Y Knight 20 Nov '04

20 Nov '04

I think id() should never be returning a negative number. Both these behaviors are poor: In 2.3: >>> print "%X" % id(o) __main__:1: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up A5F48198 In 2.4: >>> print "%X" %id(o) -5FC84D08 Pointers are conventionally never treated or printed as signed. In 2.3 and before, it usually ended up okay, besides the warning, because "%X" had broken behavior. In 2.4, now it's ending up doing the wrong thing and printing a confusing value. I propose that id() always return a positive value. This means that it will sometimes have to return a long instead of an int, but, it already does that under some circumstances on some architectures. Comments? James

7 10

Confusion about os.urandom()
by Matthias Andreas Benkard 19 Nov '04

19 Nov '04

Hello there. I was just reading through http://www.python.org/2.4/highlights.html and noticed the following: os.urandom() has been added for systems that support a source of random data (entropy) At first, I was a bit stunned about the choice of name here. Why would anyone call this method urandom()? That confused me a bit, for, AFAICS, under Linux at least, /dev/random is the entropy pool and /dev/urandom is a PRNG (or rather, a source of random numbers which falls back to a PRNG when the entropy pool runs out of numbers). So I would not expect a method that is supposed to yield cryptographically secure random numbers to be called `urandom()'. Anyway, that might be non-intuitive (which is unusual in Python), but certainly not a severe bug. But then I noticed that if I rename /dev/urandom to something else (say, /dev/notrandomenough), os.urandom() (in Python 2.4b2) raises a NotImplementedError: Python 2.4b2 (#2, Nov 11 2004, 23:44:54) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.urandom(1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/os.py", line 693, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found >>> Now I'm really confused. Does os.urandom() use /dev/urandom under Linux? Either my brain has got a serious bug that makes me misunderstand the random(4) manpage, which states that "[w]hen read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver", or the implementation of os.urandom() is severely flawed. (BTW, I just checked Python 2.4c1. Judging from the source code, it seems to have the same behaviour.) That's what help(os.urandom) says: urandom(n) -> str Return a string of n random bytes suitable for cryptographic use. So it should be using /dev/random rather than /dev/urandom, shouldn't it? - Matthias A. Benkard

2 1

RELEASED Python 2.4, release candidate 1
by Anthony Baxter 19 Nov '04

19 Nov '04

On behalf of the Python development team and the Python community, I'm happy to announce the first release candidate of Python 2.4. Python 2.4c1 is a release candidate - 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 probably not suitable for production usage. At this point, we're particularly interested in build bugs. If you could grab the source archive, build it and then run the test suite, we'd appreciate it. http://www.python.org/2.4 Notable changes in rc1 include a handful of bug fixes, including a thread shutdown race bug. 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. This is the first release candidate of Python 2.4. Python 2.4 is now close to release - there should be few or no new features, merely bug fixes. Assuming no problems, we're looking at a final release around the end of November (if there are problems, there will be another release candidate). Please log any problems you have with this release in the SourceForge bug tracker (noting that you're using 2.4c1): http://sourceforge.net/bugs/?group_id=5470 Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

2 2

Misinformation in highlights webpage
by Batista, Facundo 19 Nov '04

19 Nov '04

In http://www.python.org/2.4/highlights.html it presents decimal between the "New or upgraded built-ins", while it should talk about it in "New or upgraded modules and packages". Should I post a bug or this is enough? (never know what to do regarding webpages). Thanks! Facundo Batista Desarrollo de Red fbatista(a)unifon.com.ar (54 11) 5130-4643 Cel: 15 5097 5024

1 0

python 2.3.5 release?
by Matthias Klose 19 Nov '04

19 Nov '04

Python 2.3.4 was released on 2004-05-27. According to the bi-annual release schedule that would assume another release from the 2.3 branch this year. Are people still interested in a formal 2.3.5 release? At least the 2.3 branch does have a couple of patches worth making a release. Is there anything that needs to be added before a 2.3.5 release is scheduled, or should we wait for the 2.4 release to identify patches that need to be backported to a potential 2.3.5 release? Thanks for any comment, Matthias

5 5