Mailman 3 March 2001 - Python-Dev

Re: [Python-Dev] [Very Long 23kb] List of Patches to Go in 2.0.1
by Michael Hudson 28 Mar '01

28 Mar '01

Moshe Zadka <moshez(a)zadka.site.co.il> writes: > After labouring over the list of log messages for 2-3 days, I finally > have a tentative list of changes. I present it as a list of checkin > messages, complete with the versions. Sometimes I concatenated several > consecutive checkins into one -- "I fixed the bug", "oops, typo last > fix" and similar. > > Please go over the list and see if there's anything you feel should > not go. I think there are some that don't apply to 2.0.1: > Python/pythonrun.c, 2.128->2.129 > Fix memory leak with SyntaxError. (The DECREF was originally hidden > inside a piece of code that was deemed reduntant; the DECREF was > unfortunately *not* redundant!) and > Python/compile.c, 2.150->2.151 > Fix bug reported by Ka-Ping Yee: The compiler botched parsing function > parameters that contained both anonymous tuples and *arg or **arg. Ex: > def f(a, (b, c), *d): pass > > Fix the symtable_params() to generate names in the right order for > co_varnames slot of code object. Consider *arg and **arg before the > "complex" names introduced by anonymous tuples. aren't meaningful without the nested scopes stuff. But I guess you'll notice pretty quickly if I'm right... Otherwise, general encouragement! Please keep it up. Cheers, M. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp

2 1

Re: [Python-Dev] [Very Long 23kb] List of Patches to Go in 2.0.1
by aahz＠panix.com 28 Mar '01

28 Mar '01

Guido: >Aahz: >> >> I'm not sure about this, but it seems to me that the attribute change >> will generate a different .pyc. If I'm wrong about that, this patch >> as-is is fine with me; otherwise, I'd lobby to use the containment fix >> but not the attributes (assuming we're willing to use part of a patch). > > Adding attributes to xrange() can't possibly change the .pyc files. Okay, chalk another one up to ignorance. Another thought occurred to me in the shower, though: would this change the pickle of xrange()? If yes, should pickle changes also be prohibited in bugfix releases (in the PEP)? -- --- Aahz <*> (Copyright 2001 by aahz(a)pobox.com) Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 "Boost the stock market -- fire someone"

3 2

Re: [Python-Dev] [Very Long 23kb] List of Patches to Go in 2.0.1
by aahz＠panix.com 28 Mar '01

28 Mar '01

> > Okay, chalk another one up to ignorance. Another thought occurred to me > > in the shower, though: would this change the pickle of xrange()? If yes, > > should pickle changes also be prohibited in bugfix releases (in the PEP)? > > from the why-dont-you-just-try-it department: You're right, I should have tried it. I didn't because my shell account still hasn't set up Python 2.0 as the default version and I haven't yet set myself up to test beta/patch/CVS releases. <sigh> The more I learn, the more ignorant I feel.... -- --- Aahz <*> (Copyright 2001 by aahz(a)pobox.com) Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 "Boost the stock market -- fire someone"

1 0

SF bugs tracker?
by Jeremy Hylton 28 Mar '01

28 Mar '01

I've been unable to reach the bugs tracker today. Every attempt results in a document-contains-no-data error. Has anyone else had any luck? Jeremy

4 3

Function in os module for available disk space, why not?
by Dinu Gherman 27 Mar '01

27 Mar '01

I wrote on comp.lang.python today: > > is there a simple way (or any way at all) to find out for > any given hard disk how much free space is left on that > device? I looked into the os module, but either not hard > enough or there is no such function. Of course, the ideal > solution would be platform-independant, too... :) Is there any good reason for not having a cross-platform solution to this? I'm certainly not the first to ask for such a function and it certainly exists for all platforms, doesn't it? Unfortunately, OS problems like that make it rather impossi- ble to write truly cross-platform applications in Python, even if it is touted to be exactly that. I know that OS differ in the services they provide, but in this case it seems to me that each one *must* have such a function, so I don't understand why it's not there... Regards, Dinu -- Dinu C. Gherman ReportLab Consultant - http://www.reportlab.com ................................................................ "The only possible values [for quality] are 'excellent' and 'in- sanely excellent', depending on whether lives are at stake or not. Otherwise you don't enjoy your work, you don't work well, and the project goes down the drain." (Kent Beck, "Extreme Programming Explained")

17 39

setup.py is too aggressive
by Martin von Loewis 27 Mar '01

27 Mar '01

> It seems to me setup.py tries to build libraries even when it's > impossible E.g., I had to add the patch attached so I will get no > more ImportErrors where the module shouts at me that it could not > find a symbol. The more general problem here is that building of a module may fail: Even if a library is detected correctly, it might be that additional libraries are needed. In some cases, it helps to put the correct module line into Modules/Setup (which would have helped in your case); then setup.py will not attempt to build the module. However, there may be cases where a module cannot be build at all: either some libraries are missing, or the module won't work on the system for some other reason (e.g. since the system library it relies on has some bug). There should be a mechanism to tell setup.py not to build a module at all. Since it is looking into Modules/Setup anyway, perhaps a *excluded* dbm syntax in Modules/Setup would be appropriate? Of course, makesetup needs to be taught such a syntax. Alternatively, an additional configuration file or command line options might work. In any case, distributors are certainly advised to run the testsuite and potentially remove or fix modules for which the tests fail. Regards, Martin

