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. =3D) > > 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". =3D) > > > 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. =3D) > > 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@OCF.Berkeley.EDU> > Reply-To: drifty@alum.berkeley.edu > To: Jeffery Roberts <g9robjef@cdf.toronto.edu> > CC: Tim Peters <tim.one@comcast.net>, python-dev@python.org > Subject: Re: [Python-Dev] Introduction > > Jeffery Roberts wrote: > > Thanks for all of your replies. The front-end rewrite sounds especiall= y > > 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. =3D) > > 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@python.org, python-dev@python.org > To: python-announce@python.org > From: Barry Warsaw <barry@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: > > =09http://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 > > =09http://www.python.org/2.2.3/NEWS.txt > > There are a small number of minor incompatibilities with Python 2.2.2; > for details see: > > =09http://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@python.org > To: Barry Warsaw <barry@python.org> > From: Jack Jansen <Jack.Jansen@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@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@python.org> > Subject: Re: [Python-Dev] Of what use is commands.getstatus() > To: skip@pobox.com > Cc: python-dev@python.org > > > I was reading the docs for the commands module and noticed getstatus() = seems > > to be completely unrelated to getstatusoutput() and getoutput(). I tho= ught, > > "I'll correct the docs. They must be wrong." Then I looked at command= s.py > > and saw the docs are correct. It's the function definition which is we= ird. > > Of what use is it to return 'ls -ld file'? Based on its name I would h= ave > > 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 th= e > > existence of os.stat, os.listdir, etc. Should it be deprecated or modi= fied > > 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@python.org> > Subject: Re: [Python-Dev] Descriptor API > To: =3D?iso-8859-1?Q?Gon=3DE7alo_Rodrigues?=3D <op73418@mail.telepac.pt> > Cc: python-dev@python.org > > > I was doing some tricks with metaclasses and descriptors in Python 2.2 = and > > stumbled on the following: > > > > >>> class test(object): > > ... a =3D 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 =3D C() > x.meth() # prints 42 > x.meth =3D 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: =3D?iso-8859-1?Q?Gon=3DE7alo_Rodrigues?=3D <op73418@mail.telepac.pt= > > To: <python-dev@python.org> > Subject: Re: [Python-Dev] Descriptor API > Date: Fri, 23 May 2003 15:34:14 +0100 > > > ----- Original Message ----- > From: "Guido van Rossum" <guido@python.org> > To: "Gon=E7alo Rodrigues" <op73418@mail.telepac.pt> > Cc: <python-dev@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 =3D 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 ca= se? > > > > 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 =3D C() > > x.meth() # prints 42 > > x.meth =3D 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@python.org> > Subject: Re: [Python-Dev] Need advice, maybe support > To: Christian Tismer <tismer@tismer.com> > Cc: python-dev@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 :-)= =2E > > > > 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@python.org > http://mail.python.org/mailman/listinfo/python-dev > > > End of Python-Dev Digest >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4