Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
>> I still fail to see the rationale for removing these >> two methods. > > I believe there was a thread (in January 2008) with a decision to keep > qsize() but to drop empty() and full(). That's something different: even if there was a decision, it doesn't mean that there was a rationale, and that the rationale was correct. I see that you proposed to remove the methods because they are unreliable. I still think this classification is incorrect: they are *not* unreliable. They do what they do correctly and reliably. Looking at the discussion (on python-3000), I don't see that an actual decision was made. You proposed it, there was a *lot* of objections. Guido proposed a compromise (without indicating whether he was in favor of the removal in the first place). There was then still opposition both to leaving qsize, and to change anything at all - and then you removed the methods. At this point, I do request that the patch is reverted completely (i.e. that the documentation is restored), and that the qualification "not reliable!" is removed from the doc strings of the methods, as it is factually incorrect. 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
[Python-Dev] Regexp 2.7
Hello, Matthew Barnett has been doing a lot of work on the regular expressions engine (it seems he hasn't finished yet) under http://bugs.python.org/issue2636. However, the patches are really huge and touch all of the sre internals. I wonder what the review process can be for such patches? Is there someone knowledgeable enough to be able to review them? Regards Antoine. ___ 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] Regexp 2.7
> Matthew Barnett has been doing a lot of work on the regular expressions engine > (it seems he hasn't finished yet) under http://bugs.python.org/issue2636. > However, the patches are really huge and touch all of the sre internals. I > wonder what the review process can be for such patches? Is there someone > knowledgeable enough to be able to review them? Traditionally, Fredrik Lundh has reviewed sre patches. Not sure whether he is interested in that anymore, though. 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] Pickler/Unpickler API clarification
Michael Haggerty wrote: A similar effect could *almost* be obtained without accessing the memos by saving the pickled primer itself in the database. The unpickler would be primed by using it to load the primer before loading the record of interest. But AFAIK there is no way to prime new picklers, because there is no guarantee that pickling the same primer twice will result in the same id->object mapping in the pickler's memo. Would it help if, when creating a pickler or unpickler, you could specify another pickler or unpickler whose memo is used to initialise the memo of the new one? Then you could keep the pickler that you used to pickle the primer and "fork" new picklers off it, and similarly with the unpicklers. -- Greg ___ 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] Pickler/Unpickler API clarification
Antoine Pitrou wrote: If these strings are not interned, then perhaps they should be. I think this is a different problem. Even if the strings are interned, if you start with a fresh pickler each time, you get a copy of the strings in each pickle. What he wants is to share strings between different pickles. -- Greg ___ 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] Python wins Linux New Media Award for Best Open Source Programming Language
On Sat, Mar 7, 2009 at 9:32 AM, Lie Ryan wrote: The prize was Martin von Löwis of the Python Foundation on behalf of the Python community itself. >>> >>> This is a funny translation from German-to-English. :-) >>> >>> But yeah, a good one and the prize was presented by Klaus Knopper of >>> Knoppix. >>> >>> Congratulations! >> >> Actually, the prize went to "Python", not to me, and not to the PSF. So >> congratulations to you as well! > > The (translated) article says that YOU are the prize? WOW. > > Ummm... better not to use automatic translator for anything mission > critical. > Congratulations! There is already a proper English version of press release at http://www.linux-magazine.com/online/news/cebit_2009_openstreetmap_wins_two_linux_new_media_awards so new link can probably be changed. The article still doesn't mention competitors. -- --anatoly t. ___ 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] 3.1 performance
Hello, Out of curiosity, I timed running the test suite ("./python -m test.regrtest") in non-debug mode, in both the release30-maint and py3k branches: * release30-maint got: 302 tests OK. [...] 165.79user 26.03system 5:01.75elapsed 63%CPU * py3k got: 304 tests OK. [...] 113.33user 28.93system 4:06.79elapsed 57%CPU So, 3.1 is 30% faster in user CPU time, even though it probably has more tests (because of io-c, ordereddict and importlib). This is on a 64-bit Linux AMD system, and I got similar results on a 64-bit Linux Core2 system. Regards Antoine. ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
[MvL] At this point, I do request that the patch is reverted completely (i.e. that the documentation is restored), and that the qualification "not reliable!" is removed from the doc strings of the methods, as it is factually incorrect. I would be happy to restore the documentation. You want the methods back and I think that's sufficient reason to bring it back. The "not reliable" wording in the docstrings was put there by Guido 16 years ago. http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup Speak to him about this. I'm done with this thread. 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
Re: [Python-Dev] 3.1 performance
Antoine Pitrou wrote: Hello, Out of curiosity, I timed running the test suite ("./python -m test.regrtest") in non-debug mode, in both the release30-maint and py3k branches: * release30-maint got: 302 tests OK. [...] 165.79user 26.03system 5:01.75elapsed 63%CPU * py3k got: 304 tests OK. [...] 113.33user 28.93system 4:06.79elapsed 57%CPU So, 3.1 is 30% faster in user CPU time, even though it probably has more tests (because of io-c, ordereddict and importlib). This is on a 64-bit Linux AMD system, and I got similar results on a 64-bit Linux Core2 system. Regards Antoine. Yes, traceback in large file is also quite fast now. Good work, io-c guys. :-) ___ 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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()
[MvL] At this point, I do request that the patch is reverted completely (i.e. that the documentation is restored), and that the qualification "not reliable!" is removed from the doc strings of the methods, as it is factually incorrect. I would be happy to restore the documentation. You want the methods back and I think that's sufficient reason to bring it back. The "not reliable" wording in the docstrings was put there by Guido 16 years ago. http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup Speak to him about this. I'm done with this thread. Also, for years, the documentation also had a "not-reliable" notice: Return ``True`` if the queue is empty, ``False`` otherwise. Because of multithreading semantics, this is not reliable. Skip changed it to the present wording last year: http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 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
Re: [Python-Dev] More on Py3K urllib -- urlencode()
After a harder look, I concluded there was a bit more work to be done, but still very basic modifications. Attached is a version of urlencode() which seems to make the most sense to me. I wonder how I could officially propose at least some of these modifications. - Dan Bill Janssen wrote: Bill Janssen wrote: Dan Mahn wrote: 3) Regarding the following code fragment in urlencode(): k = quote_plus(str(k)) if isinstance(v, str): v = quote_plus(v) l.append(k + '=' + v) elif isinstance(v, str): # is there a reasonable way to convert to ASCII? # encode generates a string, but "replace" or "ignore" # lose information and "strict" can raise UnicodeError v = quote_plus(v.encode("ASCII","replace")) l.append(k + '=' + v) I don't understand how the "elif" section is invoked, as it uses the same condition as the "if" section. This looks like a 2->3 bug; clearly only the second branch should be used in Py3K. And that "replace" is also a bug; it should signal an error on encoding failures. It should probably catch UnicodeError and explain the problem, which is that only Latin-1 values can be passed in the query string. So the encode() to "ASCII" is also a mistake; it should be "ISO-8859-1", and the "replace" should be a "strict", I think. Sorry! In 3.0.1, this whole thing boils down to l.append(quote_plus(k) + '=' + quote_plus(v)) Bill def urlencode(query, doseq=0, safe='', encoding=None, errors=None): """Encode a sequence of two-element tuples or dictionary into a URL query string. If any values in the query arg are sequences and doseq is true, each sequence element is converted to a separate parameter. If the query arg is a sequence of two-element tuples, the order of the parameters in the output will match the order of parameters in the input. """ if hasattr(query,"items"): # mapping objects query = query.items() else: # it's a bother at times that strings and string-like objects are # sequences... try: # non-sequence items should not work with len() # non-empty strings will fail this if len(query) and not isinstance(query[0], tuple): raise TypeError # zero-length sequences of all types will get here and succeed, # but that's a minor nit - since the original implementation # allowed empty dicts that type of behavior probably should be # preserved for consistency except TypeError: ty,va,tb = sys.exc_info() raise TypeError("not a valid non-string sequence or mapping object").with_traceback(tb) l = [] if not doseq: # preserve old behavior for k, v in query: k = quote_plus(k if isinstance(k, (str,bytes)) else str(k), safe, encoding, errors) v = quote_plus(v if isinstance(v, (str,bytes)) else str(v), safe, encoding, errors) l.append(k + '=' + v) else: for k, v in query: k = quote_plus(k if isinstance(k, (str,bytes)) else str(k), safe, encoding, errors) if isinstance(v, str): v = quote_plus(v if isinstance(v, (str,bytes)) else str(v), safe, encoding, errors) l.append(k + '=' + v) else: try: # is this a sufficient test for sequence-ness? x = len(v) except TypeError: # not a sequence v = quote_plus(str(v)) l.append(k + '=' + v) else: # loop over the sequence for elt in v: elt = quote_plus(elt if isinstance(elt, (str,bytes)) else str(elt), safe, encoding, errors) l.append(k + '=' + elt) return '&'.join(l) ___ 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] More on Py3K urllib -- urlencode()
On Sat, Mar 07, 2009, Dan Mahn wrote: > > After a harder look, I concluded there was a bit more work to be done, > but still very basic modifications. > > Attached is a version of urlencode() which seems to make the most sense > to me. > > I wonder how I could officially propose at least some of these > modifications. Submit a patch to bugs.python.org -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()
On Sat, Mar 7, 2009 at 6:54 AM, Raymond Hettinger wrote: > >> [MvL] >>> >>> At this point, I do request that the patch is reverted completely >>> (i.e. that the documentation is restored), and that the qualification >>> "not reliable!" is removed from the doc strings of the methods, as >>> it is factually incorrect. >> >> I would be happy to restore the documentation. You want the methods >> back and I think that's sufficient reason to bring it back. >> >> The "not reliable" wording in the docstrings was put there by Guido 16 >> years ago. >> http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158&view=markup >> Speak to him about this. I'm done with this thread. > > Also, for years, the documentation also had a "not-reliable" notice: > > Return ``True`` if the queue is empty, ``False`` otherwise. Because of > multithreading semantics, this is not reliable. > > Skip changed it to the present wording last year: > http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 That was a long time ago, but I think I just meant the obvious warning about multi-threaded use: if you are using full() and empty() and other threads may also mutate the queue, then you cannot use them to reliably prevent you from blocking. That's why eventually the facilities for non-blocking get() and put() were added (I think by Tim Peters). -- --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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickler/Unpickler API clarification
Greg Ewing wrote: > Michael Haggerty wrote: >> A similar effect could *almost* be obtained without accessing the memos >> by saving the pickled primer itself in the database. The unpickler >> would be primed by using it to load the primer before loading the record >> of interest. But AFAIK there is no way to prime new picklers, because >> there is no guarantee that pickling the same primer twice will result in >> the same id->object mapping in the pickler's memo. > > Would it help if, when creating a pickler or unpickler, > you could specify another pickler or unpickler whose > memo is used to initialise the memo of the new one? > > Then you could keep the pickler that you used to pickle > the primer and "fork" new picklers off it, and similarly > with the unpicklers. Typically, the purpose of a database is to persist data across program runs. So typically, your suggestion would only help if there were a way to persist the primed Pickler across runs. (The primed Unpickler is not quite so important because it can be primed by reading a pickle of the primer, which in turn can be stored somewhere in the DB.) In the particular case of cvs2svn, each of our databases is in fact written in a single pass, and then in later passes only read, not written. So I suppose we could do entirely without pickleable Picklers, if they were copyable within a single program run. But that constraint would make the feature even less general. Michael ___ 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] Pickler/Unpickler API clarification
On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty wrote: > Typically, the purpose of a database is to persist data across program > runs. So typically, your suggestion would only help if there were a way > to persist the primed Pickler across runs. I haven't followed all this, but isn't is at least possible to conceive of the primed pickler as being recreated from scratch from constant data each run? > (The primed Unpickler is not quite so important because it can be primed > by reading a pickle of the primer, which in turn can be stored somewhere > in the DB.) > > In the particular case of cvs2svn, each of our databases is in fact > written in a single pass, and then in later passes only read, not > written. So I suppose we could do entirely without pickleable Picklers, > if they were copyable within a single program run. But that constraint > would make the feature even less general. Being copyable is mostly equivalent to being picklable, but it's probably somewhat weaker because it's easier to define it as a pointer copy for some types that aren't easily picklable. -- --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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Belated introduction
I've been watching the threads about tracker maintenance and patch review with interest. I'm afraid that I did not follow the list recommendation to introduce myself when I first started posting, partly because I initially jumped in on something that was a bit of a hot button issue for me :) So, a little belatedly, here is my intro. I've been coding in and loving Python since 1993 or thereabouts. I am currently an independent IT consultant, with specialization in IP networking (especially Cisco), Lunix and Unix system administration, and systems integration. It is in my systems integration work that I make heavy use of Python, writing scripts and programs to tie systems together and/or add needed functionality. In my previous life I was Director of Technology for an ISP, and at one stage we were heavy into web site development. At that time I worked with the Zope community quite a bit, and made some contributions to the beginnings of Zope3. So for at least a few people this might be more of a re-introduction. I've decided that this year I would like to get more involved in the Python community. As another poster said, I'm looking forward to the opportunity to work with and learn from some very smart people. And then there's the satisfaction of giving back to a community that has given me so much over the years, by producing such a delightful language in which to do my coding. So, I've been reading the developer docs, setting up a bzr checkout, learning how to compile a debug python and run tests, wandering around in the source code, etc, etc. My thought about how I could best contribute at the present time is to help out with reviewing tracker issues. I actually updated the open tracker issue with the oldest last activity date this morning, as a sort of trial run. Unless someone wants to suggest a different way for me to contribute (I'm open to any suggestions), I'll probably continue through the list in reverse order of last update date and cherry pick things that interest me and that I think I can make some sort of contribution to. Don't hesitate to let me know if I miss etiquette points (gently, please :). Oh, and I'll be at pycon this year (my second pycon, the first was several years back), and look forward to hanging out with a cool bunch of people :) --RDM ___ 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] Belated introduction
On Sat, Mar 07, 2009, rdmur...@bitdance.com wrote: > > So, a little belatedly, here is my intro. [...] > > --RDM Welcome! You apparently haven't set your $NAME nor listed a name in your .sig, so how do you prefer to be addressed? Or do you just prefer your initials, like RMS? ;-) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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] IMAP/POP3 servers on python.org?
[moving discussion to python-dev from pydotorg] On Fri, Mar 06, 2009, Bill Janssen wrote: > Michael Foord wrote: >> Bill Janssen wrote: >>> Steve Holden wrote: Seems to me it might be better to have a test start a local server then kill it, but I am presuming you have some good reason why this is not practical? >>> >>> It seems a steep learning curve just to run the Python test suite, to >>> have to know how to install an IMAP server on your machine. But perhaps >>> you're right. >> >> Does it need to test against a real server - can't some of the lower >> calls be mocked out? > > Not really. These *are* the lower-level calls. One thing I haven't seen addressed in this discussion is why it's undesirable to ship Twisted as part of the testing source tree. Yes, I realize that it could create an "attractive nuisance", but I think the gains in simplifying testing outweigh that. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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] IMAP/POP3 servers on python.org?
Aahz pythoncraft.com> writes: > > One thing I haven't seen addressed in this discussion is why it's > undesirable to ship Twisted as part of the testing source tree. Because Twisted is huge and it's not reasonable to include it just for testing purposes? (besides, launching a twisted server implies running a reactor and I'm not sure the reactors support being started and stopped several times yet) ___ 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] Belated introduction
On Sat, 7 Mar 2009 at 08:42, Aahz wrote: On Sat, Mar 07, 2009, rdmur...@bitdance.com wrote: So, a little belatedly, here is my intro. [...] --RDM Welcome! You apparently haven't set your $NAME nor listed a name in your .sig, so how do you prefer to be addressed? Or do you just prefer your initials, like RMS? ;-) Thanks. Initials is fine, but I'm more used to 'David' as form of address. I have been using my initials in my sig because there are just too many Davids around. I suppose changing my sig to my name and my website wouldn't be be a bad thing, so... -- R. David Murray http://www.bitdance.com ___ 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] Pickler/Unpickler API clarification
Guido van Rossum wrote: > On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty wrote: >> Typically, the purpose of a database is to persist data across program >> runs. So typically, your suggestion would only help if there were a way >> to persist the primed Pickler across runs. > > I haven't followed all this, but isn't is at least possible to > conceive of the primed pickler as being recreated from scratch from > constant data each run? If there were a guarantee that pickling the same data would result in the same memo ID -> object mapping, that would also work. But that doesn't seem to be a realistic guarantee to make. AFAIK the memo IDs are integers chosen consecutively in the order that objects are pickled, which doesn't seem so bad. But compound objects are a problem. For example, when pickling a map, the map entries would have to be pickled in an order that remains consistent across runs (and even across Python versions). Even worse, all user-written __getstate__() methods would have to return exactly the same result, even across program runs. >> (The primed Unpickler is not quite so important because it can be primed >> by reading a pickle of the primer, which in turn can be stored somewhere >> in the DB.) >> >> In the particular case of cvs2svn, each of our databases is in fact >> written in a single pass, and then in later passes only read, not >> written. So I suppose we could do entirely without pickleable Picklers, >> if they were copyable within a single program run. But that constraint >> would make the feature even less general. > > Being copyable is mostly equivalent to being picklable, but it's > probably somewhat weaker because it's easier to define it as a pointer > copy for some types that aren't easily picklable. Indeed. And pickling the memo should not present any fundamental problems, since by construction it can only contain pickleable objects. Michael ___ 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] More on Py3K urllib -- urlencode()
Aahz wrote: > On Sat, Mar 07, 2009, Dan Mahn wrote: > > > > After a harder look, I concluded there was a bit more work to be done, > > but still very basic modifications. > > > > Attached is a version of urlencode() which seems to make the most sense > > to me. > > > > I wonder how I could officially propose at least some of these > > modifications. > > Submit a patch to bugs.python.org And it would help if it included a lot of test cases. Bill ___ 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] RELEASED Python 3.1 alpha 1
On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Python 3.1 focuses on the stabilization and optimization of features and changes Python 3.0 introduced. The new I/O system has been rewritten in C for speed. Other features include a ordered dictionary implementation and support for ttk Tile in Tkinter. Please note that these are alpha releases, and as such are not suitable for production environments. We continue to strive for a high degree of quality, but there are still some known problems and the feature sets have not been finalized. These alphas are being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 3.1 might impact you. If you find things broken or incorrect, please submit a bug report at http://bugs.python.org For more information and downloads, see the Python 3.1 website: http://www.python.org/download/releases/3.1/ See PEP 375 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, -- Benjamin Benjamin Peterson benjamin at python.org Release Manager (on behalf of the entire python-dev team) ___ 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] RELEASED Python 3.1 alpha 1
Benjamin Peterson wrote: On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. [...] Looks good, thanks to all involved. Two minor things: For more information and downloads, see the Python 3.1 website: http://www.python.org/download/releases/3.1/ On the release page, the bzip link says '3.0' not '3.1'. See PEP 375 for release schedule details: http://www.python.org/dev/peps/pep-0361/ On the PEP page, the Google calendar link is borken. Regards G. ___ 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] RELEASED Python 3.1 alpha 1
On Sat, Mar 07, 2009, Benjamin Peterson wrote: > > On behalf of the Python development team and the Python community, I'm > happy to announce the first alpha release of Python 3.1. Congratulations on your first baby! Here's to hoping you release many more of these! -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ 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] RELEASED Python 3.1 alpha 1
2009/3/7 Gerard Flanagan : > Benjamin Peterson wrote: > On the release page, the bzip link says '3.0' not '3.1'. That should be fixed now. > >> See PEP 375 for release schedule details: >> >> http://www.python.org/dev/peps/pep-0361/ That URL is actually supposed to be http://www.python.org/dev/peps/pep-0375/. -- Regards, Benjamin ___ 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] RELEASED Python 3.1 alpha 1
[Benjamin Peterson] On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 3.1. Thanks for the good work. 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
Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
> I would be happy to restore the documentation. You want the methods > back and I think that's sufficient reason to bring it back. Thanks! I'll look into the docstrings. 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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()
> Skip changed it to the present wording last year: > http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 I see. I agree that the change was for the better. 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] asyncore fixes in Python 2.6 broke Zope's version of medusa
gl...@divmod.com wrote: > ... which is exactly why I have volunteered to explain to someone how to > separate the core event-loop bits (suitable for inclusion in the > standard library) from the huge pile of protocol implementations which > are not necessarily useful. > > Despite the FUD to the contrary, Twisted's internal factoring is quite > good; it's not a single, undifferentiated pile of code. Plus, at this > point, we're not even talking about actually putting any Twisted code > into the standard library, just standardizing the "protocol" API, which > basically boils down to: [...] This sounds great. I'm interested on working on this since it scratches an itch of mine but I don't know if I will have time. Do you think if this part of Twisted became part of the standard library that it would be used by Twisted or would it continue to have its own version? 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] asyncore fixes in Python 2.6 broke Zope's version of medusa
Glyph> ... which is exactly why I have volunteered to explain to someone Glyph> how to separate the core event-loop bits (suitable for inclusion Glyph> in the standard library) from the huge pile of protocol Glyph> implementations which are not necessarily useful. Neil> This sounds great. I'm interested on working on this since it Neil> scratches an itch of mine but I don't know if I will have time. Neil> Do you think if this part of Twisted became part of the standard Neil> library that it would be used by Twisted or would it continue to Neil> have its own version? Anybody interested in working on this at a PyCon Sprint? I won't be attending the conference proper, but plan to spend a couple days sprinting, one on Mailman/SpamBayes integration and one on Python core stuff. This might fit well into my Python core "slot". I will probably have little time before the sprint to do much, but any brain dumps or Twisted pointers people could give me in the interim would be appreciated. Skip ___ 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] RELEASED Python 3.1 alpha 1
On Sat, Mar 7, 2009 at 1:21 PM, Raymond Hettinger wrote: > > [Benjamin Peterson] >> >> On behalf of the Python development team and the Python community, I'm >> happy to announce the first alpha release of Python 3.1. > > Thanks for the good work. Sorry to be late to the party. Indeed, thanks for all your efforts. I really appreciate it!! -- --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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickler/Unpickler API clarification
Michael Haggerty wrote: Typically, the purpose of a database is to persist data across program runs. So typically, your suggestion would only help if there were a way to persist the primed Pickler across runs. I don't think you need to be able to pickle picklers. In the case in question, the master pickler would be primed by pickling all the shared classes, and the resulting pickle would be stored in the database. When unpickling, the master unpickler would be primed by unpickling the shared pickle. -- Greg ___ 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] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()
On Sat, Mar 7, 2009 at 2:56 PM, "Martin v. Löwis" wrote: >> Skip changed it to the present wording last year: >> http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 > > I see. I agree that the change was for the better. Agreed too, though it would seem that *if* there is a single reader, empty()==False would guarantee that one subsequent get() won't block, and similar *if* there is a single writer, full()==False would guarantee that the next put() won't block. My point being that the lack of guarantee has to do with the necessary consequences of the non-atomicity of making two calls, not with anything inherently buggy in the implementation. Because Queue is designed for multi-threaded use, it's important to emphasize the lacking guarantees; but I think it's even more important to explain *why* these guarantees cannot hold. After all we don't go around documenting e.g. that for a dictionary, after "x in d" returns True, "x[d]" may still raise a KeyError exception (in case another thread deleted it). I'm not sure how I would modify the Queue documentation to clarify all this; perhaps it would be helpful to add an introductory section explaining the general issues with multiple readers and writers, and refer to this section in the descriptions of qsize() (and empty() and full() if they remain documented)? -- --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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com