Mailman 3 March 2001 - Python-Dev

__credits__ and __author__ variables
by Guido van Rossum March 1, 2001

March 1, 2001

Ping just checked in this: > Log Message: > Add __author__ and __credits__ variables. > > > Index: tokenize.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/tokenize.py,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -C2 -r1.19 -r1.20 > *** tokenize.py 2001/03/01 04:27:19 1.19 > --- tokenize.py 2001/03/01 13:56:40 1.20 > *************** > *** 10,14 **** > it … [View More]

3 4

Finger error -- my apologies
by Eric S. Raymond March 1, 2001

March 1, 2001

I meant to accept this patch, but I think I rejected it instead. Sorry, Ping. Resubmit, plese, if I fooed up? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> It is the assumption of this book that a work of art is a gift, not a commodity. Or, to state the modern case with more precision, that works of art exist simultaneously in two "economies," a market economy and a gift economy. Only one of these is essential, however: a work of art can survive without the … [View More]

2 2

Re: [Python-Dev] just trying to catch up with the semantic
by Samuele Pedroni March 1, 2001

March 1, 2001

[Jeremy] > All your examples look like what is currently implemented. My > preference is that global kills the local-decl only in one scope. > I'll stick with that unless Guido disagrees. At least this will break fewer code. regards.

1 0

just trying to catch up with the semantic
by Samuele Pedroni March 1, 2001

March 1, 2001

Hi. I read the following CVS log from Jeremy: > Fix core dump in example from Samuele Pedroni: > > from __future__ import nested_scopes > x=7 > def f(): > x=1 > def g(): > global x > def i(): > def h(): > return x > return h() > return i() > return g() > > print f() > print x > > This kind of code didn't work correctly because x was treated as free > in i, … [View More]

2 1

PEP 236: an alternative to the __future__ syntax
by Martin v. Loewis March 1, 2001

March 1, 2001

> but where's the patch? Argh. It's now at http://www.informatik.hu-berlin.de/~loewis/python/directive.diff > other tools that parse Python will have to be adapted. Yes, that's indeed a problem. Initially, that syntax will be used only to denote modules that use nested scopes, so those tools would have time to adjust. > The __future__ hack doesn't need that. If it is *just* parsing, then yes. If it does any further analysis (e.g. "find definition (of a variable)" aka "find … [View More]

2 1

PEP 236: an alternative to the __future__ syntax
by Martin v. Loewis March 1, 2001

March 1, 2001

PEP 236 states that the intention of the proposed feature is to allow modules "to request that the code in module M use the new syntax or semantics in the current release C". It achieves this by introducing a new statement, the future_statement. This looks like an import statement, but isn't. The PEP author admits that 'overloading "import" does suck'. I agree (not surprisingly, since Tim added this QA item after we discussed it in email). It also says "But if we introduce a new keyword, that … [View More]

4 3

Re: [Python-checkins] CVS: python/dist/src/Objects funcobject.c,2.35,2.36
by Jeremy Hylton March 1, 2001

March 1, 2001

This change does not appear to solve the leaks, but it seems necessary for correctness. Jeremy

1 0

code objects leakin'
by Jeremy Hylton Feb. 28, 2001

Feb. 28, 2001

It looks like code objects are leaked with surprising frequency. I added a simple counter that records all code object allocs and deallocs. For many programs, the net is zero. For some, including setup.py and the regression test, it's much larger than zero. I've got no time to look at this before the beta, but perhaps someone else does. Even if it can't be fixed, it would be helpful to know what's going wrong. I am fairly certain that recursive functions are being leaked, even after … [View More]

1 0

[development doc updates]
by Fred L. Drake Feb. 28, 2001

Feb. 28, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/

1 0

A few small issues
by Ka-Ping Yee Feb. 28, 2001

Feb. 28, 2001

Hi. Here are some things i noticed tonight. 1. The error message for UnboundLocalError isn't really accurate. >>> def f(): ... x = 1 ... del x ... print x ... >>> f() Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 4, in f UnboundLocalError: local variable 'x' referenced before assignment >>> It's not a question of the variable being referenced "… [View More]before assignment" -- it's just that the variable is undefined. Better would be a straightforward message such as UnboundLocalError: local name 'x' is not defined This message would be consistent with the others: NameError: name 'x' is not defined NameError: global name 'x' is not defined 2. Why does imp.find_module('') succeed? >>> import imp >>> imp.find_module('') (None, '/home/ping/python/', ('', '', 5)) I think it should fail with "empty module name" or something similar. 3. Normally when a script is run, it looks like '' gets prepended to sys.path so that the current directory will be searched. But if the script being run is a symlink, the symlink is resolved first to an actual file, and the directory containing that file is prepended to sys.path. This leads to strange behaviour: localhost[1004]% cat > spam.py bacon = 5 localhost[1005]% cat > /tmp/eggs.py import spam localhost[1006]% ln -s /tmp/eggs.py . localhost[1007]% python eggs.py Traceback (most recent call last): File "eggs.py", line 1, in ? import spam ImportError: No module named spam localhost[1008]% python Python 2.1a2 (#23, Feb 11 2001, 16:26:17) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import spam >>> (whereupon the confused programmer says, "Huh? If *i* could import spam, why couldn't eggs?"). Was this a design decision? Should it be changed to always prepend ''? 4. As far as i can tell, the curses.wrapper package is inaccessible. It's obscured by a curses.wrapper() function in the curses package. >>> import curses.wrapper >>> curses.wrapper <function wrapper at 0x80ebe14> >>> import sys >>> sys.modules['curses.wrapper'] <module 'curses.wrapper' from '/home/ping/dev/python/dist/src/Lib/curses/wrapper.pyc'> I don't see any way around this other than renaming curses.wrapper. -- ?!ng "If I have not seen as far as others, it is because giants were standing on my shoulders." -- Hal Abelson [View Less]

5 8