3 4

distutils change breaks code, Pyfort
by Paul F. Dubois 27 Mar '01

27 Mar '01

The requirement of a version argument to the distutils command breaks Pyfort and many of my existing packages. These packages are not intended for use with the distribution commands and a package version number would be meaningless. I will make a new Pyfort that supplies a version number to the call it makes to setup. However, I think this change to distutils is a poor idea. If the version number would be required for the distribution commands, let *them* complain, perhaps by setting a default value of time.asctime(time.gmtime()) or something that the distribution commands could object to. I apologize if I missed an earlier discussion of this change that seems to be in 2.1b2 but not 2.1b1, as I am new to this list. Paul

3 2

Simple generators, round 2
by Neil Schemenauer 27 Mar '01

27 Mar '01

I've got a different implementation. There are no new keywords and its simpler to wrap a high level interface around the low interface. http://arctrix.com/nas/python/generator2.diff What the patch does: Split the big for loop and switch statement out of eval_code2 into PyEval_EvalFrame. Add a new "why" flag for ceval, WHY_SUSPEND. It is similar to WHY_RETURN except that the frame value stack and the block stack are not touched. The frame is also marked resumable before returning (f_stackbottom != NULL). Add two new methods to frame objects, suspend and resume. suspend takes one argument which gets attached to the frame (f_suspendvalue). This tells ceval to suspend as soon as control gets back to this frame. resume, strangely enough, resumes a suspended frame. Execution continues at the point it was suspended. This is done by calling PyEval_EvalFrame on the frame object. Make frame_dealloc clean up the stack and decref f_suspendvalue if it exists. There are probably still bugs and it slows down ceval too much but otherwise things are looking good. Here are some examples (the're a little long and but illustrative). Low level interface, similar to my last example: # print 0 to 999 import sys def g(): for n in range(1000): f = sys._getframe() f.suspend((n, f)) return None, None n, frame = g() while frame: print n n, frame = frame.resume() Let's build something easier to use: # Generator.py import sys class Generator: def __init__(self): self.frame = sys._getframe(1) self.frame.suspend(self) def suspend(self, value): self.frame.suspend(value) def end(self): raise IndexError def __getitem__(self, i): # fake indices suck, need iterators return self.frame.resume() Now let's try Guido's pi example now: # Prints out the frist 100 digits of pi from Generator import Generator def pi(): g = Generator() k, a, b, a1, b1 = 2L, 4L, 1L, 12L, 4L while 1: # Next approximation p, q, k = k*k, 2L*k+1L, k+1L a, b, a1, b1 = a1, b1, p*a+q*a1, p*b+q*b1 # Print common digits d, d1 = a/b, a1/b1 while d == d1: g.suspend(int(d)) a, a1 = 10L*(a%b), 10L*(a1%b1) d, d1 = a/b, a1/b1 def test(): pi_digits = pi() for i in range(100): print pi_digits[i], if __name__ == "__main__": test() Some tree traversals: from types import TupleType from Generator import Generator # (A - B) + C * (E/F) expr = ("+", ("-", "A", "B"), ("*", "C", ("/", "E", "F"))) def postorder(node): g = Generator() if isinstance(node, TupleType): value, left, right = node for child in postorder(left): g.suspend(child) for child in postorder(right): g.suspend(child) g.suspend(value) else: g.suspend(node) g.end() print "postorder:", for node in postorder(expr): print node, print This prints: postorder: A B - C E F / * + Cheers, Neil

8 17

Release 2.0.1: Heads Up
by Martin v. Loewis 26 Mar '01

26 Mar '01

> I have volunteered to be the Patch Czar (see the PEP!) for the 2.0.1 > release Great! > So please, let me know of bugfixes that you need or want in Python > 2.0. In addition to your procedures (which are all very reasonable), I'd like to point out that Tim has created a 2.0.1 patch class on the SF patch manager. I hope you find the time to review the patches in there (which should not be very difficult at the moment). This is meant for patches which can't be proposed in terms of 'cvs diff' commands; for mere copying of code from the mainline, this is probably overkill. Also note that I have started to give a detailed analysis of what exactly has changed in the NEWS file of the 2.0 maintainance branch - I'm curious to know what you think about procedure. If you don't like it, feel free to undo my changes there. Regards, Martin

3 2

PEP 6 cleanup
by aahz＠panix.com 26 Mar '01

26 Mar '01

Now that Moshe has agreed to be Patch Czar for 2.0.1, I'd like some clarification/advice on a couple of issues before I release the next draft: Issues To Be Resolved What is the equivalent of python-dev for people who are responsible for maintaining Python? (Aahz proposes either python-patch or python-maint, hosted at either python.org or xs4all.net.) Does SourceForge make it possible to maintain both separate and combined bug lists for multiple forks? If not, how do we mark bugs fixed in different forks? (Simplest is to simply generate a new bug for each fork that it gets fixed in, referring back to the main bug number for details.)

1 0