On Tue, Jan 17, 2012 at 1:34 PM, Antoine Pitrou wrote:
> Under the proposed scheme, there would be two kinds of feature
> versions (sometimes dubbed "minor versions", for example 3.2 or 3.3):
> normal feature versions and long-term support (LTS) versions.
...
> A new feature version would be relea
On Wed, Jan 18, 2012 at 5:01 PM, Ethan Furman wrote:
> Is there a reason why normal classes can't have their __doc__ strings
> rewritten? Creating a do-nothing metaclass seems like overkill for such a
> simple operation.
>
> Python 3.2 ... on win32
> --> class Test():
> ... __doc__ = 'am I perm
On Jan 19, 2012 9:28 AM, "Bill Janssen" wrote:
> I'm not sure how much of a problem this really is. I continually build
> fairly complicated systems with Python that do a lot of HTTP networking,
> for instance. It's fairly easy to replace use of the standard library
> modules with use of Tornado
On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
> There are many reasons to import a module, such as viewing its
> documentation. And the warning will trigger if the import happens in
> non-user code, such as a library; or when there is a fallback for the
> module not being present. People
On Sat, Jan 28, 2012 at 4:08 PM, Antoine Pitrou wrote:
> Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
>> On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou wrote:
>> > There are many reasons to import a module, such as viewing its
>> > documentation. And
On Feb 5, 2012 5:36 PM, "Steven D'Aprano" wrote:
>
> Paul Moore wrote:
>>
>> On 4 February 2012 11:25, Steven D'Aprano wrote:
>>>
>>> It strikes me that it would be helpful sometimes to programmatically
>>> recognise "preview" modules in the std lib. Could we have a
recommendation
>>> in PEP 8 th
On Tue, Feb 7, 2012 at 8:47 PM, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 12:54 PM, Terry Reedy wrote:
>> On 2/7/2012 9:35 PM, PJ Eby wrote:
>>> It's just that not everything I write can depend on Importing.
>>> Throw an equivalent into the stdlib, though, and I guess I wouldn't have
>>> to w
On Fri, Feb 10, 2012 at 1:13 PM, Jim J. Jewett wrote:
>
> Eli Bendersky wrote (in
> http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
>
>> A package will be marked provisional by including the
>> following paragraph as a note at the top of its
>> documentation page:
>
> I re
On Fri, Feb 10, 2012 at 8:10 PM, Eli Bendersky wrote:
> On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett wrote:
>>
>> Eli Bendersky wrote (in
>> http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
>>
>>> A package will be marked provisional by including the
>>> following paragrap
On Fri, Feb 10, 2012 at 11:32 PM, Nick Coghlan wrote:
> On Sat, Feb 11, 2012 at 1:39 PM, Eric Snow
> wrote:
>> Is there more to it than having a simple __provisional__ attribute on
>> the module and/or a list at sys.provisional_modules?
>
> Yes. As soon as we touch fun
On Sat, Mar 3, 2012 at 4:11 PM, Victor Stinner wrote:
> Le 29/02/2012 19:21, Victor Stinner a écrit :
>>
>> Rationale
>> =
>>
>> (...) Use cases of frozendict: (...)
>
>
> I updated the PEP to list use cases described in the other related mailing
> list thread.
> ---
> Use cases:
>
> * fr
On Apr 5, 2012 11:01 AM, "Guido van Rossum" wrote:
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fix" timeouts) was implemented by the
> application/library code using the timeout (or provided as a separate
> library function), rather than by the clock, since
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon wrote:
> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In the "ancient" import.c d
On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon wrote:
> An open issue in PEP 302 is whether to require __loader__ attributes on
> modules. The claimed worry is memory consumption, but considering importlib
> and zipimport are already doing this that seems like a red herring.
> Requiring it, though,
On Sat, Apr 14, 2012 at 4:16 PM, Brett Cannon wrote:
> Once again, it's just code that needs updating to run on Python 3.3 so I
> don't view it as a concern. Going from list.append() to list.insert() (even
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.
I'm fine with that.
On Mon, Apr 16, 2012 at 11:32 AM, Brett Cannon wrote:
>
>
> On Mon, Apr 16, 2012 at 13:04, "Martin v. Löwis" wrote:
>>
>> > I don't see how depending on Cython is better than depending on having
>> > an existing Python. If the only benefit is semi-readable code, surely
>> > we do have source cod
On Wed, Apr 18, 2012 at 8:21 AM, Antoine Pitrou wrote:
> (and here we see why reference-stealing APIs are a nuisance: because
> you never know in advance whether a function will steal a reference or
> not, and you have to read the docs for each and every C API call you
> make)
+1
-eric
_
How closely is tokenize.detect_encoding() supposed to match
PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
difference in their behavior that has bearing on PEP 263 handling
during import. [1] Should any difference be considered a bug, or
should I work around it? Thanks.
-er
Forgot the subject (going to bed now).
On Thu, Apr 19, 2012 at 2:00 AM, Eric Snow wrote:
> How closely is tokenize.detect_encoding() supposed to match
> PyTokenizer_FindEncoding()? From what I can tell, there is a subtle
> difference in their behavior that has bearing on PEP 263
On Fri, Apr 20, 2012 at 7:54 AM, Eric V. Smith wrote:
> 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
On Apr 21, 2012 7:11 AM, "Nick Coghlan" wrote:
>
> The internal dictproxy class was recently exposed as
types.MappingProxyType.
>
> Since it's not very discoverable that way, would anyone object if I
> moved things around so it was exposed as collections.MappingProxy
> instead? The main benefit to
On Sat, Apr 21, 2012 at 4:17 PM, Brett Cannon wrote:
> On Sat, Apr 21, 2012 at 12:10, Barry Warsaw wrote:
>> Strictly speaking, I do think you need to deprecate the APIs. I like
>> Nick's
>> suggestion to make them C wrappers which just call back into Python.
>
>
> That was my plan, but the amou
It looks like the test suite accommodates a stable import state to
some extent, but would it be worth having a PEP-405-esque context
manager to help with this? For example, something along these lines:
class ImportState:
# sys.modules is part of the interpreter state, so
# repopulate (do
The proposal of adding sys.implementation has come up a couple times
over the last few years. [1][2] While the reaction has been
overwhelmingly positive, nothing has come of it. I've created a
tracker issue and a patch:
http://bugs.python.org/issue14673
The patch adds a struct sequence that
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw wrote:
> On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:
>>Are there any objections? Considering the positive reaction and the
>>scope of the addition, does this need a PEP?
>
> It's somewhat of a corner case, but I think
On Thu, Apr 26, 2012 at 9:29 PM, Larry Hastings wrote:
> My one bit of bike-shedding: I don't think it's desirable that this object
> be iterable. Therefore I suggest you don't use struct sequence.
Good point. Noted.
-eric
___
Python-Dev mailing list
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw wrote:
> It's somewhat of a corner case, but I think a PEP couldn't hurt. The
> rationale section would be useful, at least.
http://mail.python.org/pipermail/python-ideas/2012-April/014954.html
-eric
___
On Fri, May 4, 2012 at 10:07 AM, Python tracker wrote:
>
> ACTIVITY SUMMARY (2012-04-27 - 2012-05-04)
> Python tracker at http://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues counts and deltas:
> open
On Mon, May 7, 2012 at 6:15 AM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 9:54 PM, Georg Brandl wrote:
>> As for build_class: at the moment the types module really only has types,
>> and to add build_class there is just about as weird as in operator IMO.
>
> Oh no, types is definitely less wei
On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw wrote:
> Hi Eric,
>
> Great job on the latest PEP 421. I really like it.
Encouragement appreciated. :)
> A few additional
> comments/questions.
>
> * sys.implementation.version
>
> This is defined as the version of the implementation, while
>
On Wed, May 9, 2012 at 3:05 AM, Steven D'Aprano wrote:
> I understand that at the language summit, this was
> considered a good idea:
>
> http://python.6.n6.nabble.com/Callable-non-descriptor-class-attributes-td1884829.html
FYI, this was at the 2011 language summit
-eric
On Wed, May 9, 2012 at 3:57 AM, "Martin v. Löwis" wrote:
> Interesting proposal. I have a number of comments:
Thanks for taking a look, Martin.
> - namespace vs. dictionary. Barry was using it in the form
> sys.implementation.version. I think this is how it should work,
> yet the PEP says that
On Wed, May 9, 2012 at 8:44 AM, Brett Cannon wrote:
> On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis"
> wrote:
>> [Update: it seems this is already reflected in the PEP. I wonder
>> where the requirement for "a new type" comes from. I think making
>> it a module should be conforming, even
On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou wrote:
> On Wed, 9 May 2012 10:44:59 -0400
> Brett Cannon wrote:
>>
>> > I wish there was a builtin class
>> >
>> > class record:
>> > pass
>> >
>> > which can be used to create objects which have only attributes
>> > and no methods.
>
On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw wrote:
> On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>>Definitely tangled. So, sys.implementation.version and
>>sys.implementation.lang_version? Also, my inclination is to not have
>>a sys.version equivalent in sys.implement
On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan wrote:
> Please, no. No new
> just-like-a-namedtuple-except-you-can't-iterate-over-it type, and
> definitely not one exposed in the collections module.
>
> We've been over this before: collections.namedtuple *is* the standard
> library's answer for stru
On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou wrote:
> sys.implementation.metadata looks like a completely over-engineered
> concept. Please, let's just make sys.implementation a dict and stop
> bothering about ordering and iterability.
I'm fine with ditching "metadata". The PEP will say
sys.i
On Sat, May 12, 2012 at 6:04 AM, Nick Coghlan wrote:
> On Sat, May 12, 2012 at 12:40 PM, Eric Snow
> wrote:
>> If anyone has strong feelings for item-access over attribute-access,
>> please elaborate. I'm just not seeing it as that important and would
>> rather f
On Sat, May 12, 2012 at 8:35 AM, Barry Warsaw wrote:
> I'm okay with dropping immutability for sys.implementation, but I still think
> attribute access is a more useful model. You can easily support both getattr
> and getitem with a class instance, so I think that's the way to go.
>
> (FWIW, immu
On Sat, May 12, 2012 at 10:51 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/12/2012 08:04 AM, Nick Coghlan wrote:
>> On Sat, May 12, 2012 at 12:40 PM, Eric Snow
>> wrote:
>>> If anyone has strong feelings for item-access
At this point I'm pretty comfortable with where PEP 421 is at. Before
asking for pronouncement, I'd like to know if anyone has any
outstanding concerns that should be addressed first.
The only (relatively) substantial point of debate has been the type
for sys.implementation. The PEP now limits t
PEP 421 has reached a good place and I'd like to ask for pronouncement. Thanks!
-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/ar
On Thu, May 24, 2012 at 12:33 PM, Guido van Rossum wrote:
> I've reviewed the updates to the PEP and have accepted it. Congrats all!
Congrats!
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Fri, May 25, 2012 at 12:23 PM, Barry Warsaw wrote:
> On May 17, 2012, at 07:19 AM, Eric Snow wrote:
>
>>PEP 421 has reached a good place and I'd like to ask for pronouncement.
>
> As the newly self-appointed PEP 421 czar, I hereby accept this PEP.
>
> Eric, y
The implementation for sys.implementation is going to use a new (but
"private") type[1]. It's basically equivalent to the following:
class namespace:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
def __repr__(self):
keys = (k for k in self.__dict__ if not k.st
On Thu, May 31, 2012 at 9:06 AM, Barry Warsaw wrote:
> On May 31, 2012, at 10:31 PM, Nick Coghlan wrote:
>
>>Personally, I suggest we just expose the new type as
>>types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace
>>= type(sys.implementation)" and call it done.
>
> Great idea,
On Fri, Jun 1, 2012 at 6:07 AM, Nick Coghlan wrote:
> There may be other CPython-specific fields currently in sys.version
> that it makes sense to also include in sys.implementation, but:
> 1. That's *as well as*, not *instead of*
> 2. It's something that can be looked at *after* the initial
> imp
On Fri, Jun 1, 2012 at 7:17 AM, Mark Shannon wrote:
> Previously you said that "it needs to handled in the implementation
> language, and explicitly *not* in Python".
> I asked why that was.
>
> Now you seem to be suggesting that Python code would break the DRY rule,
> but the C code would not. If
On Thu, May 31, 2012 at 9:08 PM, Barry Warsaw wrote:
> On Jun 01, 2012, at 11:49 PM, Nick Coghlan wrote:
>
>>The long term goal here is that all the code in the standard library
>>should be implementation independent - PyPy, Jython, IronPython, et al
>>should be able to grab it and just run it. Th
On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby wrote:
> I mean that class-level __metaclass__ is no longer supported as of PEP 3115,
> so I can't use that as a way to non-invasively obtain the enclosing class at
> class creation time.
Depends on what you mean by non-invasive:
* http://code.activestate.c
On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov wrote:
> On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
>> Functions already record their name (twice!), and it is simple enough to
>> query func.__name__. What reason is there for recording it a third time, in
>> the Signature object?
>
> Sign
On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan wrote:
> +
> +Alternatives
> +
> +
Would it be worth also (briefly) rehashing why the class instance
couldn't be created before the class body is executed*? It might seem
like a viable alternative if you haven't looked at how classes get
c
On Wed, Jun 6, 2012 at 11:28 AM, Yury Selivanov wrote:
> Never copy attributes by hand, always use 'functools.wraps'. It copies
> '__name__', '__qualname__', and bunch of other attributes to the decorator
> object.
>
> We'll probably extend it to copy __signature__ too; then 'signature(decor(f))'
On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov wrote:
> On 2012-06-06, at 1:02 PM, Eric Snow wrote:
>> I'm with Steven on this one. What's the benefit to storing the name
>> or qualname on the signature object? That ties the signature object
>> to a specif
On Thu, Jun 7, 2012 at 8:12 AM, Larry Hastings wrote:
> On 06/06/2012 06:00 PM, Nick Coghlan wrote:
>
>> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow
>> wrote:
>>
>> Furthermore, using __signature__ as a cache may even cause problems.
>> If the Signature obje
On Fri, Jun 8, 2012 at 12:29 PM, Brett Cannon wrote:
> On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com
> wrote:
>> I think a python-implementations list would be a fantastic idea - I
>> sometimes miss multi-implementation discussions in python-dev, or at
>> least come in very late.
>
>
> If
On Fri, Jun 8, 2012 at 11:08 AM, R. David Murray wrote:
> The are four issues: (1) we build the python3 docs using python2, so 'make
> doctest' on python3 doesn't currently work
For reference: http://bugs.python.org/issue10224. Are there any others?
-eric
___
On Mon, Jun 11, 2012 at 12:58 AM, Nick Coghlan wrote:
> On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum wrote:
>> But what guarantee do you have that (a) the right people sign up for
>> the new list, and (b) topics are correctly brought up there instead of
>> on python-dev? I agree that python
On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote:
> I should mention another option is to add sys.dont_read_bytecode (I think I
> have discussed this with Frank at some point).
Or check for "sys.implementation.cache_tag is None"...
-eric
___
Python
On Thu, Jun 14, 2012 at 9:06 AM, R. David Murray wrote:
> I don't have strong feelings about this, but to me the fact that there
> are values of the individual parameters that if they occur on the same
> object at the same time would be invalid is a code smell. If the thing
> can be one and only
On Thu, Jun 21, 2012 at 2:44 AM, larry.hastings
wrote:
> http://hg.python.org/peps/rev/1edf1cecae7d
> changeset: 4472:1edf1cecae7d
> user: Larry Hastings
> date: Thu Jun 21 01:44:15 2012 -0700
> summary:
> The latest changes from Yury Selivanov. I can almost taste the acceptance
On Fri, Aug 10, 2012 at 2:17 PM, philip.jenvey
wrote:
> http://hg.python.org/cpython/rev/e024f6ba5ed8
> changeset: 78487:e024f6ba5ed8
> user:Philip Jenvey
> date:Fri Aug 10 11:53:54 2012 -0700
> summary:
> update docstring per the extension package fix, refactor
>
> files:
>
On Sat, Aug 11, 2012 at 3:27 PM, "Martin v. Löwis" wrote:
> I think you misunderstood. What gps is concerned about (IIUC) that some
> people add ast optimizers in some run of Python, but other AST optimizers in
> a different run. Then, if you use a Python byte code
> file, you should be able to fi
On Sat, Aug 11, 2012 at 6:03 PM, Brett Cannon wrote:
> It would also be very easy to expand importlib.abc.SourceLoader to add a
> method which is called with source and returns the bytecode to be written
> out
Yes, please. Not having to hack around this would be nice.
> which people could overr
On Aug 12, 2012 12:56 PM, "PJ Eby" wrote:
> I'm not sure if this is directly related or not, but making this
> mechanism support custom compilation for new filename suffixes would
> be nice, especially for various e.g. HTML/XML templating systems that
> compile to Python or bytecode.
>
> Specifica
On Wed, Aug 15, 2012 at 8:49 AM, Daniel Holth wrote:
> I've drafted some edits to Metadata 1.2 with valuable feedback from
> distutils-sig (special thanks to Erik Bray), which seems to have no
> more comments on the issue after about 6 weeks. Let me know if you
> have an opinion, or if you will ha
On Wed, Oct 3, 2012 at 8:55 AM, Nick Coghlan wrote:
> I *can't* effectively trial
> those changes on PyPI (except perhaps some of the disassembly
> changes), and I don't have the resources to create and distribute
> Windows and Mac OS X installers on my own. That means, before the
> release of 3.4
On Fri, Nov 2, 2012 at 11:07 AM, Python tracker wrote:
>
> ACTIVITY SUMMARY (2012-10-26 - 2012-11-02)
> Python tracker at http://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues counts and deltas:
> open
On Sun, Nov 11, 2012 at 1:53 PM, Christian Tismer wrote:
> Once again on this:
>
> With the introduction of module folders
> without __init__, it has become even harder to deduce a sensible project
> root
> Dir without relying on a global settings file. Abd as you probably agree,
> such files are
On Thu, Nov 22, 2012 at 5:09 AM, Nick Coghlan wrote:
> On Thu, Nov 22, 2012 at 9:44 PM, Kristján Valur Jónsson
> wrote:
>>
>> Where in the tracker? I tried searching but didn’t find it.
>
>
> This one: http://bugs.python.org/issue13475
>
> This and the issue about being able to configure coverag
On Tue, Nov 27, 2012 at 9:19 PM, Eric Snow wrote:
> On Thu, Nov 22, 2012 at 5:09 AM, Nick Coghlan wrote:
>> On Thu, Nov 22, 2012 at 9:44 PM, Kristján Valur Jónsson
>> wrote:
>>>
>>> Where in the tracker? I tried searching but didn’t find it.
>>
>>
&
On Thu, Dec 13, 2012 at 1:57 PM, Chris Angelico wrote:
> The default version shown on http://docs.python.org/ is now 3.3.0,
> which I think is a Good Thing. However, http://python.org/download/
> puts 2.7 first, and says:
>
> """If you don't know which version to use, start with Python 2.7; more
>
501 - 572 of 572 matches
Mail list logo
