[Python-Dev] 2.4.1c1 March 10th, 2.4.1 March 17th
Ok - Fred and Martin and I will be cutting 2.4.1c1 on March 10th, and (assuming no problems) 2.4.1 on March 17th. Apologies for the delay - my time's been all consumed lately with doing lighting and sound design for a show. (Any Melbournites who're interested, we're putting on Michael Palin's play "The Weekend" from next Thursday - see www.stagtheatre.org for more details ) -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OK, time to retire (was: Re: python-dev Summary for 2005-01-16 through 2005-01-31)
Steve Holden wrote: Michele Simionato wrote [on c.l.py]: Brett Cannon: [... python-dev summary ... boilerplate change ...] +1 for this idea. The summary looks much better now :) Keep the good work going, Sorry, but i have to disagree. I hope you won't take this reply personally, Michele, since it's directed to all c.l.py readers, as well as (particularly) at Python users who [unlike you] are mostly take and rather less give. Although this is inherently the nature of open source, in certain cases this can be taken too far. [SNIP] Now, the reason for this specific rant is this: I can tell a cry for help when I see one. Brett has done a magnificent job of providing python-dev summaries since Andrew decided he'd had enough, and he is to be congratulated for it. I managed to offload another bunch of work on him (moderation of various troublesome PyCon mailing lists), but at least I was able to recompense him by letting him into PyCon for nothing. [SNIP] But frankly, I think it's time someone else stood up and said "Brett, you've done a magnificent job. Hesitant though I am about replacing you, I would like to volunteer for the task, because only when you are free from the burden of writing the python-dev summaries will we see what else you are capable of". Since I am at best an intermittent reader of python-dev I can say this without fear of having to stand up myself. [SNIP] [I am going to use this to reply to both Steve and Martin] As Steve mentioned above, he can spot a cry for help when he sees one. I think the problem is that I am a total sucker when it comes to the Python community and python-dev. Anyone who has been on the python-dev list for as long as I have been a participant has most likely seen my almost yearly "thank you" emails I send the list (which there will probably be another one of once I choose where I am going to pursue my doctorate; I have acceptances but I am still waiting to here back from 9 more schools). Usually it is just me gushing to python-dev, thanking the list for how Python has gotten me where I am today. And that statement is completely sincere; python-dev has sculpted me into the programmer that I am (does this mean I can blame python-dev for my own buggy code? =). And for that I will be eternally grateful to all of the wonderful people I have gotten to work with and know on this list. It has also made me want to help people to get involved on python-dev in hopes others would benefit from python-dev the same way I have. Granted, python-dev tends not to attract people like I was when I started getting involved (a philosophy degree and 4 CS courses does not equal a good programmer by default =), but I have always hoped that through my efforts some other people could come to enjoy hacking on Python, learn some things, and advance the language. But I think the big problem is that the Summaries have become a "gift" in the truest sense of the word. I lost all personal benefit from the Summaries over a year ago. Initially I learned a ton from all of the reading I was doing and the research required to understand what the heck people were talking about. But I have graduated from "The School of Hard Knocks". At this point I do the Summaries entirely altruistically, giving back what I can to the community in a way that I know benefits many people which happens to have zero benefit to me now. The Summaries consume what little free time I do have for Python which is unfortunate. I have always hoped I would get to the point in my programming abilities that I would be a larger asset to python-dev as a programmer than as a writer. I would like to think I have reached that point finally after my over two and a half years on the list (I can't believe I first posted to the list on June 17, 2002!). So, to make sure I don't squander what time I do have for Python waiting for a possible replacement that might never come, I have decided that I am going to stop doing the python-dev Summaries after PyCon; the Summary covering the last half of March 2005 will be it for me. Hopefully I will be more valuable as an active participant on python-dev again instead of as a passive listener who just happens to chime in on occasion and squash a simple bug when I am procrastinating from doing my homework. This has been a long time coming and I needed a swift kick in the ass to finally get me to stop. I thank you, Steve, for giving me that kick like the English gentleman you are. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: python-dev Summary for 2005-01-16 through 2005-01-31
Steve Holden wrote: Now, the reason for this specific rant is this: I can tell a cry for help when I see one. Brett has done a magnificent job of providing python-dev summaries since Andrew decided he'd had enough, and he is to be congratulated for it. I managed to offload another bunch of work on him (moderation of various troublesome PyCon mailing lists), but at least I was able to recompense him by letting him into PyCon for nothing. The more I participate, the more I can relate to Eric Raymond's notion of a "gift society". Volunteers give their contributions to the community just because they want to, and they may get recognition in return. But because these are gifts, you can just stop giving them away at any time, and nobody should feel bad about doing so. The community only is only entitled to the contributor saying so - finding somebody else to step in is indeed optional. I don't actually know whether Brett would prefer to hand over the python-dev summaries to somebody else, but if he wants to, he could just *stop* publishing them, with nobody taking over, and my appreciation of this contribution would not change at all. Continuing it until a new volunteer steps forward is, as I said, truly optional. I still recall when Tim Peters reappeared in the net (even though I haven't been around long enough to remember him disappear), and I know I didn't understand all the cheering and praising (I do now, of course). So their isn't anything wrong with taking a vacation from a project for some time, not even if the vacation takes a few years :-) Enough ranting. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & returning NotImplemented (or not)
On Tue, Mar 01, 2005 at 11:45:43PM +1000, Nick Coghlan wrote: > Interesting. In that case, my other suggestion was to have raising > NotImplementedError from a special method be the equivalent of returning > NotImplemented (which makes life much easier for a class like Decimal which > has an internal method for doing the type conversion). NotImplementedError has nothing to do with the NotImplemented singleton. It's unfortunate about the naming. IMO, Decimal should be returning NotImplemented instead of raising TypeError. That could be considered a bug but I'd file it under new functionality for the purposes of backporting (i.e. fix it in 2.5 only). Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Legacy bugs on SF
Title: RE: [Python-Dev] Legacy bugs on SF [Reinhold Birkenfeld] #- The month is over now, so what to do with them? The "month" is like a minimum time limit. I got separated and moved to my parent house. I still don't have internet connection, so I have this work a bit overdue. But I'll continue it, and eventually will reach the bugs where I alerted, and will close it, and will review the others (be aware that I'm not alerting every bug, I try to check every one when possible to see if it's still a bug, if was fixed, if the context changed to it has no sense any more, etc...). #- Note that there are other very old bugs, e.g. in the #- "Platform-specific" #- group, which I think may be closed too. Ok. . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Legacy bugs on SF
Hello, still in 2004, this comment was added to old bugs with groups Python2.*: """ Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". """ The month is over now, so what to do with them? Note that there are other very old bugs, e.g. in the "Platform-specific" group, which I think may be closed too. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & returning NotImplemented (or not)
Raymond Hettinger wrote: Try to address this in a larger context than decimal. The same sort of logic is present in sets.py and in datetime objects. Interesting. In that case, my other suggestion was to have raising NotImplementedError from a special method be the equivalent of returning NotImplemented (which makes life much easier for a class like Decimal which has an internal method for doing the type conversion). Then a class ("NotImplementedTypeError"?) that inherited from both NotImplementedError and TypeError could be used to fix the problem in a fairly backward compatible way - the PyNumber machinery would see the NotImplemented error, and try the other available operators before falling back to generating its own TypeError, while direct calls with invalid arguments would still be raising a subclass of TypeError, so existing code to catch TypeError from direct calls would continue to function. I didn't suggest this initially, since I didn't realise Decimal wasn't the only class with the problem, and I'm sure messing with PyNumber_* isn't possible for the 2.4 series :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Decimal & returning NotImplemented (or not)
> A recent question on c.l.p pointed out that the 2.4 Decimal implementation > raises TypeError directly for operator arguments it doesn't understand, > instead > of returning NotImplemented. > > Obviously, this creates problems for anyone trying to define a class that > 'plays > nicely' with Decimal (but does not inherit from Decimal), since their > __rop__ > methods never get called - Decimal's TypeError gets in the way. Try to address this in a larger context than decimal. The same sort of logic is present in sets.py and in datetime objects. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Decimal & returning NotImplemented (or not)
A recent question on c.l.p pointed out that the 2.4 Decimal implementation raises TypeError directly for operator arguments it doesn't understand, instead of returning NotImplemented. Obviously, this creates problems for anyone trying to define a class that 'plays nicely' with Decimal (but does not inherit from Decimal), since their __rop__ methods never get called - Decimal's TypeError gets in the way. I had another look at the PEP and didn't see anything on this topic, and I can't recall any discussion on the topic either on this list, or directly with Raymond and Facundo (Google doesn't have anything, either). My current thoughts run as follows: 1. The standard binary operations (that is, '/', '*', '+', '-', '%', '**', '//', divmod(), cmp()) should be returning NotImplemented instead of raising TypeError directly. 2. The method-only operations should continue to raise TypeErrors 3. Invocations via Context methods should continue to raise TypeErrors I was going to say this couldn't be fixed for Python 2.4 because it was a semantic change. But I modified my local copy to work this way, and the full Decimal test suite passed without any issue. For syntax-based access, the bad call still results in a TypeError from the PyNumber_* machinery, and there isn't anything in the docs that says anything about whether a bad operand in a direct call to a special method results in NotImplemented being returned or TypeError being raised. So, 2 questions: 1. Should Python 2.5's C implementation of Decimal follow the standard numeric coercion rules as described above? 2. Is it reasonable to class this as a bugfix and fix the Python version for 2.4.2? (2.4.1's a bit too soon for my liking) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: python-dev Summary for 2005-01-16 through 2005-01-31
Michele Simionato wrote [on c.l.py]: Brett Cannon: [... python-dev summary ... boilerplate change ...] +1 for this idea. The summary looks much better now :) Keep the good work going, Sorry, but i have to disagree. I hope you won't take this reply personally, Michele, since it's directed to all c.l.py readers, as well as (particularly) at Python users who [unlike you] are mostly take and rather less give. Although this is inherently the nature of open source, in certain cases this can be taken too far. I have a long history of doing things, and an equally long history giving up doing them. This stems from a personal belief that organic growth (IMHO the healthiest type) will only be engendered by variety. I was the Chairman of the Sun UK User Group once. When I was elected I said I would serve for two years, and when I resigned after two years many people said to me "Steve, please reconsider your decision". I observed, perhaps somewhat cynically, that most of the people who said this were motivated by the wish to avoid the pain of locating and electing a new chairman. Guess what ... when I refused to reconsider they found a new chairman, who was at least as good as me (I thought he was better), and life carried on. If you were to ask a member of the Sun UK User Group now the name of their second chairman I'd be very surprised if they had any idea who the hell Steve Holden was. (Historical note: the first chairman was Chris Brown, and nobody will remember him either). Now, the reason for this specific rant is this: I can tell a cry for help when I see one. Brett has done a magnificent job of providing python-dev summaries since Andrew decided he'd had enough, and he is to be congratulated for it. I managed to offload another bunch of work on him (moderation of various troublesome PyCon mailing lists), but at least I was able to recompense him by letting him into PyCon for nothing. I can say this because I am confident that nobody will even think of suggesting that Brett's contribution to the Python community doesn't entitle him to a free place at PyCon. I suspect most readers of this list would feel the same about Guido (I certainly hope so, because he too is a free-loader this year :-). I would actually like a free place at PyCon to represent recognition of significant contributions to the Python community, but there is a conflict here with another of my goals (raising funds for the PSF). But frankly, I think it's time someone else stood up and said "Brett, you've done a magnificent job. Hesitant though I am about replacing you, I would like to volunteer for the task, because only when you are free from the burden of writing the python-dev summaries will we see what else you are capable of". Since I am at best an intermittent reader of python-dev I can say this without fear of having to stand up myself. Oops, I'm rambling. I guess what I'm trying to say boils down to "Ask not what the Python community can do for you ...", and anyone who can't provide the remainder of the analogy is too young to consider themselves a victim of this post, and can claim a free ticket until they are old enough ti understand what history is. I like to think that although I don't make frequent checkins to the code base I do *something* to engender the Python community spirit (though I don't consider my own interpretation of that spirit to uniquely define it), and I'm damned sure Brett has done his share. It would be great if just a *few* more people who are currently consuming the fruits of our labors would stop sitting on the sidelines shouting "great job!" and roll their sleeves up. I hope I'll be able to put these remarks in a corporate context for PyCon - which astute readers will have noticed will be my last PyCon as chairman. I am happy to say that Andrew Kuchling has finally admitted his lust for power and confirmed that he is prepared to act as chairman for 2006, and I wish him well. More later one-more-thing-given-up-ly y'rs - steve ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python Dev] PEP 309
Steven Bethard wrote: (I'm also secretly hoping that map, filter, reduce, etc. will be moved to the functional module in the future, maybe in Python 3.0. But that's probably just my love for list comprehensions and generator expressions speaking.) ;-) Given Guido's stated desire to get rid of those three, but also given the fact that sometimes they're just plain clearer than the equivalent list comp (e.g. performing a type conversion on an entire list), having the functional module as a place to eventually put them seemed like a fine idea to me. I'm actually half-tempted to suggest that those three functions should be aliased in the functional module for 2.5 (in addition to being in builtins - ala the contents of the exceptions module). I also agree with your other point - with a functional module in place, it becomes more feasible to give the functional programming folks a few extra tools without impacting too badly on those people that *aren't* interested in FP related stuff. Cheers, Nick. Maybe we should open a book on the next method to make it into functional. Compose, perhaps? -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com