Re: [Python-Dev] gc ideas -- sparse memory

On Sat, 4 Dec 2010 15:06:45 +1100 Cameron Simpson wrote: > On 03Dec2010 18:15, James Y Knight wrote: > | On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote: > | > gc is implementation specific. CPython uses ref counting + cycle > | > gc. A constraint on all implementations is that objects have a fixed

Re: [Python-Dev] python 2 for building python 3

On Sat, 4 Dec 2010 11:20:57 +0200 Eli Bendersky wrote: > > I had the error pop out in a real build, so the time stamp is probably not a > 100% guarantee. Therefore I think it's good that you made it version > agnostic. This should be probably be a requirement for all scripts that are > part of

Re: [Python-Dev] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py

On Sat, 4 Dec 2010 10:10:44 +0100 (CET) gregory.p.smith wrote: > Author: gregory.p.smith > Date: Sat Dec 4 10:10:44 2010 > New Revision: 87010 > > Log: > issue7213 + issue2320: Cause a DeprecationWarning if the close_fds argument is > not passed to subprocess.Popen as the default value will be

Re: [Python-Dev] python 2 for building python 3

Le samedi 04 décembre 2010 à 13:23 +, Mark Dickinson a écrit : > On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote: > > Er, normally you don't need *any* Python installed to build Python (be > > it 3.x or 2.x). > > Are you sure about this? I remember nee

Re: [Python-Dev] python 2 for building python 3

Le samedi 04 décembre 2010 à 13:39 +, Mark Dickinson a écrit : > On Sat, Dec 4, 2010 at 1:23 PM, Mark Dickinson wrote: > > On Sat, Dec 4, 2010 at 11:41 AM, Antoine Pitrou wrote: > >> Er, normally you don't need *any* Python installed to build Python (be > >>

Re: [Python-Dev] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py

On Sat, 4 Dec 2010 23:17:49 + Paul Moore wrote: > On 4 December 2010 23:07, Paul Moore wrote: > > Is there an issue on Windows? If not, and given how different FD > > inheritance is on Windows, I'd argue that in the absence of bug > > reports, there's no need to change behaviour on Windows. >

Re: [Python-Dev] r87010 - in python/branches/py3k: Doc/library/subprocess.rst Lib/subprocess.py Lib/test/test_subprocess.py

