Mailman 3 May 2006 - Python-Dev

Re: [Python-Dev] lambda in Python
by Jay Parlar 04 May '06

04 May '06

On May 4, 2006, at 6:00 AM, Talin wrote: > xahlee <xah <at> xahlee.org> writes: > >> Today i ran into one of Guido van Rossum's blog article titled >> ?Language Design Is Not Just Solving Puzzles? at >> http://www.artima.com/weblogs/viewpost.jsp?thread=147358 > > The confrontational tone of this post makes it pretty much impossible > to have a reasonable debate on the subject. I'd suggest that if you > really want to be heard (instead of merely having that "I'm right" > feeling) that you try a different approach. > > -- Talin Xah Lee is a well known troll, he does stuff like this on c.l.p. all the time. Best to just ignore him, he doesn't listen to reason. Jay P.

5 4

test failures in test_ctypes (HEAD)
by Guido van Rossum 04 May '06

04 May '06

I see test failures in current HEAD on my Google Red Hat Linux desktop that the buildbots don't seem to have: ./python -E -tt ../Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- errors occurred; run in verbose mode for details More details from running this manually: $ ./python ../Lib/test/test_ctypes.py . . (lots of passing tests; then:) . test_gl (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glu (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR test_glut (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR ====================================================================== ERROR: test_gl (ctypes.test.test_find.Test_OpenGL_libs) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py", line 42, in setUp self.glut = CDLL(lib_glut) File "/home/guido/projects/python/trunk/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion ====================================================================== ERROR: test_glu (ctypes.test.test_find.Test_OpenGL_libs) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py", line 42, in setUp self.glut = CDLL(lib_glut) File "/home/guido/projects/python/trunk/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion ====================================================================== ERROR: test_glut (ctypes.test.test_find.Test_OpenGL_libs) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py", line 42, in setUp self.glut = CDLL(lib_glut) File "/home/guido/projects/python/trunk/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion ---------------------------------------------------------------------- This seems libglut related -- I don't know what that is but find /lib /usr/lib -name \*glut\* produces this output: /usr/lib/libglut.so.3 /usr/lib/libglut.so.3.7 -- --Guido van Rossum (home page: http://www.python.org/~guido/)

4 4

Time since the epoch
by Sanghyeon Seo 04 May '06

04 May '06

Hello, Python library reference 6.11 says, "The epoch is the point where the time starts. On January 1st of that year, at 0 hours, the "time since the epoch'' is zero. For Unix, the epoch is 1970." To me this seems to suggest that the epoch may vary among platforms and implementations as long as it's consistent. Am I correct? For example, does it make sense to file bug reports to Python projects assuming that time.time() returns seconds since the Unix epoch? I am asking because currently Python and IronPython returns very different values for time.time() even if they run on the same computer and at the same time. Seo Sanghyeon

2 1

mail to talin is bouncing
by Guido van Rossum 04 May '06

04 May '06

Sorry to bother the list -- talin, mail to you is bouncing: ----- The following addresses had permanent fatal errors ----- <talin(a)viridia.org> ----- Transcript of session follows ----- ... while talking to viridia.org >>> RCPT To:<talin(a)viridia.org> <<< 550 message to verify they are valid." -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] Date for DC-area Python sprint?
by A.M. Kuchling 03 May '06

03 May '06

I found out that May 27th is on Memorial Day weekend, and some people will doubtless have travel plans. Let's aim for the next Saturday, June 3rd. (No intersection with the Need for Speed sprint; oh well.) I'll post a detailed announcement and set up a wiki page when things are nailed down, but it looks like the sprint can be from 9 or 10AM to 4PM, or thereabouts. Wireless will be available. Does anyone else want to organize sprints for that day? --amk

1 0

signature object issues (to discuss while I am out of contact)
by Brett Cannon 03 May '06

03 May '06

Signature objects (which has been lightly discussed on python-3000, but I realize should be retargeted to 2.6 since there is no incompatibility problems) are the idea of having an object that represents the parameters of a function for easy introspection. But there are two things that I can't quite decide upon. One is whether a signature object should be automatically created for every function. As of right now the PEP I am drafting has it on a per-need basis and have it assigned to __signature__ through a built-in function or putting it 'inspect'. Now automatically creating the object would possibly make it more useful, but it could also be considered overkill. Also not doing it automatically allows signature objects to possibly make more sense for classes (to represent __init__) and instances (to represent __call__). But having that same support automatically feels off for some reason to me. The second question is whether it is worth providing a function that will either figure out if a tuple and dict representing arguments would work in calling the function. Some have even suggested a function that returns the actual bindings if the call were to occur. Personally I don't see a huge use for either, but even less for the latter version. If people have a legit use case for either please speak up, otherwise I am tempted to keep the object simple. Now, I probably won't be participating in this discussion for the rest of the week. I am driving down to the Bay Area from Seattle for the next few days and have no idea what my Internet access will be like. But I wanted to get this discussion going since it kept me up last night thinking about it and I would like to sleep by knowing python-dev, in its infinite wisdom <grin>, is considering the issues. =) -Brett

4 7

Seeking students for the Summer of Code
by Neal Norwitz 03 May '06

03 May '06

There is less than a week left before students must submit a final application. There are a bunch of ideas up on the wiki: http://wiki.python.org/moin/SummerOfCode/ The wiki has instructions for how to submit a proposal. There are many different areas including: core language features, libraries, and applications. This is a great opportunity to get real coding experience. Not to mention the chance to work with a nice and fun group of people. The earlier you submit an application, the more feedback you can get to improve it and increase your liklihood of getting accepted. Feel free to contact me if you have any questions. Cheers, n

1 0

more pyref: continue in finally statements
by Fredrik Lundh 03 May '06

03 May '06

the language reference says: continue may only occur syntactically nested in a for or while loop, but not nested in a function or class definition or finally statement within that loop. /.../ It may occur within an except or else clause. The restriction on occurring in the try clause is implementor's laziness and will eventually be lifted. and it looks like the new compiler still has the same issue: $ python test.py File "test.py", line 5: continue SyntaxError: 'continue' not supported inside 'finally' clause how hard would it be to fix this ? (shouldn't the "try clause" in the note read "finally clause", btw? "continue" within the "try" suite seem to work just fine...) </F>

4 4

Re: [Python-Dev] elimination of scope bleeding ofiteration variables
by Delaney, Timothy (Tim) 02 May '06

02 May '06

Josiah Carlson wrote: > for line in lines: > line = line.rstrip() > ... Exactly the use case I was thinking of (and one I used yesterday BTW). I'm -1 on *dis*allowing reusing a name bound in a for loop in any construct i.e. +1 for the status quo. Tim Delaney

2 1

Positional-only Arguments
by Benji York 02 May '06

02 May '06

I've not followed the PEP 3102 (keyword-only arguments) discussion closely enough to know if this has been mentioned, but we were discussing a need at work today for the ability to enforce position-only arguments. The specific instance was an argument that was intended to be used as a positional argument which a group had began using as a keyword argument instead. There was no way for the users to know it was intended for positional use only. And it makes refactoring the signature difficult. Of course you could use *args from the get-go, but ugly signatures as default isn't nice. Is there any reason to pursue the idea, or this mostly a misguided desire for symmetry? -- Benji York

4 4