Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Nick Coghlan 
On Wed, May 9, 2012 at 4:37 PM, Daniel Urban  wrote:
> On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan  wrote:
>> We need the explicitly declared metaclass as well as the bases in
>> order to determine the correct metaclass.
>
> Note, that the current patch (at http://bugs.python.org/issue14588)
> obtains the explicitly declared metaclass from the keywords dict
> (exactly like the class statement).

Ah, good point. In that case, consider me convinced: static method it
is. It can join mro() as the second non-underscore method defined on
type().

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Mark Shannon 

Nick Coghlan wrote:

On Wed, May 9, 2012 at 4:37 PM, Daniel Urban  wrote:

On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan  wrote:

We need the explicitly declared metaclass as well as the bases in
order to determine the correct metaclass.

Note, that the current patch (at http://bugs.python.org/issue14588)
obtains the explicitly declared metaclass from the keywords dict
(exactly like the class statement).


Ah, good point. In that case, consider me convinced: static method it
is. It can join mro() as the second non-underscore method defined on
type().



Be careful adding methods to type. Because type is its own metaclass 
descriptors can appear to add strangely:


int.mro()

[, ]

type.mro()

Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor 'mro' of 'type' object needs an argument

As a consequence of this, making build_class either a class method or a 
static method will cause a direct call to type.build_class() to fail as 
neither class method nor static method are callable.


Cheers,
Mark.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Nick Coghlan 
On Wed, May 9, 2012 at 5:57 PM, Mark Shannon  wrote:
> As a consequence of this, making build_class either a class method or a
> static method will cause a direct call to type.build_class() to fail as
> neither class method nor static method are callable.

We'll make sure it *behaves* like a static method, even if it's
technically something else under the hood.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Mark Shannon 

Nick Coghlan wrote:

On Wed, May 9, 2012 at 5:57 PM, Mark Shannon  wrote:

As a consequence of this, making build_class either a class method or a
static method will cause a direct call to type.build_class() to fail as
neither class method nor static method are callable.


We'll make sure it *behaves* like a static method, even if it's
technically something else under the hood.


What I am saying is that you *don't* want it to behave like a static 
method, you want it to behave like a builtin-function.


Cheers,
Mark.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Steven D'Aprano 
On Wed, May 09, 2012 at 08:57:55AM +0100, Mark Shannon wrote:

> As a consequence of this, making build_class either a class method or a 
> static method will cause a direct call to type.build_class() to fail as 
> neither class method nor static method are callable.

This might be a good reason to make them callable, especially 
staticmethod. 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

It certainly seems long overdue: confusion due to staticmethods 
not being callable go back a long time:

http://stackoverflow.com/questions/3932948/
http://grokbase.com/t/python/python-list/11bhhtv95y/staticmethod-makes-my-brain-hurt
http://mail.python.org/pipermail/python-list/2004-August/272593.html


-- 
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Point of building without threads?

2012-05-09 Thread Stefan Krah 
Antoine Pitrou  wrote:
> > _decimal is about 12% faster without threads, because the expensive
> > thread local context can be disabled.
> 
> If you cached the last thread id along with the corresponding context,
> perhaps it could speed things up in most scenarios?

Nice. This reduces the speed difference to about 4%!


Stefan Krah



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-09 Thread Martin v. Löwis 

Is there a better way?


Dear Alex,

As Terry indicates: python-dev is a list for the development *of* 
Python, not the development *with* Python. Use the general python-list

or the xml-sig list for this kind of question.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Martin v. Löwis 

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 proposal. I have a number of comments:

- 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 sys.implementation is a dictionary, which
  means that you would need to write
  sys.implementation['version']

  I think the PEP should be silent on the type of sys.implementation,
  in particular, it should not mandate that it be a module (else
  "from sys.implementation import url" ought to work)

  [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 though probably discouraged
   for cpython, as it would make people think that they can rely on
   it being a module. I wish there was a builtin class

 class record:
pass

   which can be used to create objects which have only attributes
   and no methods. Making it a type should also work:

class implementation:
   name = "cpython"
   version = (3,3,0)

  in which case it would an instance of an existing type, namely,
  "type"]

- under-specified attributes: "run-time environment" doesn't mean much
  to me - my first guess is that it is the set of environment variables,
  i.e. a dictionary identical to os.environ. I assume you mean something
  different ...
  gc_type is supposedly a string, but I cannot guess what possible
  values it may have. I also wonder why it's relevant.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Point of building without threads?

2012-05-09 Thread Antoine Pitrou 
On Wed, 9 May 2012 11:26:29 +0200
Stefan Krah  wrote:
> Antoine Pitrou  wrote:
> > > _decimal is about 12% faster without threads, because the expensive
> > > thread local context can be disabled.
> > 
> > If you cached the last thread id along with the corresponding context,
> > perhaps it could speed things up in most scenarios?
> 
> Nice. This reduces the speed difference to about 4%!

Note that you don't need the actual thread id, the Python thread state
is sufficient: PyThreadState_GET should be a simply variable lookup in
release builds.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-09 Thread Alex Leach 
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote:
| Erm… you have them? What do you think `<` and `>` are?

I was under the impression that those (let's call them) HTML representations 
of < and > don't get interpreted correctly by Javascript engines. I'll have to 
check that though..

| 
| As to writing a loop in javascript without < and >, == and != generally
| work rather well, as does Array.prototype.forEach[0]

Thanks for the tips!
Cheers,
Alex

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] c/ElementTree XML serialisation

2012-05-09 Thread Alex Leach 
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote:
| Erm… you have them? What do you think `<` and `>` are?

I was under the impression that those (let's call them) HTML representations 
of < and > don't get interpreted correctly by Javascript engines. I'll have to 
check that though..

| 
| As to writing a loop in javascript without < and >, == and != generally
| work rather well, as does Array.prototype.forEach[0]

Thanks for the tips!
Cheers,
Alex

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Eric Snow 
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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Brett Cannon 
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://mail.python.org/**pipermail/python-ideas/2012-**
>> April/014954.html
>>
>
> Interesting proposal. I have a number of comments:
>
> - 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 sys.implementation is a dictionary, which
>  means that you would need to write
>  sys.implementation['version']
>
>  I think the PEP should be silent on the type of sys.implementation,
>  in particular, it should not mandate that it be a module (else
>  "from sys.implementation import url" ought to work)
>
>  [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 though probably discouraged
>   for cpython, as it would make people think that they can rely on
>   it being a module.


That stems from people arguing over whether sys.implementation should be a
dict or a tuple, and people going "it shouldn't be a sequence since it
lacks a proper order", but then others saying "it shouldn't be a dict
because it isn't meant to be mutated" (or something since I argued for the
dict). So Eric (I suspect) went with what made sense to him.


> 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 years. Why don't
we have such an empty class sitting somewhere in the stdlib with a
constructor classmethod to simply return new instances (and if you want to
get really fancy, optional keyword arguments to update the instance with
the keys/values passed in)? Is it simply because it's just two lines of
Python that *everyone* has replicated at some point?

-Brett



> Making it a type should also work:
>
>class implementation:
>   name = "cpython"
>   version = (3,3,0)
>
>  in which case it would an instance of an existing type, namely,
>  "type"]
>
> - under-specified attributes: "run-time environment" doesn't mean much
>  to me - my first guess is that it is the set of environment variables,
>  i.e. a dictionary identical to os.environ. I assume you mean something
>  different ...
>  gc_type is supposedly a string, but I cannot guess what possible
>  values it may have. I also wonder why it's relevant.
>
> Regards,
> Martin
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Eric Snow 
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 sys.implementation is a dictionary, which
>  means that you would need to write
>  sys.implementation['version']
>
>  I think the PEP should be silent on the type of sys.implementation,
>  in particular, it should not mandate that it be a module (else
>  "from sys.implementation import url" ought to work)
>
>  [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 though probably discouraged
>   for cpython, as it would make people think that they can rely on
>   it being a module. I wish there was a builtin class
>
>     class record:
>        pass
>
>   which can be used to create objects which have only attributes
>   and no methods. Making it a type should also work:
>
>    class implementation:
>       name = "cpython"
>       version = (3,3,0)
>
>  in which case it would an instance of an existing type, namely,
>  "type"]

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 not being so specific about
the type.  I'll give that some thought.

> - under-specified attributes: "run-time environment" doesn't mean much
>  to me - my first guess is that it is the set of environment variables,
>  i.e. a dictionary identical to os.environ. I assume you mean something
>  different ...
>  gc_type is supposedly a string, but I cannot guess what possible
>  values it may have. I also wonder why it's relevant.

Sorry for the confusion.  These are from the examples section for
sys.implementation.metadata.  I believe the current version of the PEP
is more clear on the distinction.

Thanks again for the feedback.

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Antoine Pitrou 
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 years. Why don't
> we have such an empty class sitting somewhere in the stdlib with a
> constructor classmethod to simply return new instances (and if you want to
> get really fancy, optional keyword arguments to update the instance with
> the keys/values passed in)? Is it simply because it's just two lines of
> Python that *everyone* has replicated at some point?

In this case, it's because sys is a built-in module written in C, and
importing Python code is a no-go.

We have a similar problem with ABCs: io jumps through hoops to register
its implementation classes with the I/O ABCs.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Eric Snow 
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 though probably discouraged
>>   for cpython, as it would make people think that they can rely on
>>   it being a module.
>
>
> That stems from people arguing over whether sys.implementation should be a
> dict or a tuple, and people going "it shouldn't be a sequence since it lacks
> a proper order", but then others saying "it shouldn't be a dict because it
> isn't meant to be mutated" (or something since I argued for the dict). So
> Eric (I suspect) went with what made sense to him.

Yep.

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Eric Snow 
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.
>>
>>
>> I have heard this request now a bazillion times over the years. Why don't
>> we have such an empty class sitting somewhere in the stdlib with a
>> constructor classmethod to simply return new instances (and if you want to
>> get really fancy, optional keyword arguments to update the instance with
>> the keys/values passed in)? Is it simply because it's just two lines of
>> Python that *everyone* has replicated at some point?
>
> In this case, it's because sys is a built-in module written in C, and
> importing Python code is a no-go.

Something I've remotely considered is an approach like namedtuple
takes: define a pure Python template, .format() it, and exec it.
However, this is partly a reflection of my lack of familiarity with
using the C-API. As well, the only place I've seen this done in the
CPython code base is with namedtuple.  Consequently, I was planning on
taking the normal approach.  Should the namedtuple-exec technique be
avoided at the C level?

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Rietveld integration problem?

2012-05-09 Thread Vinay Sajip 
I recently added an issue

http://bugs.python.org/issue14712

to track PEP 405 integration. The code is in my sandbox repo, and I've created a
patch using the "Create Patch" button on the tracker. The diff has been created,
but I don't seem to see a "review" link to Rietveld. The issue is on Rietveld
but for some reason the patch set hasn't attached to it. An earlier version of
the patch (which I've since unlinked) had the same problem - even after several
days, the "review" link never appeared. It's done so automatically in the past,
e.g. for issue

http://bugs.python.org/issue1521950

Is it something I'm doing wrong, or is there a problem with the issue
tracker/Rietveld integration?

Regards,

Vinay Sajip

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Brett Cannon 
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 methods.
> >
> >
> > I have heard this request now a bazillion times over the years. Why don't
> > we have such an empty class sitting somewhere in the stdlib with a
> > constructor classmethod to simply return new instances (and if you want
> to
> > get really fancy, optional keyword arguments to update the instance with
> > the keys/values passed in)? Is it simply because it's just two lines of
> > Python that *everyone* has replicated at some point?
>
> In this case, it's because sys is a built-in module written in C, and
> importing Python code is a no-go.
>

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?

-Brett


>
> We have a similar problem with ABCs: io jumps through hoops to register
> its implementation classes with the I/O ABCs.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Barry Warsaw 
On May 09, 2012, at 05:20 PM, Nick Coghlan wrote:

>Ah, good point. In that case, consider me convinced: static method it
>is. It can join mro() as the second non-underscore method defined on
>type().

+1

If I may dip into the bikeshed paint once more.  I think it would be useful to
establish a naming convention for alternative constructors implemented as
{static,class}methods.  I don't like `build_class()` much.  Would you be
opposed to `type.new()`?

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw 
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 to untangle that, so I think it be better
>>   to represent both values explicitly in sys.implementation.
>
>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
>interest of keeping things as bare-bones as possible to start.

I think it would be fine, if PEP 421 was clear about the semantics of
sys.implementation.version and was silent about trying to disentangle the
semantics of sys.version.  IOW, the PEP can say that the semantics of
sys.version are fuzzy, but not try to clear it up.  Then it would be explicit
(as it already is) that sys.implementation.version describes the version of
the implementation, not the version of the language compliance.

If the latter is useful later, then it can use the PEP 421 described process
to propose a new sys.implementation value that describes a language compliance
variable.

>>  * I mildly prefer sys.implementation.name to be lower cased.  My intuition
>> is   that to be safe, most comparisons of the value will coerce to lower
>> case,   which is easy enough in Python, but perhaps a bit more of a pain in
>> C.  I   don't feel really strongly about this though.  (A counter argument
>> is that   the value might be printed, so a case-sensitive version would be
>> better.)
>
>I'm not sure it makes a lot of difference.  Since cache_tag will be
>provided by the implementation, I don't have any strong use-cases that
>would constrain the name itself.  Still, my preference is for lower
>case as well.  I'll mull this one over.

Cool.  As I said, I'm on the fence about it too. :)

>>  * I've said before that I think the keys in sys.implementation should be
>>   locked down (i.e. not writable).
>
>I've been on and off about this.  It's certainly not too hard to do,
>it makes sense, and I don't see a lot of reason not to do it.  I'll
>give it a go.

Maybe it doesn't matter.  We're all adults here.  I think there are two good
choices.  Either the PEP explicitly describes sys.implementation as immutable,
or it is silent about it.  IOW, I don't think the PEP should explicitly allow
sys.implementation to be mutable.

>> I think sys.implementation.metadata
>>   should be the same type.
>
>This I wonder about.  The more I think about it, the more it fits.
>I'll give it a day and if that still holds I'll work it in.

Cool.

>Thanks for the feedback, Barry!  Feels like the PEP's getting close.

Indeed!

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread martin 

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 list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw 
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 not being so specific about
>the type.  I'll give that some thought.

Right.  See my previous follow up for what I think the PEP should say about
the semantics of the type, without being so specific about the actual type.

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw 
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 exposed in the collections module.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Brett Cannon 
On Wed, May 9, 2012 at 12:21 PM, Barry Warsaw  wrote:

> On May 09, 2012, at 05:20 PM, Nick Coghlan wrote:
>
> >Ah, good point. In that case, consider me convinced: static method it
> >is. It can join mro() as the second non-underscore method defined on
> >type().
>
> +1
>
> If I may dip into the bikeshed paint once more.  I think it would be
> useful to
> establish a naming convention for alternative constructors implemented as
> {static,class}methods.  I don't like `build_class()` much.  Would you be
> opposed to `type.new()`?


Depends on how far you want this new term to go since "new" is somewhat
overloaded thanks to __new__(). I personally like create().
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Nick Coghlan 
Given that the statement form is referred to as a "class definition", and
this is the dynamic equivalent, I'm inclined to go with "type.define()".
Dynamic type definition is more consistent with existing terminology than
dynamic type creation.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread R. David Murray 
On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan  wrote:
> Given that the statement form is referred to as a "class definition", and
> this is the dynamic equivalent, I'm inclined to go with "type.define()".
> Dynamic type definition is more consistent with existing terminology than
> dynamic type creation.

Yeah, but that's the statement form.  I think of the characters in the
.py file as the definition.  If I'm creating a class dynamically...I'm
creating(*) it, not defining it.

I don't think it's a big deal, though.  Either word will work.

--David

(*) Actually, come to think of it, I probably refer to it as
"constructing" the class, rather than creating or defining it.
It's the type equivalent of constructing an instance, perhaps?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Greg Ewing 

Nick Coghlan wrote:

In that case, consider me convinced: static method it
is.


-0.93. Static methods are generally unpythonic, IMO.

Python is not Java -- we have modules. Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
implement it differently. That's not the case with
build_class().

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Eric Snow 
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
>>interest of keeping things as bare-bones as possible to start.
>
> I think it would be fine, if PEP 421 was clear about the semantics of
> sys.implementation.version and was silent about trying to disentangle the
> semantics of sys.version.  IOW, the PEP can say that the semantics of
> sys.version are fuzzy, but not try to clear it up.  Then it would be explicit
> (as it already is) that sys.implementation.version describes the version of
> the implementation, not the version of the language compliance.
>
> If the latter is useful later, then it can use the PEP 421 described process
> to propose a new sys.implementation value that describes a language compliance
> variable.

Whoops.  I meant that I'm okay with having sys.implementation.version
and sys.implementation.lang_version, both as analogs to
sys.version_info.  My inclination is to not include the analog to
sys.version.  However, with the way that you put it, I think you're
right that we could put off the lang_version attribute for later.

>>>  * I've said before that I think the keys in sys.implementation should be
>>>   locked down (i.e. not writable).
>>
>>I've been on and off about this.  It's certainly not too hard to do,
>>it makes sense, and I don't see a lot of reason not to do it.  I'll
>>give it a go.
>
> Maybe it doesn't matter.  We're all adults here.  I think there are two good
> choices.  Either the PEP explicitly describes sys.implementation as immutable,
> or it is silent about it.  IOW, I don't think the PEP should explicitly allow
> sys.implementation to be mutable.

Agreed.

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Larry Hastings 

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.namedtuple.  IWBNI this new type was
also exposed in the collections module.


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 members.



//arry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Nick Coghlan 
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 companion to collections.namedtuple.  IWBNI this new type was
> also exposed in the collections module.

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 structured records. TOOWTDI, and the way we have
already chosen includes iterability as one of its expected properties.

People shouldn't be so quick to throw away ordered iterability - it
makes a lot of things like generic display routines and serialisation
*much* easier, and without incurring the runtime cost of multiple
calls to sorted().

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. The
top-level record now has a consistent length for any given language
version. The fact that the length of the record may still change in
*future* versions of Python can be handled through documentation - we
can simply tell people "it's OK to iterate over the fields, and even
to use tuple unpacking, but if you want to future proof your code,
make sure to include the trailing ', *' to ignore any fields that get
added in the future".

To help focus the discussion, I am going to propose a specific (albeit
still somewhat hypothetical) use case: a cross-implementation testing
system that wants to be able to consistently capture data about the
version of Python that was tested, *without* needing implementation
specific code in the metadata capture step.

That produces the following set of requirements:

1. sys.implementation should be immutable for a given execution of Python
2. repr(sys.implementation) should display all recorded details of the
implementation
3. It should be possible to write a generic, future-proof,
serialisation of sys.implementation that captures all recorded details

collections.namedtuple meets all those requirements (_structseq
doesn't meet the last one at this point, but more on that later)

It also shows that we only need to place very minimal constraints on
sys.implementation.metadata: the type of that structure can be
entirely up to the implementation, with the only requirement being
that repr(sys.implementation.metadata) should produce a string that
accurately captures the stored information. The only
cross-implementation operation that is supported on that field would
be to take its representation.

Now, because this is going to be in the sys module, for CPython, we
would actually need to use _structseq rather than
collections.namedtuple. To do so in a useful way, _structseq should
get two new additions:
- the "_fields" attribute
- the "_asdict" method

As an added bonus, sys.float_info and sys.hash_info would also gain
the new operations.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Nick Coghlan 
On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
 wrote:
> Python is not Java -- we have modules. Something should
> only go in a class namespace if it somehow relates to
> that particular class, and other classes could might
> implement it differently. That's not the case with
> build_class().

Not true - you *will* get a type instance out of any sane call to
type.define(). Technically, you could probably declare your metaclass
such that you get a non-type object instead (just as you can with a
class definition), but that means you're really just using an insanely
convoluted way to make an ordinary function call. If you didn't want
to invoke the full PEP 3115 find metaclass/prepare namespace/execute
body/call metaclass dance, why would you be calling type.define
instead of just calling the metaclass directly?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw 
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 members.

Well, "__init__(self, **kws)", but yeah. :)

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Eric Snow 
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 structured records. TOOWTDI, and the way we have
> already chosen includes iterability as one of its expected properties.
>
> People shouldn't be so quick to throw away ordered iterability - it
> makes a lot of things like generic display routines and serialisation
> *much* easier, and without incurring the runtime cost of multiple
> calls to sorted().
>
> 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. The
> top-level record now has a consistent length for any given language
> version. The fact that the length of the record may still change in
> *future* versions of Python can be handled through documentation - we
> can simply tell people "it's OK to iterate over the fields, and even
> to use tuple unpacking, but if you want to future proof your code,
> make sure to include the trailing ', *' to ignore any fields that get
> added in the future".

Good point.  I'd forgotten about that new tuple unpacking syntax.
FYI, a named tuple was my original choice.  I'm going to sit on this a
few days though.  Who knows, we might be back to using a dict by then.


Key points:

* has dotted access
* is immutable

Both reflect the nature of sys.implementation as currently described
(a fixed set of attributes on an dotted-access namespace).

> To help focus the discussion, I am going to propose a specific (albeit
> still somewhat hypothetical) use case: a cross-implementation testing
> system that wants to be able to consistently capture data about the
> version of Python that was tested, *without* needing implementation
> specific code in the metadata capture step.
>
> That produces the following set of requirements:
>
> 1. sys.implementation should be immutable for a given execution of Python
> 2. repr(sys.implementation) should display all recorded details of the
> implementation
> 3. It should be possible to write a generic, future-proof,
> serialisation of sys.implementation that captures all recorded details
>
> collections.namedtuple meets all those requirements (_structseq
> doesn't meet the last one at this point, but more on that later)
>
> It also shows that we only need to place very minimal constraints on
> sys.implementation.metadata: the type of that structure can be
> entirely up to the implementation, with the only requirement being
> that repr(sys.implementation.metadata) should produce a string that
> accurately captures the stored information. The only
> cross-implementation operation that is supported on that field would
> be to take its representation.

Nice.

> Now, because this is going to be in the sys module, for CPython, we
> would actually need to use _structseq rather than
> collections.namedtuple. To do so in a useful way, _structseq should
> get two new additions:
> - the "_fields" attribute
> - the "_asdict" method

Sounds good to me regardless of the PEP.

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Allow use of sphinx-autodoc in the standard library documentation?

2012-05-09 Thread Nick Coghlan 
One of the requirements for acceptance of PEP 3144 if the provision of
a reStructuredText API reference.

The current plan for dealing with that is to use Spinx apidoc to
create a skeleton, and then capture the rewritten ReST produced by
autodoc.

However, it occurs to me that the module reference could actually
*use* autodoc, with additional prose added to supplement the
docstrings, rather than completely replacing them.

I'd initially dismissed this idea out of hand, but recently realised I
didn't have any especially strong arguments against it (and there are
all the usual "avoid double-keying data" arguments in favour).

So, given the advantages of autodoc, is there a concrete reason why we
can't use it for the documentation of *new* standard library modules?

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Martin v. Löwis 

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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Nick Coghlan 
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, I'll write a PEP.

Yes, please. One of the original arguments that delayed the
introduction of the collections module was the fear that it would lead
to the introduction of tons of subtly different data types, making it
substantially harder to choose the right data type for a given
application. I see this proposal as the realisation of that fear.

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 in a namedtuple".

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com