[Python-Dev] Re: Introduction (original) (raw)

Jeffery Roberts g9robjef@cdf.toronto.edu
Mon, 26 May 2003 12:51:05 -0400 (EDT)

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 . > 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=3DE7aloRodrigues?=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=3DE7aloRodrigues?=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 tpmethods, and is scanned once by PyTypeReady. > > 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 PyTypeReady 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 > > PyFindMethod. With PyFindMethod 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 PyFindMethod > call, I could of course modify PyFindMethod. 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 > > PyFindMethod 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 * > PyFindMethod(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->obtype in PyFindMethodInChain(), which is called by PyFindMethod(). > Except for module objects, this seems to be right. I've run > Python against a lot of Python modules, but none seems > to call PyFindMethod 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 tpcallnr 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