On Sun, 5 Dec 2010 11:08:43 -0800 "Gregory P. Smith" wrote: > Sleeping on the issue some more and pondering it... > > Is there any _good_ reason not to just make the close_fds default change in > 3.2 today? No warning (since they're never seen by most people anyways). > Document it in Misc/NEWS

Re: [Python-Dev] PEP 11: Dropping support for ten year old systems

On Sun, 05 Dec 2010 22:48:49 +0100 "Martin v. Löwis" wrote: > I'd like to tighten PEP 11, and declare a policy that systems > older than ten years at the point of a feature release are not > supported anymore by default. Older systems where support is still > maintained need to be explicitly liste

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 beta 1

> Development efforts concentrated on the standard library and support for > porting code to Python 3. Highlights are: > > [snip] * ...a much improved ssl module Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Tue, 7 Dec 2010 20:26:06 + (UTC) Vinay Sajip wrote: > > >From my perspective and as mentioned in the logging documentation, library > >code > which uses logging should add a NullHandler instance to any top-level logger, > which will avoid any "No handlers could be found for logger XXX" me

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Tue, 7 Dec 2010 22:04:36 +0100 Łukasz Langa wrote: > Wiadomość napisana przez Antoine Pitrou w dniu 2010-12-07, o godz. 21:50: > > > If any library defining a logger must also add a NullHandler just in > > case, ISTM that complicates a lot the use of logging (and cou

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Tue, 7 Dec 2010 23:45:39 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > > > I thought "error" and "critical" messages were logged to stderr by > > default? Isn't it the case? > > > > Only if

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 8 Dec 2010 01:51:44 + (UTC) Vinay Sajip wrote: > > > Adding a NullHandler isn't the right thing to do - the behaviour I > > would want for any standard library logging that hasn't been > > explicitly configured otherwise is to do what the root logger does > > under basicConfig(): deb

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 08 Dec 2010 09:09:45 +0100 Georg Brandl wrote: > Am 08.12.2010 01:09, schrieb Antoine Pitrou: > > On Tue, 7 Dec 2010 23:45:39 + (UTC) > > Vinay Sajip wrote: > >> Antoine Pitrou pitrou.net> writes: > >> > >> > > >> > I t

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 8 Dec 2010 01:19:45 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > > > Why wouldn't it be the default for all logging calls ? Such special > > cases don't really make things easy to remember. > > > >

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 08 Dec 2010 11:48:16 +0100 Georg Brandl wrote: > Am 08.12.2010 10:42, schrieb Antoine Pitrou: > > >> But errors don't pass silently, do they? The usual way to present errors > >> is still by raising exceptions. > > > > Or logging the

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 8 Dec 2010 12:15:53 + (UTC) Vinay Sajip wrote: > > First, you cannot call it a "default", since the library writer has to > > make it explicit. > > Second, I don't find that convenient at all. When I use a third-party > > lib I want the errors to be displayed, not silenced. I'm willing

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 8 Dec 2010 14:54:09 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > I'm not talking specifically about exceptions, but about errors in > > general. If the case wasn't common, I'm not sure why the error() and >

Re: [Python-Dev] Redirecting stdout/stderr to the logging module (was Re: Using logging in the stdlib and its unit tests)

On Thu, 9 Dec 2010 03:28:36 +1000 Nick Coghlan wrote: > On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip wrote: > > Nick Coghlan gmail.com> writes: > >> P.S. On a completely unrelated note, has anyone thought about creating > >> a write-only TextIO stream that outputs received writes via the > >> lo

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, 8 Dec 2010 19:00:31 + (UTC) Vinay Sajip wrote: > > > If you're interested in having a theoretical argument about what a > > beautiful design should be (and if you want to argue about your own > > design decisions), I'll leave the discussion here. I'm only interested > > No, I'm not i

Re: [Python-Dev] transform() and untransform() methods, and the codec registry

On Thu, 9 Dec 2010 13:55:08 -0500 Alexander Belopolsky wrote: > On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum wrote: > .. > > string-string transforms use the same namespace even though the > > typical transform only supports one or the other. E.g. IMO all of the > > following should raise Lo

Re: [Python-Dev] sWAPcASE Was: transform() and untransform() methods, and the codec registry

On Thu, 09 Dec 2010 18:10:38 -0500 Eric Smith wrote: > On 12/9/2010 5:54 PM, Raymond Hettinger wrote: > > It would make me happy if we could agree to kill or at least mortally wound > > str.swapcase(). I did some research on what it is go for and found > > that it is a vestige of an old word proce

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Hey Vinay, On Fri, 10 Dec 2010 11:46:18 + (UTC) Vinay Sajip wrote: > Terry Reedy udel.edu> writes: > > > Your proposal struck me as probably the best way forward. Can you code > > it up and put a patch on the tracker that people can test before the > > next beta? > > Coded up (including

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Fri, 10 Dec 2010 12:34:48 + (UTC) Vinay Sajip wrote: > > When you make significant changes outside of logging, it would be nice > > if you first opened an issue and posted the patch for review. There's > > nothing obviously wrong with what you committed, but I think it's > > principally bet

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Fri, 10 Dec 2010 12:31:19 -0800 Guido van Rossum wrote: > > The default setting of WARNING is not from Java either - it's the Unix idea > > that > > verbosity should be kept to a minimum unless specifically requested. So, > > warnings and errors should be shown, but info and debug not. Imagine

Re: [Python-Dev] API for the new sysconfig module

On Fri, 10 Dec 2010 12:27:26 -0800 Raymond Hettinger wrote: > > IMO, sysconfig did not warrant a whole module. Where would you put it? > Rather than using two levels of dictionary, it's also possible > to use a named tuple if you think that is more clean looking: > >>>> c = sys.sysconfig()

Re: [Python-Dev] API for the new sysconfig module

On Sat, 11 Dec 2010 12:55:25 +1000 Nick Coghlan wrote: > On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote: > > On 12/10/2010 4:59 PM, R. David Murray wrote: > > > >> Like Éric, I'm not sure what the implications of the existing module > >> having been released in 2.7 and 3.2 beta are in terms

Re: [Python-Dev] API for the new sysconfig module

On Sun, 12 Dec 2010 13:01:42 +0100 Łukasz Langa wrote: > Wiadomość napisana przez Raymond Hettinger w dniu 2010-12-11, o godz. 22:18: > > >> *(I sometimes lose track of which changes were made in both branches > >> pre-2.7, which ones were mode post-2.7 release, and which ones went in > >> pre-2

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolsky wrote: > On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum wrote: > > I'm at least +0 on > > allowing trailing commas in the situation the OP mentioned. > > > > FWIW, I am also about +0.5 on allowing trailing comma. Note that in a > simi

Re: [Python-Dev] configparser 1.1 - one last bug fix needed

On Tue, 14 Dec 2010 10:20:04 +1000 Nick Coghlan wrote: > +1 from me. > > If anyone complains too much, perhaps we can offer to retain the old > ConfigParser as "_BuggyConfigParser"? (that idea is only partially > tongue-in-cheek...) Or we can put it in the "buggy" module which receives all bugg

Re: [Python-Dev] r87253 - tracker/instances/python-dev/detectors/autonosy.py

On Wed, 15 Dec 2010 01:53:37 +0100 (CET) ezio.melotti wrote: > Author: ezio.melotti > Date: Wed Dec 15 01:53:37 2010 > New Revision: 87253 > > Log: > #363: add automatically release managers to the nosy list for release > blockers. Initial patch by Georg Brandl. You should probably add deferr

[Python-Dev] Remove HTTP 0.9 support

Hello, I would like to remove HTTP 0.9 support from http.client and http.server. I've opened an issue at http://bugs.python.org/issue10711 for that. Would anyone think it's a bad idea? (HTTP 1.0 was devised in 1996) Regards Antoine. ___ Python-Dev

Re: [Python-Dev] Remove HTTP 0.9 support

On Wed, 15 Dec 2010 12:58:51 -0800 Glenn Linderman wrote: > On 12/15/2010 10:39 AM, Antoine Pitrou wrote: > > Hello, > > > > I would like to remove HTTP 0.9 support from http.client and > > http.server. I've opened an issue at http://bugs.python.org/issue10711

Re: [Python-Dev] Remove HTTP 0.9 support

On Wed, 15 Dec 2010 14:20:54 -0800 Glenn Linderman wrote: > On 12/15/2010 1:25 PM, Antoine Pitrou wrote: > > On Wed, 15 Dec 2010 12:58:51 -0800 > > Glenn Linderman wrote: > >> On 12/15/2010 10:39 AM, Antoine Pitrou wrote: > >>> Hello, > >>> &g

Re: [Python-Dev] Remove HTTP 0.9 support

Le jeudi 16 décembre 2010 à 16:14 +0800, Senthil Kumaran a écrit : > On Wed, Dec 15, 2010 at 11:29:27PM +0100, Antoine Pitrou wrote: > > Well, I think the "most web servers" comment itself is outdated. > > Try e.g. www.mozilla.org or www.google.com or www.msn.com. &

Re: [Python-Dev] Multiprocessing module - Synergeticprocessing (my custom module) - Pickling unPickling issues

On Thu, 16 Dec 2010 15:52:19 +0200 Dimitrios Pritsos wrote: > > Hello Michael, > > OK I will do sent it to the bug tracker. But what about the last issue > i.e. that even if the class is transfered-and-pickled-unpickled it > raises an exception if the class is defined into the __main__ script

Re: [Python-Dev] Remove HTTP 0.9 support

On Thu, 16 Dec 2010 07:42:08 +0100 André Malo wrote: > * Antoine Pitrou wrote: > > > Hello, > > > > I would like to remove HTTP 0.9 support from http.client and > > http.server. I've opened an issue at http://bugs.python.org/issue10711 > > for

Re: [Python-Dev] Remove HTTP 0.9 support

On Fri, 17 Dec 2010 00:52:14 +0800 Senthil Kumaran wrote: > Actually, it is turning out to be true: > > http://ftp.ics.uci.edu/pub/ietf/http/rfc1945.html#Response > > According to HTTP 1.0, When a request is Simple-Request, it means a > VERB URL (without a version) and it generally corresponds t

Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst

On Sat, 18 Dec 2010 12:37:09 +0100 Georg Brandl wrote: > I'd rather keep this a note. We don't want to use warnings except for cases > where there is a possibility of security implications or crashes. Well, there'll be a crash as soon as someone relies on an API we decide to change or remove :)

Re: [Python-Dev] r87188 - python/branches/py3k/Doc/library/test.rst

On Sat, 18 Dec 2010 13:11:09 +0100 Georg Brandl wrote: > Am 18.12.2010 13:07, schrieb Antoine Pitrou: > > On Sat, 18 Dec 2010 12:37:09 +0100 > > Georg Brandl wrote: > >> I'd rather keep this a note. We don't want to use warnings except for > >>

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

On Sat, 18 Dec 2010 17:50:38 +0100 Georg Brandl wrote: > Am 18.12.2010 14:57, schrieb Victor Stinner: > > Le 18/12/2010 13:21, Georg Brandl a écrit : > >> I very much like having a traceback on (some) segmentation faults, > > Why do you say "some" segmentation faults? > >> but it's clear there nee

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

On Sat, 18 Dec 2010 20:36:50 +0100 "Martin v. Löwis" wrote: > Am 18.12.2010 19:55, schrieb Alexander Belopolsky: > > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote: > > .. > >> In any case, this is coming pretty late; beta 2 is scheduled for this > >> weekend, and even if this is something

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On Sat, 18 Dec 2010 21:00:04 +0100 (CET) ezio.melotti wrote: > Author: ezio.melotti > Date: Sat Dec 18 21:00:04 2010 > New Revision: 87389 > > Log: > #10573: use actual/expected consistently in unittest methods. IMHO, this should be reverted. The API currently doesn't treat these arguments diffe

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On Sat, 18 Dec 2010 20:23:49 -0800 Guido van Rossum wrote: > I may be unique, but I fear there is no great answer. On the one hand > I almost always code it as e.g. assertEqual(actual, expected), which > matches my preference for e.g. "if x == 5:" rather than "if 5 == x:". > On the other hand in t

Re: [Python-Dev] r87399 - in python/branches/py3k: Doc/library/http.client.rst Doc/library/urllib.request.rst Lib/http/client.py Lib/test/test_httplib.py Lib/test/test_urllib2.py Lib/urllib/request.py

Hello Senthil, > +raise TypeError("data should be byte-like object\ Should be "bytes-like". > +request.add_unredirected_header( > +'Content-length', '%d' % len(mv) * mv.itemsize) There is an operator precedence problem here: >>>

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

Le dimanche 19 décembre 2010 à 10:41 -0800, Guido van Rossum a écrit : > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: > > On Sat, 18 Dec 2010 20:23:49 -0800 > > Guido van Rossum wrote: > >> I may be unique, but I fear there is no great answer. On the one hand &

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit : > >> This is also what I think. Installing a signal handler is a fairly > >> drastic action, and I don't think the code has been sufficiently > >> reviewed yet. > > > > How much more review should it receive? > > There shoul

Re: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

On Sun, 19 Dec 2010 23:37:58 +0100 Victor Stinner wrote: > Le dimanche 19 décembre 2010 à 20:20 +0100, Antoine Pitrou a écrit : > > Can you clarify why you think those signal handlers fall into that > > description? After all, SIGINT, SIGILL and friends only get triggered in &

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On Sun, 19 Dec 2010 18:54:55 -0500 Terry Reedy wrote: > On 12/19/2010 1:41 PM, Guido van Rossum wrote: > > On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou wrote: > > >> This could be nicely resolved by renaming the arguments "a" and "b", > >&

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : > Ah man, we've *nearly* finished bikeshedding about the names of unittest > assert methods so its time to move onto the names and order of the > arguments. Really? Apparently someone decided this bikeshedding was important enough

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

Le lundi 20 décembre 2010 à 14:03 +, Michael Foord a écrit : > On 20/12/2010 13:47, Antoine Pitrou wrote: > > Le lundi 20 décembre 2010 à 13:00 +, Michael Foord a écrit : > >> Ah man, we've *nearly* finished bikeshedding about the names of unittest > >> as

Re: [Python-Dev] r87445 - python/branches/py3k/Lib/numbers.py

On Thu, 23 Dec 2010 19:41:33 +0100 (CET) eric.araujo wrote: > > def __index__(self): > -"""index(self)""" > +"""someobject[self]""" This is misleading as to what the method actually does, as you can read in the implementation: > return int(self) ___

Re: [Python-Dev] r87445 - python/branches/py3k/Lib/numbers.py

On Thu, 23 Dec 2010 22:09:15 +0100 Éric Araujo wrote: > Le 23/12/2010 20:55, Antoine Pitrou a écrit : > >> def __index__(self): > >> -"""index(self)""" > >> +"""someobject[self]""&

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

On Wed, 29 Dec 2010 14:14:03 -0500 "R. David Murray" wrote: > On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller wrote: > > The concurrent.futures tests should (like the multiprocessing test > > suite) detect the lack of support and skip the tests on the broken > > platforms. I'm sort of surprised

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

On Wed, 29 Dec 2010 23:24:32 +0100 "Martin v. Löwis" wrote: > > I don't have a good suggestion (or a computer with a keyboard > > anywhere near me) right now, but making a migration/fallback to SYSV > > style semaphores a release blocker seems like a mistake to me. > > And indeed, I don't propose

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

On Thu, 30 Dec 2010 16:04:16 +0100 Łukasz Langa wrote: > > Some answers Philip gave already. Knowing all these things would let us > decide whether switching the module off on systems that don't meet the > requirements is okay and can we get away with just documenting how to make it > work. I

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

> > I'm not sure concurrent.futures is the culprit, rather than > > multiprocessing itself (or perhaps even some core Python functionality). > > Actually, the threading-based part of concurrent.futures probably works > > fine. > > Well, "the culprit" really is FreeBSD. However, concurrent.futures

Re: [Python-Dev] Backport troubles with mercurial

On Thu, 30 Dec 2010 20:57:11 +0100 Éric Araujo wrote: > Hi, > > One thing confuses me in this thread: Do the problems come from merging > across different versions (i.e. different syntax and module names), or > are they regular problems that come up because people don’t want to use > a merge tool

Re: [Python-Dev] Backport troubles with mercurial

Le jeudi 30 décembre 2010 à 14:24 -0600, Benjamin Peterson a écrit : > 2010/12/30 Antoine Pitrou : > > On Thu, 30 Dec 2010 20:57:11 +0100 > > Éric Araujo wrote: > >> Hi, > >> > >> One thing confuses me in this thread: Do the problems come from m

Re: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

On Thu, 30 Dec 2010 12:36:47 -0800 Ethan Furman wrote: > Martin v. Löwis wrote: > >> And, again, the threading-based API in concurrent.futures should work > >> fine anyway. Do you suggest we selectively disable the process-based > >> API? > > > > Yes. Importing concurrent.futures.process should

Re: [Python-Dev] PEP 3333: wsgi_string() function

On Tue, 04 Jan 2011 03:44:53 +0100 Victor Stinner wrote: > def wsgi_string(u): > # Convert an environment variable to a WSGI "bytes-as-unicode" > string > return u.encode(enc, esc).decode('iso-8859-1') > > def run_with_cgi(application): > environ = {k: wsgi_string(v) for k,v in os.env

Re: [Python-Dev] PEP 3333: wsgi_string() function

On Tue, 04 Jan 2011 14:33:37 +0100 Victor Stinner wrote: > Le mardi 04 janvier 2011 à 13:20 +0100, Antoine Pitrou a écrit : > > On Tue, 04 Jan 2011 03:44:53 +0100 > > Victor Stinner wrote: > > > def wsgi_string(u): > > > # Convert an environment var

Re: [Python-Dev] Omit Py_buffer struct from Stable ABI for Python 3.2?

On Wed, 5 Jan 2011 12:55:55 + Mark Dickinson wrote: > On Wed, Jan 5, 2011 at 12:31 PM, Nick Coghlan wrote: > > Currently [1], the implementation and the documentation for PEP 3118's > > Py_buffer struct don't line up (there's an extra field in the > > implementation that the PEP doesn't menti

Re: [Python-Dev] Omit Py_buffer struct from Stable ABI for Python 3.2?

On Wed, 5 Jan 2011 14:03:41 + Mark Dickinson wrote: > On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou wrote: > > On Wed, 5 Jan 2011 12:55:55 + > > Mark Dickinson wrote: > >> The need for obj is a little ugly:  as far as I can tell, it's > >> meaning

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

On Wed, 5 Jan 2011 12:33:55 -0500 Alexander Belopolsky wrote: > On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum wrote: > > Given the rule garbage in -> garbage out, I'd do the most useful > > thing, which would be to produce a longer output string (and update > > the docs). This would match the

Re: [Python-Dev] [Python-checkins] r87768 - in python/branches/py3k: Lib/socket.py Lib/test/test_socket.py Misc/NEWS

On Wed, 05 Jan 2011 17:21:23 -0500 Terry Reedy wrote: > > > Issue #7995: When calling accept() on a socket with a timeout, the returned > > socket is now always non-blocking, regardless of the operating system. > > Seems clear enough > > > +# Issue #7995: if no default timeout is set a

Re: [Python-Dev] [Python-checkins] devguide: Start a doc on running and writing unit tests.

On Wed, 05 Jan 2011 17:43:32 -0500 Terry Reedy wrote: > > Not on Windows. > C:\Programs\Python32>./python -m test > '.' is not recognized as an internal or external command, > operable program or batch file. > > python -m test > works (until it failed, separate issue). This will not run the r

Re: [Python-Dev] [Python-checkins] devguide: Start a doc on running and writing unit tests.

On Wed, 05 Jan 2011 18:00:18 -0500 Terry Reedy wrote: > > > +Running > > +--- > > Is there a way to skip a particular test, such as one that crashes the > test process? -x test_foo ___ Python-Dev mailing list Python-Dev@python.org http://mail.

Re: [Python-Dev] [Python-checkins] devguide: Start a doc on running and writing unit tests.

On Thu, 06 Jan 2011 00:34:11 -0500 > >> > >> python -m test > >>works (until it failed, separate issue). > > > > This will not run the right interpreter, unless this is an installed > > build. > > It is, from 32b2.msi. I have no compiler ;-). Ah, sorry. For the devguide, however, I recommend

Re: [Python-Dev] 3.2b2 fails test suite on (my) Windows XP

On Wed, 5 Jan 2011 17:56:53 -0600 Brian Curtin wrote: > > http://bugs.python.org/issue9116 covers this issue. > > The reason it doesn't fail on any of the build slaves is because they modify > a registry value for Windows Error Reporting to not display the pop-up > window, or at least mine does.

Re: [Python-Dev] r87816 - peps/trunk/pep-3333.txt

On Fri, 7 Jan 2011 16:45:26 +0100 (CET) phillip.eby wrote: > Author: phillip.eby > Date: Fri Jan 7 16:45:26 2011 > New Revision: 87816 > > Log: > Fix re-raise syntax for Python 3 > > > Modified: >peps/trunk/pep-.txt > > Modified: peps/trunk/pep-.txt >

Re: [Python-Dev] API refactoring tracker field for Python4

On Fri, 7 Jan 2011 13:36:26 -0500 Alexander Belopolsky wrote: > On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote: > .. > > Don't you think that if people could review issues and "star" them > > then such minor issues could be scheduled for release not only by > > "severity" status as deci

Re: [Python-Dev] API refactoring tracker field for Python4

On Fri, 7 Jan 2011 12:39:34 -0600 Brian Curtin wrote: > > > > I haven't started using Python 3 yet, but I already know some annoying > > API issues that are not fixed there. Unfortunately, I don't remember > > them to give you a list. That's why I asked for a flag. > > If you haven't used it yet,

Re: [Python-Dev] API refactoring tracker field for Python4

On Fri, 7 Jan 2011 11:11:47 -0800 Guido van Rossum wrote: > On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky > wrote: > > -1 on the "star system" for the tracker > > The tracker on Google Code uses stars. We use this tracker to track > external App Engine issues. It works very well to meas

Re: [Python-Dev] r87838 - python/branches/py3k/Doc/library/threading.rst

On Fri, 7 Jan 2011 22:54:18 +0100 (CET) raymond.hettinger wrote: > Author: raymond.hettinger > Date: Fri Jan 7 22:54:18 2011 > New Revision: 87838 > > Log: > Revert r87821 which moved the source link to the wrong section (from the > module intro covering the module to a section on thread impor

Re: [Python-Dev] r87849 - python/branches/py3k/Lib/test/test_ssl.py

On Sat, 8 Jan 2011 04:16:05 +0100 (CET) victor.stinner wrote: > Author: victor.stinner > Date: Sat Jan 8 04:16:05 2011 > New Revision: 87849 > > Log: > test_ssl: test SHA256 using sha256.tbs-internet.com instead of sha2.hboeck.de > > Modified: >python/branches/py3k/Lib/test/test_ssl.py >

Re: [Python-Dev] FYI: Python 2.7.1 + gcc 4.6 (experimental) probable optimizer problem

On Sat, 8 Jan 2011 12:03:35 -0800 (PST) "Ralf W. Grosse-Kunstleve" wrote: > I just wanted to share an observation in case Python developers are > interested: > Python 2.7.1 doesn't build with the current gcc 4.6 svn. > Note that gcc 4.6 is now in "bug-fix only" mode. You should report a bug with

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

On Sat, 08 Jan 2011 23:05:06 +0100 brett.cannon wrote: > +For bugs, an issue needs to: > + > +* Clearly explain the bug so it can be reproduced > +* All relevant platform details are included > +* What version(s) of Python are affected by the bug are fully known > +* Is there a proper unit test th

Re: [Python-Dev] FYI: Python 2.7.1 + gcc 4.6 (experimental) probable optimizer problem

On Sat, 8 Jan 2011 22:58:51 +0100 Stefan Krah wrote: > Antoine Pitrou wrote: > > On Sat, 8 Jan 2011 12:03:35 -0800 (PST) > > "Ralf W. Grosse-Kunstleve" wrote: > > > I just wanted to share an observation in case Python developers are > > > interested

Re: [Python-Dev] Add sendfile() to core?

On Sat, 08 Jan 2011 09:55:19 +0200 max ulidtko wrote: > On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote: > | sendfile() is used when writing really high-performance Web servers, > | in order to save an unnecessary memory-to-memory copy. Question: > | should I make up a patch to add a se

Re: [Python-Dev] Add sendfile() to core?

On Sun, 9 Jan 2011 11:17:40 -0800 Guido van Rossum wrote: > Isn't that just shutil.copyfileobj()? copyfileobj() still uses an user-space buffer (the Python bytes object used in the loop). The advantage of sendfile() is to bypass user-space logic and do the transfer entirely in kernel. How much

Re: [Python-Dev] API refactoring tracker field for Python4

On Sun, 09 Jan 2011 22:52:47 +0100 Éric Araujo wrote: > Le 07/01/2011 19:39, Brian Curtin a écrit : > > On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote: > >> Module split: > >> try to get all issues for 'os' module > > No solution for this right now, but people have suggested that we add

[Python-Dev] "unit test needed"

Hello, I would like to advocate again for the removal of the "unit test needed" stage on the tracker, which regularly confuses our triagers into thinking it's an actual requirement or expectation from contributors and bug reporters. Regards Antoine. ___

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

On Sun, 9 Jan 2011 15:18:12 -0800 Brett Cannon wrote: > > OK, so the sentence is poorly phrased, but in the list of tasks it is > labeled explicitly as intermediate when one is comfortable with the > process, not a newbie. Does that alleviate the worry you both have? It does seem to alleviate it

Re: [Python-Dev] "unit test needed"

On Mon, 10 Jan 2011 21:11:23 +0200 Eli Bendersky wrote: > > I would like to advocate again for the removal of the "unit test > > needed" stage on the tracker, which regularly confuses our triagers > > into thinking it's an actual requirement or expectation from > > contributors and bug reporters.

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit : > > > > > > Fair enough. I will remove it. > > > > Well, *often* a test that exposes the issue can be written - and if so > it is a useful exercise (surely). Yes, well, that's a matter of "useful exercise for the contributor" vs.

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

Le lundi 10 janvier 2011 à 19:37 +, Michael Foord a écrit : > On 10/01/2011 19:31, Antoine Pitrou wrote: > > Le lundi 10 janvier 2011 à 19:26 +, Michael Foord a écrit : > >>> > >>> Fair enough. I will remove it. > >>> > >> Well, *often*

Re: [Python-Dev] r87946 - python/branches/py3k/Doc/howto/sorting.rst

On Wed, 12 Jan 2011 00:05:56 +0100 (CET) terry.reedy wrote: > +>>> def cmp_to_key(mycmp): http://docs.python.org/dev/library/functools.html#functools.cmp_to_key ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/list

Re: [Python-Dev] os.ioprio_get() and os.ioprio_set()

On Mon, 17 Jan 2011 14:53:19 +0100 Giampaolo Rodolà wrote: > I've recently implemented this functionality in psutil: > http://code.google.com/p/psutil/issues/detail?id=147 > If desired, I can contribute a patch for the os module, altough being > such functions Linux-only, I'm not sure os module is

Re: [Python-Dev] devguide: Add a doc outlining how to add something to the stdlib.

On Sun, 16 Jan 2011 21:38:43 +0100 brett.cannon wrote: > + > +Adding to a pre-existing module > +--- > + > +If you have found that a function, method, or class is useful and you believe > +it would be useful to the general Python community, there are some steps to > go

Re: [Python-Dev] Moving stuff out of Misc and over to the devguide

On Mon, 17 Jan 2011 12:32:20 -0800 Brett Cannon wrote: > There is a bunch of stuff in Misc that probably belongs in the > devguide (under Resources) instead of in svn. Here are the files I > think can be moved (in order of how strongly I think they should be > moved): > > PURIFY.README > README.c

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On Mon, 17 Jan 2011 23:37:07 +0100 brett.cannon wrote: > + > +To undo a patch, do:: > + > +patch -R -p0 < patch.diff > + Or, simply and more reliably, use the corresponding VCS incantation ("svn revert -R ." or "hg revert -a"). Regards Antoine.

Re: [Python-Dev] devguide: Write a guide to committing a patch.

On Tue, 18 Jan 2011 07:14:51 +0100 Ezio Melotti wrote: > > + > > +Committing Patches > > +== [...] > > + > > +svnmerge.py merge -r 42 > > + > > +This will try to apply the patch to the current patch and generate a > > commit Do we want to spend so much time explaining how to u

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On Thu, 20 Jan 2011 01:23:26 +1100 Steven D'Aprano wrote: > s...@pobox.com wrote: > > > I realize the world is passing me by and that I'm rapidly turning into a > > dinosaur w.r.t. distributed version control, but as you write/update the > > developer's guide remember that proficiency in Python d

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On Thu, 20 Jan 2011 01:54:37 +1100 Steven D'Aprano wrote: > > You'll have to ask Skip if he thinks there's a concrete problem. I > haven't seen one, but I've only been reading this thread with one eye > and it may be I've missed the mother of all problems. > > The (non-concrete) issue, as I un

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On Wed, 19 Jan 2011 10:36:04 -0600 s...@pobox.com wrote: > > >> What he said, only bolded and underlined. > > Antoine> I'm not sure what the issue is. Is there something, concretely, > Antoine> that needs to be fixed? > > Strictly speaking, nothing needs to be "fixed" because nothing

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

On Wed, 19 Jan 2011 19:20:01 +0100 Michael Foord wrote: > On 19/01/2011 19:10, s...@pobox.com wrote: > > Antoine> Ok, thank you but... are you suggesting something or not? > > > > Yes. Keep the vcs command recommendations simple. At least mention idioms > > which likely to apply across a w

Re: [Python-Dev] devguide: Cover how to (un-)apply a patch.

> > The revert works with svn, hg and bzr. Using patch is not going to work on > > Windoze unless cygwin has been installed. > > I thought you were supposed to use some variant of "update" on hg > instead revert, though. I think what is discouraged is to "hg revert" to a different revision. We a

Re: [Python-Dev] Moving stuff out of Misc and over to the devguide

On Wed, 19 Jan 2011 15:31:24 -0800 Brett Cannon wrote: > OK, here is my plan that I will implement: > > MOVE > -- > developers.txt > maintainers.rst > README.gdb > README.coverity > README.Emacs > > DELETE (seem way too old to still be relevant; tell me if I am wrong) > --- > REA

Re: [Python-Dev] r88122 - python/branches/py3k/Doc/whatsnew/3.2.rst

On Thu, 20 Jan 2011 10:47:04 +0100 (CET) raymond.hettinger wrote: > > +Code Repository > +=== > + > +In addition to the existing Subversion code repository at > http://svn.python.org > +there is now a `Mercurial `_ repository at > +http://hg.python.org

<    28   29   30   31   32   33   34   35   36   37   >