Re: [Python-Dev] [Python-checkins] cpython: issue2193 - Update docs about the legal characters allowed in Cookie name
On Sun, Apr 22, 2012 at 12:32 PM, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/8cae3ee7f691 > changeset: 76465:8cae3ee7f691 > parent: 76462:0a63868c5e95 > user: Senthil Kumaran > date: Sun Apr 22 10:31:52 2012 +0800 > summary: > issue2193 - Update docs about the legal characters allowed in Cookie name You missed the dummy merge from 3.2 to indicate that this change had been applied to both branches independently. Should be fixed in my commit for issue #14026 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] path joining on Windows and imp.cache_from_source()
On Sun, 22 Apr 2012 07:45:27 +0200 "Martin v. Löwis" wrote: > > This goes back to > > http://codereview.appspot.com/842043/diff/1/3#newcode787 > > where Antoine points out that the code needs to look for altsep. > > He then suggests "keep the right-most of both". I don't think he > literally meant that the right-most separator should then also be > used to separate __pycache__, but only that the right-most of > either SEP or ALTSEP is what separates the module name. Indeed :-) Thanks Antoine. ___ 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] OS X buildbots missing
On Sat, 21 Apr 2012 15:50:03 -0400 David Bolen wrote: > Antoine Pitrou writes: > > > For the record, we don't have any stable OS X buildbots anymore. > > If you want to contribute a build slave (I hear we may have Apple > > employees reading this list), please take a look at > > http://wiki.python.org/moin/BuildBot > > I realize it may not qualify for the official stable list as it's a > Tiger-based buildbot, but osx-tiger is an OS X buildbot that's still > chugging along quite nicely (including doing the daily DMG builds). Well, the reason it can't qualify for the stable list right now is that there's a recurrent test_logging failure on it: http://bugs.python.org/issue14644 If that failure gets fixed, we could see if it's consistently green, and then put it in the stable bunch. Regards Antoine. ___ 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] Cython for cPickle?
On Thu, Apr 19, 2012 at 4:55 AM, Stefan Behnel wrote: > > That sounds like less than two weeks of work, maybe even if we add the > marshal module to it. > In less than a month of GSoC time, this could easily reach a point where > it's "close to the speed of what we have" and "fast enough", but a lot more > accessible and maintainable, thus also making it easier to add the > extensions described in the PEP. > > What do you think? As others have pointed out, many users of pickle depend on its performance. The main reason why _pickle.c is so big is all the low-level optimizations we have in there. We have custom stack and dictionary implementations just for the sake of speed. We also have fast paths for I/O operations and function calls. These optimizations alone are taking easily 2000 lines of code and they are not micro-optimizations. Each of these were shown to give speedups from one to several orders of magnitude. So I disagree that we could easily reach the point where it's "close to the speed of what we have." And if we were to attempt this, it would be a multiple months undertaking. I would rather see that time spent on improving pickle than on yet another reimplementation. -- Alexandre ___ 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] OS X buildbots missing
Antoine Pitrou writes: > Well, the reason it can't qualify for the stable list right now is that > there's a recurrent test_logging failure on it: > http://bugs.python.org/issue14644 Yeah, I don't know that I'm necessarily suggesting it be in the stable set as just mentioning that there is at least an OS X buildbot available, if only to reference pending another coming on-line. In the past I think it was tough to keep Tiger green. Though several people put a decent amount of effort into cleaning things up and I believe it's been pretty good for a while now, the current 3.x issue notwithstanding (and which is probably at least in part a chicken and egg problem in terms of awareness). The other branches look good, at least for the limited history on the web interface, and it looks like the 3.x change worked. I know I still build some of my OS X applications under Tiger (since it's easier to support later OS X versions from an earlier build than vice versa), but I don't know if Python necessarily wants to require that for releases, ala stable. -- David ___ 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] Cython for cPickle?
So I disagree that we could easily reach the point where it's "close to the speed of what we have." And if we were to attempt this, it would be a multiple months undertaking. I would rather see that time spent on improving pickle than on yet another reimplementation. Of course, this being free software, anybody can spend time on whatever they please, and this should not make anybody feel sad. You just don't get merits if you work on stuff that nobody cares about. 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
Re: [Python-Dev] Cython for cPickle?
Alexandre Vassalotti wrote: We have custom stack and dictionary implementations just for the sake of speed. We also have fast paths for I/O operations and function calls. All of that could very likely be carried over almost unchanged into a Cython version. I don't see why it should take multiple months. It's not a matter of rewriting it from scratch, just translating it from one dialect (C) to another (the C subset of Cython). -- Greg ___ 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] Cython for cPickle?
On Sun, Apr 22, 2012 at 6:12 PM, wrote: > So I disagree that we could easily reach the point where it's "close to >> the >> speed of what we have." And if we were to attempt this, it would be a >> multiple months undertaking. I would rather see that time spent on >> improving pickle than on yet another reimplementation. >> > > Of course, this being free software, anybody can spend time on whatever > they > please, and this should not make anybody feel sad. You just don't get > merits > if you work on stuff that nobody cares about. Yes, of course. I don't want to discourage anyone to investigate this option—in fact, I would very much like to see myself proven wrong. But, if I understood Stefan correctly, he is proposing to have a GSoC student to do the work, to which I would feel uneasy about since we have no idea how valuable this would be as a contribution. -- Alexandre ___ 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] Cython for cPickle?
On Mon, Apr 23, 2012 at 9:27 AM, Alexandre Vassalotti wrote: > On Sun, Apr 22, 2012 at 6:12 PM, wrote: >> Of course, this being free software, anybody can spend time on whatever >> they >> please, and this should not make anybody feel sad. You just don't get >> merits >> if you work on stuff that nobody cares about. > > > Yes, of course. I don't want to discourage anyone to investigate this > option—in fact, I would very much like to see myself proven wrong. But, if I > understood Stefan correctly, he is proposing to have a GSoC student to do > the work, to which I would feel uneasy about since we have no idea how > valuable this would be as a contribution. So long as it's made clear to the students applying that it's a proof of concept that may return a negative result (i.e. "it was tried, it proved to be a bad idea") I don't see a problem with it. The freedom to try out multiple ideas in parallel is one of the great strengths of open source. We've had GSoC students try unsuccessful experiments in the past and have gained useful information as a result (e.g. the main reason I know the Import Engine API proposed in the deferred PEP 406 isn't adequate as currently written is because of the design level problems Greg found when implementing it last summer. The currently documented design simply doesn't achieve the full objectives of the PEP) 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] Cython for cPickle?
On Sun, Apr 22, 2012 at 6:34 PM, Nick Coghlan wrote: > On Mon, Apr 23, 2012 at 9:27 AM, Alexandre Vassalotti > wrote: >> On Sun, Apr 22, 2012 at 6:12 PM, wrote: >>> Of course, this being free software, anybody can spend time on whatever >>> they >>> please, and this should not make anybody feel sad. You just don't get >>> merits >>> if you work on stuff that nobody cares about. >> >> >> Yes, of course. I don't want to discourage anyone to investigate this >> option—in fact, I would very much like to see myself proven wrong. But, if I >> understood Stefan correctly, he is proposing to have a GSoC student to do >> the work, to which I would feel uneasy about since we have no idea how >> valuable this would be as a contribution. > > So long as it's made clear to the students applying that it's a proof > of concept that may return a negative result (i.e. "it was tried, it > proved to be a bad idea") I don't see a problem with it. The freedom > to try out multiple ideas in parallel is one of the great strengths of > open source. > > We've had GSoC students try unsuccessful experiments in the past and > have gained useful information as a result (e.g. the main reason I > know the Import Engine API proposed in the deferred PEP 406 isn't > adequate as currently written is because of the design level problems > Greg found when implementing it last summer. The currently documented > design simply doesn't achieve the full objectives of the PEP) However, I think that in this case the success may be predetermined, or at least not determined by technical success alone. I have a lot of respect for Cython, but I don't think it is right to have any part of core Python depend on it. Cython is an incredibly complex and relatively young (and still fast evolving) piece of technology, while I think that core dependencies should be minimized and limited to absolutely fundamental building blocks. -- --Guido van Rossum (python.org/~guido) ___ 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
