Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/21/2012 07:25 PM, Nick Coghlan wrote: > As a simple example to back up PJE's explanation, consider: > 1. encodings becomes a namespace package > 2. It sometimes gets imported during interpreter startup to initialise > the standard io streams > 3. An application modifies sys.path after startu

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/21/2012 2:08 PM, PJ Eby wrote: > On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum > wrote: > > Ah, I see. But I disagree that this is a reasonable constraint on > sys.path. The magic __path__ object of a toplevel namespace module > should know it is a to

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/20/2012 9:33 PM, Guido van Rossum wrote: > Generally speaking the PEP is a beacon if clarity. But I stumbled > about one feature that bothers me in its specification and through its > lack of rationale. This is the section on Dynamic Path Computation: > (http://www.python.org/dev/peps/pep-0420

Re: [Python-Dev] [Python-checkins] cpython: avoid unitialized memory

On 5/4/2012 1:14 AM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/b0deafca6c02 > changeset: 76743:b0deafca6c02 > user:Benjamin Peterson > date:Fri May 04 01:14:03 2012 -0400 > summary: > avoid unitialized memory > > files: > Modules/posixmodule.c | 2 +- > 1

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

On 5/1/2012 8:11 AM, Eric V. Smith wrote: > On 5/1/2012 7:57 AM, Georg Brandl wrote: >> With 3.3a3 tagged and the beta stage currently 2 months away, I would like >> to draw your attention to the following list of possible features for 3.3 >> as specified by PEP 398: > ...

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

On 5/1/2012 7:57 AM, Georg Brandl wrote: > With 3.3a3 tagged and the beta stage currently 2 months away, I would like > to draw your attention to the following list of possible features for 3.3 > as specified by PEP 398: ... > Also, if I missed any obvious candidate PEP or change, please let me kn

Re: [Python-Dev] [Python-checkins] devguide: Record Richard Oudkerk.

> +- Richard Oudkerk was given push privileges on Apr 29 2012 by Antoine Pitrou > + on recommendation by Charles-François Natali and Jesse Noller, for various > + contributions to multiprocessing (and original authorship of > + multiprocessing's predecessor, the processing package). Could one o

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

On 4/29/2012 4:41 AM, Larry Hastings wrote: > On 04/28/2012 04:20 PM, Eric V. Smith wrote: >> But we generally use a namedtuple (or structseq) for things like >> get_clock_info. For example, for sys.float_info there's no need for it >> to be a tuple, and it can be extend

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

On 4/27/2012 11:40 PM, Guido van Rossum wrote: > On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano wrote: >> 2) get_clock_info returns a dict. Why not a namedtuple? > > Future flexibility. And there's no need for it to be a *tuple*. I haven't been paying attention to this discussion, so this isn'

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On 04/20/2012 10:59 AM, Brett Cannon wrote: > > > On Fri, Apr 20, 2012 at 09:54, Eric V. Smith <mailto:e...@trueblade.com>> wrote: > > On 04/14/2012 02:12 PM, Brett Cannon wrote: > > My multi-year project -- started in 2006 according to my blog -- to

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On 04/14/2012 02:12 PM, Brett Cannon wrote: > My multi-year project -- started in 2006 according to my blog -- to > rewrite import in pure Python and then bootstrap it into CPython as > *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I

Re: [Python-Dev] [Python-checkins] peps: Note that ImportError will no longer be raised due to a missing __init__.py

ith <mailto:python-check...@python.org>> wrote: > > http://hg.python.org/peps/rev/af61fe9a56fb > changeset: 4281:af61fe9a56fb > user:Eric V. Smith <mailto:e...@trueblade.com>> > date:Thu Apr 19 18:56:22 2012 -0400 > summary:

[Python-Dev] PEP 420: Implicit Namespace Packages

If you have any comments, please join the discussion over in import-sig. Eric. ___ 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%40

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

On 4/17/2012 5:52 AM, Antoine Pitrou wrote: > On Mon, 16 Apr 2012 20:41:56 -0400 > Brett Cannon wrote: >> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou wrote: >> >>> On Tue, 17 Apr 2012 01:11:14 +0200 >>> Georg Brandl wrote: No, it's not just an existing Python, it is (at least current

Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default

On 3/17/2012 4:47 PM, Michael Foord wrote: > > On 17 Mar 2012, at 08:49, Georg Brandl wrote: > >> On 03/15/2012 01:17 AM, victor.stinner wrote: >>> + If available, a monotonic clock is used. By default, if *strict* is >>> False, >>> + the function falls back to another clock if the monotoni

Re: [Python-Dev] [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?

And of course I meant import-sig. -- Eric. "Eric V. Smith" wrote: I think restarting the discussion anew here on distutils-sig is appropriate. -- Eric. Guido van Rossum wrote: Martin has asked me to decide on PEP 382 vs. PEP 402 (namespace packages) in time for inclusion of the d

Re: [Python-Dev] [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?

I think restarting the discussion anew here on distutils-sig is appropriate. -- Eric. Guido van Rossum wrote: Martin has asked me to decide on PEP 382 vs. PEP 402 (namespace packages) in time for inclusion of the decision in Python 3.3. As people who attended the language-sig know, I am leaning

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On 2/25/2012 11:50 AM, Antoine Pitrou wrote: >> The problem is that you can't say "my code works on Python 3.3". You now >> have to specify the micro version number as well: "my code works on >> Python 3.3.1+". We've made this mistake before; I can't see it happening >> again. > > I don't see how

Re: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library

On 2/25/2012 11:18 AM, Zachary Ware wrote: > Anyhow; I have to say I like Nick's idea put forth in PEP 413, but I > agree that the extra versioning info could get pretty awkward. > Therefore, why not just make stdlib upgrades part of the regular > maintenance releases? As long as there is absolutel

Re: [Python-Dev] PEP 409 - final?

On 2/1/2012 7:49 PM, Nick Coghlan wrote: > On Thu, Feb 2, 2012 at 10:44 AM, Tim Delaney > wrote: >>> 3) Should it be an exception, or just inherit from object? >>> Is it worth worrying about somebody trying to raise it, or >>> raise from it? >> >> If it's not actually an exception, we get prev

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

On 1/28/2012 2:10 AM, Nick Coghlan wrote: > On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull > wrote: >> Executive summary: >> >> If the promise to remove the module from __preview__ is credible (ie, >> strictly kept), then __preview__ will have a specific audience in >> those who want the st

Re: [Python-Dev] str.format implementation

On 12/12/2011 10:56 PM, Ben Wolfson wrote: > Hi, > > I'm hoping to get some kind of consensus about the divergences between > the implementation and documentation of str.format > (http://mail.python.org/pipermail/python-dev/2011-June/111860.html and > the linked bug report contain examples of the

Re: [Python-Dev] [Python-checkins] cpython (2.7): Inline the advisory text on how to use the shelve module.

On 11/4/2011 4:25 PM, Ezio Melotti wrote: > On 04/11/2011 22.21, Eric V. Smith wrote: >> On 11/4/2011 4:08 PM, raymond.hettinger wrote: >> >>> - .. note:: >>> + Like file objects, shelve objects should closed explicitly to assure >>> + that the per

Re: [Python-Dev] [Python-checkins] cpython (2.7): Inline the advisory text on how to use the shelve module.

On 11/4/2011 4:08 PM, raymond.hettinger wrote: > - .. note:: > + Like file objects, shelve objects should closed explicitly to assure > + that the peristent data is flushed to disk. Missing "be" there, I think: "should be closed". Eric. ___ Pytho

Re: [Python-Dev] Packaging and binary distributions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 5:14 PM, Tres Seaver wrote: > On 10/30/2011 02:04 PM, Ned Deily wrote: >> In article >> , > >> > > Paul Moore wrote: > >>> I'd like to reopen the discussions on how the new packaging >>> module will handle/support binary distributio

Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit

What's the logic for adding some braces, but removing others? On 10/19/2011 4:58 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9c79a25f4a8b > changeset: 73010:9c79a25f4a8b > branch: 3.2 > parent: 72998:99a9f0251924 > user:Benjamin Peterson > date:Wed

Re: [Python-Dev] [Python-checkins] cpython: Implement PEP 393.

On 10/1/2011 9:26 AM, "Martin v. Löwis" wrote: > Am 29.09.2011 01:21, schrieb Eric V. Smith: >> Is there some reason str.format had such major surgery done to it? > > Yes: I couldn't figure out how to do it any other way. The formatting > code had a few basic as

Re: [Python-Dev] [Python-checkins] cpython: Implement PEP 393.

Is there some reason str.format had such major surgery done to it? It appears parts of it were removed from stringlib. I had not even thought to look at the code before it was merged, as it never occurred to me anyone would do that. I left it in stringlib even in 3.x because there's the occasional

Re: [Python-Dev] cpython (3.2): NUL -> NULL

On 08/18/2011 02:19 PM, Antoine Pitrou wrote: > On Thu, 18 Aug 2011 17:49:28 +0200 > benjamin.peterson wrote: >> -PyErr_SetString(PyExc_TypeError, "embedded NUL character"); >> +PyErr_SetString(PyExc_TypeError, "embedded NULL character"); > > Are you sure? IIRC, NUL is the little

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On 07/20/2011 08:57 AM, P.J. Eby wrote: > At 06:46 PM 7/20/2011 +1000, Nick Coghlan wrote: >> On Wed, Jul 20, 2011 at 1:58 PM, P.J. Eby wrote: >> > So, without further ado, here it is: >> >> I pushed this version up to the PEPs repo, so it now has a number >> (402) and can be read in prettier HTML

Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing

Jim Jewett wrote: > Rationale for Removing Implicit String Concatenation > > Implicit String concatentation can lead to confusing, or even > silent, errors. [1] > > def f(arg1, arg2=None): pass > > f("abc" "def") # forgot the comma, no warning ... >

Re: [Python-Dev] About SSL tests

Facundo Batista wrote: > Eric V. Smith wrote: > >> Would it not be better to put a platform-independent version of this >> into subprocess, so that this code doesn't have to be duplicated all >> over the place? Maybe a method on a Popen object called terminate()?

Re: [Python-Dev] About SSL tests

[sorry if you see 2 copies of this] Facundo Batista wrote: > The problem of TerminateProcess is that I need the handle of the > process. > > I don't like the idea of rely on the private _handle and do: > > process = subprocess.Popen(...) > ... > subprocess.TerminateProcess(int(process._han

Re: [Python-Dev] Access to bits for a PyLongObject

Martin v. Löwis wrote: > Ah, I had missed the point that it's just binary formatting that > you are concerned with (and then I missed that binary is "base 2", > rather than "sequence of bits") Apologies for not being clear. It's easy to forget that others don't share the context of something you

Re: [Python-Dev] Access to bits for a PyLongObject

Martin v. Löwis wrote: > Eric V. Smith schrieb: >> I'm working on PEP 3101, Advanced String Formatting. About the only >> built-in numeric formatting I have left to do is for converting a >> PyLongOjbect to binary. >> >> I need to know how to access the bit

[Python-Dev] Access to bits for a PyLongObject

I'm working on PEP 3101, Advanced String Formatting. About the only built-in numeric formatting I have left to do is for converting a PyLongOjbect to binary. I need to know how to access the bits in a PyLong. After reading longobject.c, I can figure it out. But I'm looking for something that

Re: [Python-Dev] datetime's strftime implementation: by design or bug

Anthony Baxter wrote: > Please log a bug - this is probably something suitable for fixing in 2.5.1. > At > the very least, if it's going to be limited to 127 characters, it should > check that and raise a more suitable exception. [First time sent from wrong address, sorry if this is a dupe.]

[Python-Dev] datetime's strftime implementation: by design or bug

[I hope this belongs on python-dev, since it's about the design of something. But if not, let me know and I'll post to c.l.py.] I'm willing to file a bug report and patch on this, but I'd like to know if it's by design or not. In datetimemodule.c, the function wrap_strftime() insists that the

<    1   2   3   4   5   6