Re: [Python-Dev] why different between staticmethod and classmethod on non-callable object?
the three types: function, classmethod, staticmethod are descriptors. but staticmethod's __get__ return the orignal value, others return object of instancemethod. (from souce in Objects/funcobject.c) so the staticmethod just like a wrap that make the wrapped object 'frozen'. like in your example. is it right? the name and document are mis-understanded. thanks 2009/9/2 P.J. Eby : > At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote: >> >> Greg Ewing wrote: >>> >>> Benjamin Peterson wrote: >>> It depends on whether you're keeping the "callable" object around or not. Somebody could add a __call__ method later. >>> >>> Good point. Removing the check sounds like the >>> right thing to do, then. >> >> Both classmethod & staticmethod are documented as having a *function* >> (callable, as I interprete that) as their single argument. Seems reasonable >> to me. Turning the argument into a function after the fact seems like a >> really esoteric use case. > > The main use case for staticmethod is to prevent __get__ from being called > on an object retrieved from a class or an instance. It just happens that > the most common types of objects you'd want to do that on are functions. > > However, if for some reason you intend to make a *descriptor* available as > an attribute (via a class default), then wrapping it with staticmethod is > the only easy way to do it. > > For example, if you're writing a class whose instances have an attribute > that holds a "property" instance, and you want to provide a class-level > default, the simplest way to do it is to wrap the default property instance > with staticmethod, so that it's not treated as a property of the > class/instance. > > (Property instances are of course not callable.) > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/s7v7nislands%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
On 2 Sep 2009, at 00:10 , Greg Ewing wrote: Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. IIRC, the default return value of a Smalltalk method is self, not the last thing evaluated. Methods yes (and that's one of the few Smalltalk design "features" I consider truly dumb, considering it has message cascading), but I was referring to blocks rather than methods and the return value of blocks is the last evaluated expression. (And no, that's not going to happen in Python either -- the BDFL has rejected similar suggestions on previous occasions.) I know. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Decorator syntax
Hi All, This is my first post to python-dev so I will briefly introduce myself: My name is Rob Cliffe and I am a commercial programmer living in London, UK. I have some 30 years of programming experience but have only been using Python for a couple of years. First I want to say what a fantastic language Python is. It is THE best language for development in my opinion, and a joy to use. My specific issue: I eventually got my head round decorator syntax and realised that what came after the '@' was (basically) a function that took a function as argument and returned a function as result. However it seems to me unPythonesque (i.e. an exception to Python's normal consistency) that the syntax of what follows the '@' should be restricted to either a single (function) identifier or a single (function) identifier with an argument list. The example I tried, which seems not an unreasonable sort of thing to do, was along the lines of: def deco1(func): def deco2(func): DecoList = [deco1, deco2] @DecoList[0]# NO - CAUSES SYNTAX ERROR def foo(): pass I am sure other guys have their own examples. I am of course not the first person to raise this issue, and I see that Guido has a "gut feeling" against allowing a general expression after the '@'. BUT - a general expression can be "smuggled in" very easily as a function argument: def Identity(x): return x @Identity(DecoList[0])# THIS WORKS def foo(): pass So - the syntax restriction seems not only inconsistent, but pointless; it doesn't forbid anything, but merely means we have to do it in a slightly convoluted (unPythonesque) way. So please, Guido, will you reconsider? Best wishes Rob Cliffe___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
Crossposting to Python-ideas, I asked for the same change to the grammar a couple months back on python-ideas. See http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 I'm all for it, but you'll have to convince Guido that this won't result in confusing to read code. My own examples, unfortunately did not advance your cause, as Guido explained, "My brain hurts trying to understand all this. I don't think this bodes well as a use case for a proposed feature." :-D The trouble is that I was using lambdas upon lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come up with some simple, clear use cases though, and I think he might still be persuadable to make a simple change to the grammar. — Carl Johnson Rob Cliffe wrote: > Hi All, > This is my first post to python-dev so I will briefly introduce myself: My > name is Rob Cliffe and I am a commercial programmer living in London, UK. I > have some 30 years of programming experience but have only been using Python > for a couple of years. > First I want to say what a fantastic language Python is. It is THE best > language for development in my opinion, and a joy to use. > > My specific issue: > I eventually got my head round decorator syntax and realised that what came > after the '@' was (basically) a function that took a function as argument > and returned a function as result. > However it seems to me unPythonesque (i.e. an exception to Python's normal > consistency) that the syntax of what follows the '@' should be restricted to > either a single (function) identifier or a single (function) identifier with > an argument list. > The example I tried, which seems not an unreasonable sort of thing to do, > was along the lines of: > > def deco1(func): > > def deco2(func): > > > DecoList = [deco1, deco2] > > @DecoList[0] # NO - CAUSES SYNTAX ERROR > def foo(): > pass > > I am sure other guys have their own examples. > > I am of course not the first person to raise this issue, and I see that > Guido has a "gut feeling" against allowing a general expression after the > '@'. > > BUT - a general expression can be "smuggled in" very easily as a function > argument: > > def Identity(x): return x > > @Identity(DecoList[0]) # THIS WORKS > def foo(): > pass > > So - the syntax restriction seems not only inconsistent, but pointless; it > doesn't forbid anything, but merely means we have to do it in a slightly > convoluted (unPythonesque) way. So please, Guido, will you reconsider? > > Best wishes > Rob Cliffe ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] Decorator syntax
I actually encountered this for the first time yesterday and didn't realise that the decorator syntax was limited in this way (I was mentally preparing a blog entry when these emails arrived). What I needed to do was turn a Python function into a .NET event handler in IronPython. The simple case is this: from System import EventHandler @EventHandler def on_event(sender, event): # do stuff... This works fine of course, but then I needed to use the 'typed' form which is like this: @EventHandler[HtmlEventArgs] def on_event(sender, event): # do stuff... I didn't realise this was invalid syntax - nor the neat trick with the identity function to bypass the limitation. Michael 2009/9/2 Carl Johnson > Crossposting to Python-ideas, > > I asked for the same change to the grammar a couple months back on > python-ideas. > > See > http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 > > I'm all for it, but you'll have to convince Guido that this won't > result in confusing to read code. My own examples, unfortunately did > not advance your cause, as Guido explained, "My brain hurts trying to > understand all this. I don't think this bodes well as a use case for a > proposed feature." :-D The trouble is that I was using lambdas upon > lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come > up with some simple, clear use cases though, and I think he might > still be persuadable to make a simple change to the grammar. > > > — Carl Johnson > > Rob Cliffe wrote: > > > Hi All, > > This is my first post to python-dev so I will briefly introduce myself: > My > > name is Rob Cliffe and I am a commercial programmer living in London, > UK. I > > have some 30 years of programming experience but have only been using > Python > > for a couple of years. > > First I want to say what a fantastic language Python is. It is THE best > > language for development in my opinion, and a joy to use. > > > > My specific issue: > > I eventually got my head round decorator syntax and realised that what > came > > after the '@' was (basically) a function that took a function as argument > > and returned a function as result. > > However it seems to me unPythonesque (i.e. an exception to Python's > normal > > consistency) that the syntax of what follows the '@' should be restricted > to > > either a single (function) identifier or a single (function) identifier > with > > an argument list. > > The example I tried, which seems not an unreasonable sort of thing to do, > > was along the lines of: > > > > def deco1(func): > > > > def deco2(func): > > > > > > DecoList = [deco1, deco2] > > > > @DecoList[0]# NO - CAUSES SYNTAX ERROR > > def foo(): > > pass > > > > I am sure other guys have their own examples. > > > > I am of course not the first person to raise this issue, and I see that > > Guido has a "gut feeling" against allowing a general expression after the > > '@'. > > > > BUT - a general expression can be "smuggled in" very easily as a function > > argument: > > > > def Identity(x): return x > > > > @Identity(DecoList[0])# THIS WORKS > > def foo(): > > pass > > > > So - the syntax restriction seems not only inconsistent, but pointless; > it > > doesn't forbid anything, but merely means we have to do it in a slightly > > convoluted (unPythonesque) way. So please, Guido, will you reconsider? > > > > Best wishes > > Rob Cliffe > ___ > Python-ideas mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-ideas > -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
On 2 Sep 2009, at 12:15 , Rob Cliffe wrote: @Identity(DecoList[0])# THIS WORKS def foo(): pass For what it's worth, you don't need an id function, you can simply write @itemgetter(0)(decorators) def foo(): 'whatever' or @decorators.__getitem__(0) def foo(): 'whatever' ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
Greg Ewing wrote: > Xavier Morel wrote: > >> I fail to grasp the unpredictability of "the last expression >> evaluated in the body of a function is its return value". > > It's unpredictable in the sense that if you're writing > a function that's not intended to return a value, you're > not thinking about what the last call you make in the > function returns, so to a first approximation it's just > some random value. > > I often write code that makes use of the fact that falling > off the end of a function returns None. This has been a > documented part of the Python language from the beginning, > and changing it would break a lot of code for no good > reason. It also means adding a debugging message, assertion, or otherwise side-effect free statement can change the return value of the function. Not cool. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
Not advocating a change, merely pointing out that it's how Ruby works. K > -Original Message- > From: [email protected] > [mailto:[email protected]] On Behalf > Of Nick Coghlan > Sent: 2. september 2009 11:12 > To: Greg Ewing > Cc: [email protected] > Subject: Re: [Python-Dev] default of returning None hurts performance? > It also means adding a debugging message, assertion, or otherwise > side-effect free statement can change the return value of the function. > Not cool. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a buildbot
2009/8/22 Paul Moore : > 2009/8/22 Jeroen Ruigrok van der Werven : >> -On [20090822 21:30], Paul Moore ([email protected]) wrote: >>>I've just had a look on python.org, but couldn't immediately see a >>>pointer to instructions on what the process is to set up a buildbot. >> >> http://wiki.python.org/moin/BuildBot comes to mind. > > Ah, thanks. I'll take a look. I saw on planet Python that the buildbots have currently been shut down. I guess this makes my question fairly irrelevant for the moment, then :-( Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote: So - the syntax restriction seems not only inconsistent, but pointless; it doesn't forbid anything, but merely means we have to do it in a slightly convoluted (unPythonesque) way. So please, Guido, will you reconsider? Indeed, it's a silly inconsistent restriction. When it was first added I too suggested that any expression be allowed after the @, rather than having a uniquely special restricted syntax. I argued from consistency of grammar standpoint. But Guido was not persuaded. Good luck to you. :) Here's some of the more relevant messages from the thread back when the @decorator feature was first introduced: http://mail.python.org/pipermail/python-dev/2004-August/046654.html http://mail.python.org/pipermail/python-dev/2004-August/046659.html http://mail.python.org/pipermail/python-dev/2004-August/046675.html http://mail.python.org/pipermail/python-dev/2004-August/046711.html http://mail.python.org/pipermail/python-dev/2004-August/046741.html http://mail.python.org/pipermail/python-dev/2004-August/046753.html http://mail.python.org/pipermail/python-dev/2004-August/046818.html James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bugs discovered by researchers at Case Western Reserve University
Dear Developers, I am a Ph.D student from Case Western Reserve University, specialized at software engineering. Our recent approach analyzes bugs that are being fixed in the issue database, and tries to discover any latent bug instances that are the same as the fixed bug but are left unfixed. We have found some spurious code in your project in this approach, and pointed out these code by comments (sometimes also with patches) to the fixed bugs in the issue DB from which it is discovered as follows: Issue 6817: http://bugs.python.org/issue6817 (A new issue, created following Amaury's comments) Issue 2620: http://bugs.python.org/issue2620 Issue 3139: http://bugs.python.org/issue3139 Issue 5705: http://bugs.python.org/issue5705 We hope that we have discovered some real bugs for you. Any comments or suggestions are GREATLY appreciated, since your opinions are very, very precious to us. Boya -- BOYA SUN Computer Science Division Electrical Engineering & Computer Science Department 513 Olin Building Case Western Reserve University 10900 Euclid Avenue Cleveland, OH 44106 [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
On Wed, Sep 2, 2009 at 10:35 AM, James Y Knight wrote: > On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote: > >> So - the syntax restriction seems not only inconsistent, but pointless; it >> doesn't forbid anything, but merely means we have to do it in a slightly >> convoluted (unPythonesque) way. So please, Guido, will you reconsider? > > Indeed, it's a silly inconsistent restriction. When it was first added I too > suggested that any expression be allowed after the @, rather than having a > uniquely special restricted syntax. I argued from consistency of grammar > standpoint. But Guido was not persuaded. Good luck to you. :) > > Here's some of the more relevant messages from the thread back when the > @decorator feature was first introduced: > http://mail.python.org/pipermail/python-dev/2004-August/046654.html > http://mail.python.org/pipermail/python-dev/2004-August/046659.html > http://mail.python.org/pipermail/python-dev/2004-August/046675.html > http://mail.python.org/pipermail/python-dev/2004-August/046711.html > http://mail.python.org/pipermail/python-dev/2004-August/046741.html > http://mail.python.org/pipermail/python-dev/2004-August/046753.html > http://mail.python.org/pipermail/python-dev/2004-August/046818.html I think Guido may have a point about not allowing any arbitrary expression. But I do think that if it allows calls, it should also at least support the itemgetter syntax, for which there seems to be a demonstrable use case. But that's just adding on another special case, so it might be simpler to allow arbitrary expressions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
Erik Bray wrote: I think Guido may have a point about not allowing any arbitrary expression. But I do think that if it allows calls, it should also at least support the itemgetter syntax, for which there seems to be a demonstrable use case. But that's just adding on another special case, so it might be simpler to allow arbitrary expressions. It's not the same issue, of course, but note that str.format's object specification "language" supports item and attribute access. And that's the extent of what it allows. If you wanted to do this for decorators, I'm not sure how easy it would be to restrict the expression inside the brackets, or if you'd even want to. str.format has all of this baked-in, it doesn't use any sort of grammar. Eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
James Y Knight wrote: On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote: So - the syntax restriction seems not only inconsistent, but pointless; it doesn't forbid anything, but merely means we have to do it in a slightly convoluted (unPythonesque) way. So please, Guido, will you reconsider? Indeed, it's a silly inconsistent restriction. When it was first added I too suggested that any expression be allowed after the @, rather than having a uniquely special restricted syntax. I argued from consistency of grammar standpoint. But Guido was not persuaded. Good luck to you. :) [snip] I can see no syntactic reason to restrict what can appear after the @. If someone chooses to abuse it then that's unPythonic, but not illegal. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a buildbot
> I saw on planet Python that the buildbots have currently been shut > down. I guess this makes my question fairly irrelevant for the moment, > then :-( That was a misunderstanding. It was only the community buildbots, and Grig Gheorghiu is working on restoring them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py_CmpToRich removed, alternatives for comparison?
For blender we have a number of types defined in the C/API like meshes, lamps, metaballs, nurbs etc that dont make sense with some of richcmp's operations. A problem I have is that in python 3.1 the Py_CmpToRich function is removed. Should we copy Py_CmpToRich into our source tree? Otherwise we have fairly long cmp functions that have Py_CmpToRich inline. For C extension writers what is the suggested method for comparing types where Py_LT, Py_GT Py_GE etc are not useful? Since people sometimes ask why use py3.1, we're doing a rewrite that wont be ready for quite some time. -- - Campbell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bugs discovered by researchers at Case Western Reserve University
On Wed, Sep 2, 2009 at 08:19, Boya Sun wrote: > Dear Developers, > > I am a Ph.D student from Case Western Reserve University, specialized at > software engineering. Our recent approach analyzes bugs that are being > fixed in the issue database, and tries to discover any latent bug instances > that are the same as the fixed bug but are left unfixed. We have found some > spurious code in your project in this approach, and pointed out these code > by comments (sometimes also with patches) to the fixed bugs in the issue DB > from which it is discovered as follows: > > Issue 6817: http://bugs.python.org/issue6817 (A new issue, created following > Amaury's comments) > Issue 2620: http://bugs.python.org/issue2620 > Issue 3139: http://bugs.python.org/issue3139 > Issue 5705: http://bugs.python.org/issue5705 I quickly re-opened 2620 and 5705 so we don't lose track of the fact that new code has been attached. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
People, please note that the discussion has shifted to python-ideas and further comments should happen over there. Carl did the right thing to shift it there, although cross-posting once the conversation redirection has occurred is not needed. hoping-google-wave-will-have-a-permanent-redirector-for-conversations-ly yrs, Brett On Wed, Sep 2, 2009 at 03:34, Carl Johnson wrote: > Crossposting to Python-ideas, > > I asked for the same change to the grammar a couple months back on > python-ideas. > > See > http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787 > > I'm all for it, but you'll have to convince Guido that this won't > result in confusing to read code. My own examples, unfortunately did > not advance your cause, as Guido explained, "My brain hurts trying to > understand all this. I don't think this bodes well as a use case for a > proposed feature." :-D The trouble is that I was using lambdas upon > lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come > up with some simple, clear use cases though, and I think he might > still be persuadable to make a simple change to the grammar. > > > — Carl Johnson > > Rob Cliffe wrote: > >> Hi All, >> This is my first post to python-dev so I will briefly introduce myself: My >> name is Rob Cliffe and I am a commercial programmer living in London, UK. I >> have some 30 years of programming experience but have only been using Python >> for a couple of years. >> First I want to say what a fantastic language Python is. It is THE best >> language for development in my opinion, and a joy to use. >> >> My specific issue: >> I eventually got my head round decorator syntax and realised that what came >> after the '@' was (basically) a function that took a function as argument >> and returned a function as result. >> However it seems to me unPythonesque (i.e. an exception to Python's normal >> consistency) that the syntax of what follows the '@' should be restricted to >> either a single (function) identifier or a single (function) identifier with >> an argument list. >> The example I tried, which seems not an unreasonable sort of thing to do, >> was along the lines of: >> >> def deco1(func): >> >> def deco2(func): >> >> >> DecoList = [deco1, deco2] >> >> @DecoList[0] # NO - CAUSES SYNTAX ERROR >> def foo(): >> pass >> >> I am sure other guys have their own examples. >> >> I am of course not the first person to raise this issue, and I see that >> Guido has a "gut feeling" against allowing a general expression after the >> '@'. >> >> BUT - a general expression can be "smuggled in" very easily as a function >> argument: >> >> def Identity(x): return x >> >> @Identity(DecoList[0]) # THIS WORKS >> def foo(): >> pass >> >> So - the syntax restriction seems not only inconsistent, but pointless; it >> doesn't forbid anything, but merely means we have to do it in a slightly >> convoluted (unPythonesque) way. So please, Guido, will you reconsider? >> >> Best wishes >> Rob Cliffe > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_CmpToRich removed, alternatives for comparison?
2009/9/2 Campbell Barton : > For blender we have a number of types defined in the C/API like > meshes, lamps, metaballs, nurbs etc that dont make sense with some of > richcmp's operations. > A problem I have is that in python 3.1 the Py_CmpToRich function is removed. > > Should we copy Py_CmpToRich into our source tree? > Otherwise we have fairly long cmp functions that have Py_CmpToRich inline. > > For C extension writers what is the suggested method for comparing > types where Py_LT, Py_GT Py_GE etc are not useful? Return Py_NotImplemented when you get them. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
