Mailman 3 May 2003 - Python-Dev

I'm tagging the Python 2.2.3 tree
by Barry Warsaw 31 May '03

31 May '03

No more changes please. -Barry

1 0

Release question
by Jack Diederich 30 May '03

30 May '03

The PEPs are pretty thorough about how to announce and build releases. My question is about cvs, branching, and feature freezes. I joined python-dev after the 2.2 release so I haven't been around for a 'round number' release yet. I'm guessing 2.3 is in bugfix only mode. When is 2.4 tagged, and what is the timeframe on that? (the linux kernel generally waits a while before starting the next dev branch). Assume I asked intelligent questions about related things and please answer them too *wink*. Thanks, -jack

2 1

Python 2.2.3 docs freeze
by Fred L. Drake, Jr. 30 May '03

30 May '03

I'm going to generate the Python 2.2.3 documentation packages now, so please no more checkins in the Doc/ tree on the release22-maint branch. Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

New free service! AID:0951460048
by g_a_l_l_a＠mail333.com 29 May '03

29 May '03

We are pleased to inform you that on the Gallery-A site has opened a new service. Now you can absolutely FREE use the best paintings from our gallery to decorate the screen of your computer. Insert your favorite painting into the frame of your monitor. http://www.gallery-a.ru/luxury.php With best regards Boris Lipner Sorry if that information not interesting for You and we disturb You with our message! For removing yor address from this mailing list just replay this message with word 'unsubscribe' in subject field or simple click this link: http://www.gallery-a.ru/unsubscribe.php?e=cHl0aG9uLWRldkBweXRob24ub3JnOjE2O…

1 0

Python bug 544473 - bugfix candidate - was it applied?
by Skip Montanaro 29 May '03

29 May '03

