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, you've done a masterful job at balanc
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, you've done a masterful job at balancing and addressing the input from
the Python development communit
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 May 15, 2012, at 10:26 AM, Eric Snow wrote:
>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.
It looks great to me. If I were the PEP czar , I'd approve it
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 5/12/2012 10:50 AM, Eric Snow wrote:
given a normal (dict-based)
object you can use vars() to turn it into a dict:
>>> data = SomeClass(a=1, b=2, c=3)
>>> ns = vars(data)
>>> ns['a']
1
>>> ns['b']
2
>>> ns['c']
3
I'll grant that it doesn't work for some objects (like named tuples)
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 over
attribute-access, please elaborate. I'm just not seeing it as that
important and
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 over
>>> attribute-access, please elabo
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 finish up the PEP as simply as po
-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 over
>> attribute-access, please elaborate. I'm just not seeing it as that
>> important and would rath
On May 12, 2012, at 10:04 PM, 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 finish up the PEP as simply as possible.
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 finish up the PEP as simply as possible.
I object to adding a new type to the stdlib just for
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
The specific reason cache_tag is mandatory is so that importlib can rely on
it. Setting it to None for a given implementation will automatically
disable caching of bytecode files.
--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing
On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano wrote:
>> Aye. Add a rule that all implementation specific (i.e. not defined in
>> the PEP) keys must be prefixed with an underscore and I'm sold.
>
>
> So now we're adding a new convention to single underscore names? Single
> underscore names are i
No, they're private keys for the benefit of the implementation authors.
Still, it's already the case that underscore prefixed names are sometimes
used just for namespace separation (e.g. collections.namedtuple)
--
Sent from my phone, thus the relative brevity :)
__
Scott Dial wrote:
On 5/10/2012 1:40 AM, Nick Coghlan wrote:
Unordered types can be a PITA for testing, for display and for generic
serialisation, so I definitely want to see a PEP before we add a new
one that basically has its sole reason for existence being "you can
iterate over and index the f
Nick Coghlan wrote:
On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote:
On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan wrote:
The original concern (that sys.implementation may differ in length
across implementations) has been eliminated by moving all
implementation specific values into sy
On May 10, 2012, at 10: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 guess the question is whether immutability is useful to preser
On 5/10/2012 1:40 AM, Nick Coghlan wrote:
> Unordered types can be a PITA for testing, for display and for generic
> serialisation, so I definitely want to see a PEP before we add a new
> one that basically has its sole reason for existence being "you can
> iterate over and index the field values i
On 5/10/2012 10:42 AM, Georg Brandl wrote:
On 10.05.2012 10:57, Antoine Pitrou wrote:
On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan wrote:
The original concern (that sys.implementation may differ in length
across implementations) has been eliminated by moving all
implementation specific val
On 10.05.2012 10:57, Antoine Pitrou wrote:
> On Thu, 10 May 2012 11:33:14 +1000
> Nick Coghlan wrote:
>>
>> The original concern (that sys.implementation may differ in length
>> across implementations) has been eliminated by moving all
>> implementation specific values into sys.implementation.met
On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote:
> On Thu, 10 May 2012 11:33:14 +1000
> Nick Coghlan wrote:
>>
>> The original concern (that sys.implementation may differ in length
>> across implementations) has been eliminated by moving all
>> implementation specific values into sys.implem
On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan wrote:
>
> The original concern (that sys.implementation may differ in length
> across implementations) has been eliminated by moving all
> implementation specific values into sys.implementation.metadata.
Uh. It's scary the kind of things people so
On Thu, May 10, 2012 at 3:34 PM, "Martin v. Löwis" wrote:
>> We've been over this before: collections.namedtuple *is* the standard
>> library's answer for structured records.
>
>
> And I think it's a really ugly answer, and one that deserves a parallel
> that is not a tuple. If this is contentious
We've been over this before: collections.namedtuple *is* the standard
library's answer for structured records.
And I think it's a really ugly answer, and one that deserves a parallel
that is not a tuple. If this is contentious, I'll write a PEP.
Regards,
Martin
_
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 May 09, 2012, at 05:47 PM, Larry Hastings wrote:
>I like Alex Martelli's approach, which I recall was exactly this:
>
>class namespace:
> def __init__(**kwargs):
> self.__dict__ = kwargs
>
>
>That means all the initializers you pass in to the constructor get turned
>into
On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw wrote:
> On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>
>>Sure, but couldn't we define this "empty" class in C code so that you can
>>use the C API with it as well and just provide a C function to get a new
>>instance?
>
> +1
>
> ISTM to be a comp
On 05/09/2012 09:53 AM, Barry Warsaw wrote:
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?
+1
ISTM to be a companion to collections.n
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.implementation for now, in the
>
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>Sure, but couldn't we define this "empty" class in C code so that you can
>use the C API with it as well and just provide a C function to get a new
>instance?
+1
ISTM to be a companion to collections.namedtuple. IWBNI this new type was
also exp
On May 09, 2012, at 08:51 AM, Eric Snow wrote:
>The type for sys.implementation has slowly shifted from the original
>proposal. At this point it's settled into where I think it will stay,
>a custom type. I've covered the choice of type in the rationale
>section. However, there may be merit in n
Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?
That would be easy. All you need is a dictoffset.
Regards,
Martin
___
Python-Dev mailing lis
On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>> This is defined as the version of the implementation, while
>> sys.version_info is the version of the language. The semantics of
>> sys.version_info have been sufficiently squishy in the past, as the XXX
>> implies. This PEP shouldn't try
On Wed, May 9, 2012 at 10: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
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, 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.
>
>
> I have heard this request now a bazillion times over the ye
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 5:57 AM, "Martin v. Löwis" wrote:
> On 27.04.2012 09:34, Eric Snow wrote:
>
>> 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
On 27.04.2012 09:34, Eric Snow wrote:
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
Interesting p
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
>
Hi Eric,
Great job on the latest PEP 421. I really like it. A few additional
comments/questions.
* sys.implementation.version
This is defined as the version of the implementation, while
sys.version_info is the version of the language. The semantics of
sys.version_info have been suff
On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman wrote:
> Here's a ponderable: In the long term, should the documentation be unified
> for multiple implementations? Or should it be split into 4 pieces, so that
> alternate implementations could swap in their own sections for
> implementation depen
On 4/27/2012 11:49 AM, R. David Murray wrote:
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman
wrote:
On 4/27/2012 12:34 AM, Eric Snow wrote:
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 woul
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman
wrote:
> On 4/27/2012 12:34 AM, Eric Snow wrote:
> > 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:/
On 4/27/2012 12:34 AM, Eric Snow wrote:
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
The idea of
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 04/25/2012 10:31 PM, Eric Snow wrote:
The patch adds a struct sequence that holds ("name" => "CPython",
"version" => sys.version_info). If later needs dictate more fields,
we can cross that bridge then.
My one bit of bike-shedding: I don't think it's desirable that this
object be iterabl
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 a PEP couldn't hurt. The
> ra
On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:
>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
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
55 matches
Mail list logo
