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 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
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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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:
> 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
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
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
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
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 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
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
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
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
_
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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 Tue, Jan 10, 2012 at 6:09 PM, "Martin v. Löwis" wrote:
> IOW, I think it is all fine the way it is. Typically, somebody answers
> quickly. In this case, *two* people answered the same, which
> a) really gets the message through, and
> b) suggests that people are not too tired in actually typing
2012/1/5 Charles-François Natali :
> Hi,
>
> Issue #13697 (http://bugs.python.org/issue13697) deals with a problem
> with the Python version of threading.RLock (a signal handler which
> tries to acquire the same RLock is called right at the wrong time)
> which doesn't affect the C version.
> Whethe
On Wed, Jan 4, 2012 at 12:59 AM, Maciej Fijalkowski wrote:
> On Wed, Jan 4, 2012 at 12:02 AM, Bill Janssen wrote:
>> Christian Heimes wrote:
>>
>>> Am 29.12.2011 12:13, schrieb Mark Shannon:
>>> > The attack relies on being able to predict the hash value for a given
>>> > string. Randomising the
On Wed, Dec 28, 2011 at 6:28 PM, Michael Foord
wrote:
> Hello all,
>
> A paper (well, presentation) has been published highlighting security
> problems with the hashing algorithm (exploiting collisions) in many
> programming languages Python included:
>
>
> http://events.ccc.de/congress
re-sending with subject :)
On Mon, Dec 12, 2011 at 2:44 PM, Eric Snow wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities:
>> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n03
Guido posted this on Google+:
> IEEE/ISO are working on a draft document about Python vulunerabilities:
> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf
> (in the context of a larger effort to classify vulnerabilities in all
> languages: ISO/IEC TR 24772
On Fri, Oct 7, 2011 at 4:18 AM, Glyph wrote:
> On Oct 7, 2011, at 5:10 AM, Stephen J. Turnbull wrote:
>
> The principle here is "ran as root" without further explanation is a
> litmus test for "not bothering about security", even today. It's
> worth asking for explanation, or at least a comment t
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman wrote:
> Good points. So how about:
>
> some_name_here(start, stop, *, step=None, count=None)
>
> ? I personally would use the step value far more often than the count
> value.
Let's call it xrange() or maybe range_ex().But seriously,
here's an
On Wed, Aug 10, 2011 at 10:19 AM, Brian Curtin wrote:
> On Wed, Aug 10, 2011 at 11:14, Vlad Riscutia wrote:
>>
>> Removing GIL is interesting work and probably multiple people are willing
>> to contribute. Threading and synchronization is a deep topic and it might be
>> that if just one person to
On Sun, Jul 24, 2011 at 12:54 AM, Nick Coghlan wrote:
> On Sun, Jul 24, 2011 at 3:05 PM, Eric Snow
> wrote:
>> Are there other objects in the interpreter state that are exposed in
>> sys that would have the same problem?
>
> Rebinding (rather than mutating) any globa
On Sat, Jul 23, 2011 at 10:55 PM, Benjamin Peterson wrote:
> 2011/7/23 Eric Snow :
>> The documentation[1] doesn't say, but the implementation of the imp
>> module makes me wonder if sys.modules was not meant to be replaceable.
>> No doubt this has to do with its tie to
The documentation[1] doesn't say, but the implementation of the imp
module makes me wonder if sys.modules was not meant to be replaceable.
No doubt this has to do with its tie to the interpreter's modules
dict. I ran into this doing "sys.modules = sys.modules.copy()" to
protect the actual sys.mod
On Wed, Jul 20, 2011 at 7:52 PM, Nick Coghlan wrote:
> Even better would be for these (and sys.path) to be list subclasses
> that did the right thing under the hood as Glenn suggested. Code that
> *replaces* rather than modifies these attributes would still
> potentially break virtual packages, bu
On Wed, Jul 20, 2011 at 2:44 PM, P.J. Eby wrote:
> At 01:35 PM 7/20/2011 -0600, Eric Snow wrote:
>>
>> This is a really nice solution. So a virtual package is not imported
>> until a submodule of the virtual package is successfully imported
>
> Correct...
>
>&g
On Wed, Jul 20, 2011 at 11:04 AM, P.J. Eby wrote:
> Hm. Here's another variant that might be easier to implement (even in C),
> and could offer some other advantages as well.
>
> Suppose we replace the sys.virtual_packages set() with a sys.virtual_paths
> dict(): a dictionary that maps from modul
On Wed, Jul 20, 2011 at 12:03 PM, Kerrick Staley wrote:
> On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote:
>> Done: http://www.python.org/dev/peps/pep-0394/
>
> Quick question: When I do "svn up", it doesn't show any changes. Has
> it been switched over to Mercurial recently?
http://hg.pytho
On Wed, Jun 29, 2011 at 10:05 PM, Jesse Noller wrote:
> I've posted a more expansive entry on my blog:
> http://jessenoller.com/2011/06/29/announcing-the-new-speed-python-org-machine/
>
> But the short version, that as discussed at the VM and language
> summit, we now have a hosted machine dedicat
On Tue, Jun 28, 2011 at 7:20 AM, Steven D'Aprano wrote:
> Michael Foord wrote:
>
>> What do you mean by "instances can have methods as instance attributes"?
>> Once you attach a bound method directly to an instance it becomes a slightly
>> different beast I think. (On top of which that is pretty r
On Tue, Jun 28, 2011 at 5:35 AM, Michael Foord
wrote:
>
> Well, they're *usually* implemented as methods and backed by a real instance
> attribute. Usually (but not always) it makes more sense (IME) to group them
> with methods. The fact that they're *accessed* as an attribute is the
> uninteresti
On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney wrote:
> Rob Cliffe writes:
>
>> 'function attributes' ? 'def attributes' ?
>
> -1. They don't have to be functions, and hence don't have to be created
> by 'def'.
>
>> Or just stick with method attributes' ?
>
> "callable attributes" describes exactly
On May 9, 2011 6:59 AM, "Eli Bendersky" wrote:
>
> Hi all,
>
> It's a known Python gotcha (*) that the following code:
>
> x = 5
> def foo():
> print(x)
> x = 1
> print(x)
> foo()
>
> Will throw:
>
>UnboundLocalError: local variable 'x' referenced before assignment
>
> On the u
On Sat, Apr 16, 2011 at 3:54 PM, Antoine Pitrou wrote:
>
> Hmm, what's the difference between "the Python stdlib" and "CPython's
> stdlib"?
>
> I'm also not sure how you would enforce that anyway. If it means
> using ctypes to interface with system C libraries, I'm -10 on it :)
>
>
Sounds like Br
ing text editors,
> syntax highlighters, etc; insert usual Alan Perlis quote about syntactic
> sugar causing cancer of the semicolon)
>
> Also, insert usual comments about the need to think about how
> non-CPython implementations of Python would go about implementing such
> idea
I see your point, but doesn't python-list already fill the role you indicate
may be diminished? Seems like the new list is meant to fill a different
need. Perhaps one concern would be over-use of the mentoring list when
someone would be fine with python-list. I just don't see people turning
away
13, 2010 10:07 AM
To: Eric Snow
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Proposed tweaks to functools.wraps
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote:
> Actually, what is the problem with having all decorators add a __decorated__
> to the function that ultimately gets re
Actually, what is the problem with having all decorators add a __decorated__ to
the function that ultimately gets returned, pointing to the function they
decorated? I guess I never saw that discussion. Perhaps set it to None when
the decorator is the same as the decorated (no wrapping involved
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it
first because constrained this way.
http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
-eric
-Original Message-
From: python-dev-bounces+esnow=verio@python.org
[mailto:python-de
501 - 572 of 572 matches
Mail list logo