Several times today I had a Queue object (Python 2.2.2) wind up deadlocked with its fsema locked but its queue full (apparently threads are waiting to put more items in the queue than it's supposed to hold). Looking back at the cvs log for the Queue module I see this message revision 1.15 date: 2002/04/19 00:11:31; author: mhammond; state: Exp; lines: +33 -14 Fix bug 544473 - "Queue module can deadlock". Use try/finally to ensure all Queue locks remain stable. Includes test case. Bugfix candidate. but no indication that was ever applied to the maint22 branch. I'm not suggesting that this bug fix will solve my problem (it's probably a bug in my code), but it seems that it should have been applied but wasn't. Should it be applied at this point or is 2.2.3 too close to release? Skip

3 3

Plans for Python 2.2.3 final
by Barry Warsaw 29 May '03

29 May '03

I've not heard about any showstoppers for Python 2.2.3. Just to let everyone know, I'd like to release it Some PM, this Friday night, EDT. I'll need to coordinate specifics with Fred and Tim, but expect a check-in freeze on the branch at some point Friday, with a release to follow shortly thereafter. -Barry

3 4

Refinance your home with lowest rates lqjq c cipem
by Loren Mcdaniel 29 May '03

29 May '03

FREE MORTGAGE QUOTE & BEST POSSIBLE RATES ! ------------------------------------------- There are over 89,000 mortgage companies in the U.S., which means the process of finding the best loan for you can be a very difficult one.Let us do the hard work for you! Simply spend 1 minute to fill out the short form, then press the submit button, and we take it from there... finding the best deals possible, and getting the lenders to contact you! It's short, it's simple, it's free, and it will save you thousands of dollars! * Home Improvement, Refinance, Second Mortgage, Home Equity Loans, and More! Even with less than perfect or NO credit! You will qualify for the best possible rate. Do NOT miss the chance to refinance at record low rates, so act now... http://mymortagenow.com/3/index.asp?RefID=383102 remove me http://www.mortage-area.com/Auto/index.htm eamor d aoiotcm auvwi zt v u awokik tn gz kxcgc bchjfq wz gzsrh bmj

1 0

install debian package
by Rob van Putten 27 May '03

27 May '03

Hi there, I am not sure if this is the right place for my comment but here it is; I tried to install python-dev on my new Debian woody system but it returned an error because it tried to remove the modutils package (probably because it was incompatible) The problem was solved after I upgraded the modutils package (2.4.21-2) I am no debain package expert but it looks to me as if the modutils package should be upgraded from the python-dev package (if this is somehow possible off course :-) Hope this helps to improve the debian package. Regards, Rob

2 1

RE: Decimal class
by Kevin Jacobs 27 May '03

27 May '03

On Mon, 26 May 2003, Tim Peters wrote: > [Kevin Jacobs] > > Anyhow, the next big thing I want to do is to make Decimal instances > > immutable like other Python numeric types, so they can be used as > > hash keys, so common values can be re-used, and some of the code can > > be simplified. > > Offhand I didn't see anything in the code that mutates any inputs, so I > expect it's at worst close. But this kind of discussion should be in > public, so others can jump in too (especially Eric!). I agree 100%. Does anyone else have feelings for or against having mutable Decimal instances? In the mean time, I will prepare a patch to do this so we can evaluate the practical effects on the code. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs(a)theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com

5 4

Re: Introduction
by Jeffery Roberts 27 May '03

27 May '03

Thanks for that reply Brett. It is really helpful. I'm currently in Ottawa at the GCC summit trying to sponge some knowledge but I will begin following your advice when I get back home later this week. Thanks again ! Jeff > I know I learned a lot from working on patches and bugs. It especially > helps if you jump in on a patch that is being actively worked on and can > ask how something works. Otherwise just read the source until your eyes > bleed and curse anyone who doesn't write extensive documentation for > code. =) > > There also has been mention of the AST branch. I know I plan on working > on that after I finish going through the bug and patch backlog. Only > trouble is that the guys who actually fully understand it (Jeremy, Tim, > and Neal) are rather busy so it is going to be a "jump in the pool and > drown and hope your flailing manages to at least generate something > useful but you die and come back in another life wiser and able to > attempt again until you stop drowning and manage to only get sick from > gulping down so much chlorinated water". =) > > > Check out > > > > http://www.python.org/dev/ > > > > for orientation, and leave your spare time at the door <wink>. > > > > I will vouch for the loss of spare time. This has become a job. Best > job ever, though. =) > > The only big piece of advice I can offer is to just make sure you are > nice and cordial on the list; there is a low tolerance for jerks here. > Don't take this as meaning to not take a stand on an issue! All I am > saying is realize that email does not transcribe humor perfectly and > until the list gets used to your personal writing style you might have > to just make sure what you write does not come off as insulting. > > -Brett > > > > --__--__-- > > Message: 9 > Date: Thu, 22 May 2003 20:21:20 -0700 > From: "Brett C." <bac(a)OCF.Berkeley.EDU> > Reply-To: drifty(a)alum.berkeley.edu > To: Jeffery Roberts <g9robjef(a)cdf.toronto.edu> > CC: Tim Peters <tim.one(a)comcast.net>, python-dev(a)python.org > Subject: Re: [Python-Dev] Introduction > > Jeffery Roberts wrote: > > Thanks for all of your replies. The front-end rewrite sounds especially > > interesting. I'm going to look into that. Is the entire front end > > changing (ie scan/parse/ast) or just the AST structure ? > > > > If you have any more information or directions please let me know. > > > > It is just a new AST. Redoing/replacing pgen is something else > entirely. =) > > The branch that this is being developed under in CVS is ast-branch. > There is a incomplete README in Python/compile.txt that explains the > basic idea and direction. > > -Brett > > > > --__--__-- > > Message: 10 > Date: Thu, 22 May 2003 23:30:45 -0400 > Cc: python-list(a)python.org, python-dev(a)python.org > To: python-announce(a)python.org > From: Barry Warsaw <barry(a)python.org> > Subject: [Python-Dev] RELEASED Python 2.2.3c1 > > I'm happy to announce the release of Python 2.2.3c1 (release candidate > 1). This is a bug fix release for the stable Python 2.2 code line. > Barring any critical issues, we expect to release Python 2.2.3 final by > this time next week. We encourage those with an interest in a solid > 2.2.3 release to download this candidate and test it on their code. > > The new release is available here: > > http://www.python.org/2.2.3/ > > Python 2.2.3 has a large number of bug fixes and memory leak patches. > For full details, see the release notes at > > http://www.python.org/2.2.3/NEWS.txt > > There are a small number of minor incompatibilities with Python 2.2.2; > for details see: > > http://www.python.org/2.2.3/bugs.html > > Perhaps the most important is that the Bastion.py and rexec.py modules > have been disabled, since we do not deem them to be safe. > > As usual, a Windows installer and a Unix/Linux source tarball are made > available, as well as tarballs of the documentation in various forms. > At the moment, no Mac version or Linux RPMs are available, although I > expect them to appear soon after 2.2.3 final is released. > > On behalf of Guido, I'd like to thank everyone who contributed to this > release, and who continue to ensure Python's success. > > Enjoy, > -Barry > > > > --__--__-- > > Message: 11 > Date: Fri, 23 May 2003 13:42:20 +0200 > Subject: Re: [Python-Dev] RELEASED Python 2.2.3c1 > Cc: python-dev(a)python.org > To: Barry Warsaw <barry(a)python.org> > From: Jack Jansen <Jack.Jansen(a)cwi.nl> > > > On Friday, May 23, 2003, at 05:30 Europe/Amsterdam, Barry Warsaw wrote: > > > I'm happy to announce the release of Python 2.2.3c1 (release candidate > > 1). > > Oops, that suddenly went *very* fast, I though I had until the > weekend... > > Is there a chance I could get #723495 still in before 2.2.3 final? I > was also hoping to find a fix for #571343, but I don't have a patch yet > (although I'll try to get one up in the next few hours). > -- > Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > > > --__--__-- > > Message: 12 > Date: Fri, 23 May 2003 09:11:35 -0400 > From: Guido van Rossum <guido(a)python.org> > Subject: Re: [Python-Dev] Of what use is commands.getstatus() > To: skip(a)pobox.com > Cc: python-dev(a)python.org > > > I was reading the docs for the commands module and noticed getstatus() seems > > to be completely unrelated to getstatusoutput() and getoutput(). I thought, > > "I'll correct the docs. They must be wrong." Then I looked at commands.py > > and saw the docs are correct. It's the function definition which is weird. > > Of what use is it to return 'ls -ld file'? Based on its name I would have > > guessed its function was > > > > def getoutput(cmd): > > """Return status of executing cmd in a shell.""" > > return getstatusoutput(cmd)[0] > > > > This particular function dates from 1990, so it clearly can't just be > > deleted, but it seems completely superfluous to me, especially given the > > existence of os.stat, os.listdir, etc. Should it be deprecated or modified > > to do (what I think is) the obvious thing? > > That whole module wasn't thought out very well. I recently tried to > use it and found that the strip of the trailing \n on getoutput() is > also a counterproductive feature. I suggest that someone should > design a replacement, perhaps to live in shutil, and then we can > deprecate it. Until then I would leave it alone. Certainly don't > "fix" it by doing something incompatible. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > --__--__-- > > Message: 13 > Date: Fri, 23 May 2003 10:06:05 -0400 > From: Guido van Rossum <guido(a)python.org> > Subject: Re: [Python-Dev] Descriptor API > To: =?iso-8859-1?Q?Gon=E7alo_Rodrigues?= <op73418(a)mail.telepac.pt> > Cc: python-dev(a)python.org > > > I was doing some tricks with metaclasses and descriptors in Python 2.2 and > > stumbled on the following: > > > > >>> class test(object): > > ... a = property(lambda: 1) > > ... > > >>> print test.a > > <property object at 0x01504D20> > > >>> print test.a.__set__ > > <method-wrapper object at 0x01517220> > > >>> print test.a.fset > > None > > > > What this means in practice, is that if I want to test if a > > descriptor is read-only I have to have two tests: One for custom > > descriptors, checking that getting __set__ does not barf and another > > for property, checking that fset returns None. > > Why are you interested in knowing whether a descriptor is read-only? > > > So, why doesn't getting __set__ raise AttributeError in the above case? > > This is a feature. The presence of __set__ (even if it always raises > AttributeError when *called*) signals this as a "data descriptor". > The difference between data descriptors and others is that a data > descriptor can not be overridden by putting something in the instance > dict; a non-data descriptor can be overridden by assignment to an > instance attribute, which will store a value in the instance dict. > > For example, a method is a non-data descriptor (and the prevailing > example of such). This means that the following example works: > > class C(object): > def meth(self): return 42 > > x = C() > x.meth() # prints 42 > x.meth = lambda: 24 > x.meth() # prints 24 > > > Is this a bug? If it's not, it sure is a (minor) feature request > > from my part :-) > > Because of the above explanation, the request cannot be granted. > > You can test the property's fset attribute however to tell whether a > 'set' argument was passed to the constructor. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > --__--__-- > > Message: 14 > From: =?iso-8859-1?Q?Gon=E7alo_Rodrigues?= <op73418(a)mail.telepac.pt> > To: <python-dev(a)python.org> > Subject: Re: [Python-Dev] Descriptor API > Date: Fri, 23 May 2003 15:34:14 +0100 > > > ----- Original Message ----- > From: "Guido van Rossum" <guido(a)python.org> > To: "Gon�alo Rodrigues" <op73418(a)mail.telepac.pt> > Cc: <python-dev(a)python.org> > Sent: Friday, May 23, 2003 3:06 PM > Subject: Re: [Python-Dev] Descriptor API > > > > > I was doing some tricks with metaclasses and descriptors in Python 2.2 > and > > > stumbled on the following: > > > > > > >>> class test(object): > > > ... a = property(lambda: 1) > > > ... > > > >>> print test.a > > > <property object at 0x01504D20> > > > >>> print test.a.__set__ > > > <method-wrapper object at 0x01517220> > > > >>> print test.a.fset > > > None > > > > > > What this means in practice, is that if I want to test if a > > > descriptor is read-only I have to have two tests: One for custom > > > descriptors, checking that getting __set__ does not barf and another > > > for property, checking that fset returns None. > > > > Why are you interested in knowing whether a descriptor is read-only? > > > > Introspection dealing with a metaclass that injected methods in its > instances depending on a descriptor. In other words, having fun with > Python's wacky tricks. > > > > So, why doesn't getting __set__ raise AttributeError in the above case? > > > > This is a feature. The presence of __set__ (even if it always raises > > AttributeError when *called*) signals this as a "data descriptor". > > The difference between data descriptors and others is that a data > > descriptor can not be overridden by putting something in the instance > > dict; a non-data descriptor can be overridden by assignment to an > > instance attribute, which will store a value in the instance dict. > > > > For example, a method is a non-data descriptor (and the prevailing > > example of such). This means that the following example works: > > > > class C(object): > > def meth(self): return 42 > > > > x = C() > > x.meth() # prints 42 > > x.meth = lambda: 24 > > x.meth() # prints 24 > > > > > Is this a bug? If it's not, it sure is a (minor) feature request > > > from my part :-) > > > > Because of the above explanation, the request cannot be granted. > > > > Thanks for the reply (and also to P. Eby, btw). I was way off track when I > sent the email, because it did not occured to me that property was a type > implementing __get__ and __set__. With this piece of info connecting the > dots the idea is just plain foolish. > > > You can test the property's fset attribute however to tell whether a > > 'set' argument was passed to the constructor. > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > With my best regards, > G. Rodrigues > > > > --__--__-- > > Message: 15 > Date: Fri, 23 May 2003 10:39:10 -0400 > From: Guido van Rossum <guido(a)python.org> > Subject: Re: [Python-Dev] Need advice, maybe support > To: Christian Tismer <tismer(a)tismer.com> > Cc: python-dev(a)python.org > > > > The other is the new style where the PyMethodDef > > > array is in tp_methods, and is scanned once by PyType_Ready. > > > > Right, again. Now, under the hopeful assumption that every > > sensible extension module that has some types to publish also > > does this through its module dictionary, I would have the > > opportunity to cause PyType_Ready being called early enough > > to modify the method table, before any of its methods is used > > at all. > > Dangerous assumption! It's not inconceivable that a class would > instantiate some of its own classes as part of its module > initialization. > > > > 3rd party modules that have been around for a while are likely to use > > > Py_FindMethod. With Py_FindMethod you don't have a convenient way to > > > store the pointer to the converted table, so it may be better to > > > simply check your bit in the first array element and then cast to a > > > PyMethodDef or a PyMethodDefEx array based on what the bit says (you > > > can safely assume that all elements of an array are the same size :-). > > > > Hee hee, yeah. Of course, if there isn't a reliable way to > > intercept method table access before the first Py_FindMethod > > call, I could of course modify Py_FindMethod. For instance, > > a modified, new-style method table might be required to always > > start with a dummy entry, where the flags word is completely > > -1, to signal having been converted to new-style. > > Why so drastic? You could just set a reserved bit.f > > > ... > > > > >>If that approach is trustworthy, I also could drop > > >>the request for these 8 bits. > > > > > > Sure. Ah, a bit in the type would work just as well, and > > > Py_FindMethod *does* have access to the type. > > > > You think of the definition in methodobject.c, as it is > > > > """ > > /* Find a method in a single method list */ > > > > PyObject * > > Py_FindMethod(PyMethodDef *methods, PyObject *self, char *name) > > """ > > > > , assuming that self always is not NULL, but representing a valid > > object with a type, and this type is already referring to the > > methods table? > > Right. There is already code that uses self->ob_type in > Py_FindMethodInChain(), which is called by Py_FindMethod(). > > > Except for module objects, this seems to be right. I've run > > Python against a lot of Python modules, but none seems > > to call Py_FindMethod with a self parameter of NULL. > > I don't think it would be safe to do so. > > > If that is true, then I can patch a small couple of > > C functions to check for the new bit, and if it's not > > there, re-create the method table in place. > > This is music to me ears. But... > > > > Well, there is a drawback: > > I *do* need two bits, and I hope you will allow me to add this > > second bit, as well. > > > > The one, first bit, tells me if the source has been compiled > > with Stackless and its extension stuff. Nullo problemo. > > I can then in-place modify the method table in a compatible > > way, or leave it as it is, bny default. > > But then, this isn't sufficient to set this bit then, like an > > "everything is fine, now" relief. This is so, since this is *still* > > an old module, and while its type's method tables have been > > patched, the type is still not augmented by new slots, like > > the new tp_call_nr slots (and maybe a bazillion to come, soon). > > The drawback is, that I cannot simply replace the whole type > > object, since type objects are not represented as object > > pointers (like they are now, most of the time, in the dynamic > > heaptype case), but they are constant struct addresses, where > > the old C module might be referring to. > > > > So, what I think to need is no longer 9 bits, but two of them: > > One that says "everything great from the beginning", and another > > one that says "well, ok so far, but this is still an old object". > > > > I do think this is the complete story, now. > > Instead of requiring nine bits, I'm asking for two. > > But this is just *your options; I also can live with one bit, > > but then I have to add a special, invalid method table entry > > that just serves for this purpose. > > In order to keep my souce code hack to the minimum, I'd really > > like to ask for the two bits in the typeobject flags. > > OK, two bits you shall have. Don't spend them all at once! > > > Thanks so much for being so supportive -- chris > > Anything to keep ctual stackless support out of the core. :-) > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > --__--__-- > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > > > End of Python-Dev Digest >

1 0