g9robjef at cdf
May 26, 2003, 9:51 AM
Post #11 of 26
(820 views)
Permalink
|
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 [at] OCF>
> Reply-To: drifty [at] alum
> To: Jeffery Roberts <g9robjef [at] cdf>
> CC: Tim Peters <tim.one [at] comcast>, python-dev [at] python
> 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 [at] python, python-dev [at] python
> To: python-announce [at] python
> From: Barry Warsaw <barry [at] python>
> 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 [at] python
> To: Barry Warsaw <barry [at] python>
> From: Jack Jansen <Jack.Jansen [at] cwi>
>
>
> 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 [at] cwi>, 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 [at] python>
> Subject: Re: [Python-Dev] Of what use is commands.getstatus()
> To: skip [at] pobox
> Cc: python-dev [at] python
>
> > 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 [at] python>
> Subject: Re: [Python-Dev] Descriptor API
> To: =?iso-8859-1?Q?Gon=E7alo_Rodrigues?= <op73418 [at] mail>
> Cc: python-dev [at] python
>
> > 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 [at] mail>
> To: <python-dev [at] python>
> Subject: Re: [Python-Dev] Descriptor API
> Date: Fri, 23 May 2003 15:34:14 +0100
>
>
> ----- Original Message -----
> From: "Guido van Rossum" <guido [at] python>
> To: "Gonçalo Rodrigues" <op73418 [at] mail>
> Cc: <python-dev [at] python>
> 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 [at] python>
> Subject: Re: [Python-Dev] Need advice, maybe support
> To: Christian Tismer <tismer [at] tismer>
> Cc: python-dev [at] python
>
> > > 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 [at] python
> http://mail.python.org/mailman/listinfo/python-dev
>
>
> End of Python-Dev Digest
>
|
1
