[Python-Dev] PEP 487: Simpler customization of class creation

[Martin Teichmann]

Hi list,

just recently, I posted about the implementation of PEP 487. The
discussion quickly diverted to PEP 520, which happened to be
strongly related.

Hoping to get some comments about the rest of PEP 487, I took
out the part that is also in PEP 520. I attached the new version of
the PEP. The implementation can be found on the Python issue tracker:
http://bugs.python.org/issue27366

So PEP 487 is about simplifying the customization of class creation.
Currently, this is done via metaclasses, which are very powerful, but
often inflexible, as it is hard to combine two metaclasses. PEP 487
proposes a new metaclass which calls a method on all newly created
subclasses. This way, in order to customize the creation of subclasses,
one just needs to write a simple method.

An absolutely classic example for metaclasses is the need to tell descriptors
who they belong to. There are many large frameworks out there, e.g.
enthought's traits, IPython's traitlets, Django's forms and many more.
Their problem is: they're all fully incompatible. It's really hard to inherit
from two classes which have different metaclasses.

PEP 487 proposes to have one simple metaclass, which can do all those
frameworks need, making them all compatible. As an example, imagine
the framework has a generic descriptor called Integer, which describes,
well, an integer. Typically you use it like that:

class MyClass(FrameworkBaseClass):
my_value = Integer()

how does my_value know how it's called, how it should put its data into the
object's __dict__? Well, this is what the framework's metaclass is for.
With PEP 487, a framework doesn't need to declare an own metaclass
anymore, but simply uses types.Object of PEP 487 as a base class:

class FrameworkBaseClass(types.Object):
def __init_subclass__(cls):
super().__init_subclass__()
for k, v in cls.__dict__.items():
if isinstance(v, FrameworkDescriptorBase):
v.__set_owner__(cls, name)

and all the framework's descriptors know their name. And if another framework
should be used as well: no problem, they just work together easily.

Actually, the above example is just that common, that PEP 487 includes
it directly:
a method __set_owner__ is called for every descriptor. That could make most
descriptors in frameworks work out of the box.

So now I am hoping for comments!

Greetings

Martin

New version of the PEP follows:

PEP: 487
Title: Simpler customisation of class creation
Version: $Revision$
Last-Modified: $Date$
Author: Martin Teichmann ,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Feb-2015
Python-Version: 3.6
Post-History: 27-Feb-2015, 5-Feb-2016, 24-Jun-2016
Replaces: 422


Abstract


Currently, customising class creation requires the use of a custom metaclass.
This custom metaclass then persists for the entire lifecycle of the class,
creating the potential for spurious metaclass conflicts.

This PEP proposes to instead support a wide range of customisation
scenarios through a new ``__init_subclass__`` hook in the class body,
a hook to initialize attributes.

Those hooks should at first be defined in a metaclass in the standard
library, with the option that this metaclass eventually becomes the
default ``type`` metaclass.

The new mechanism should be easier to understand and use than
implementing a custom metaclass, and thus should provide a gentler
introduction to the full power Python's metaclass machinery.


Background
==

Metaclasses are a powerful tool to customize class creation. They have,
however, the problem that there is no automatic way to combine metaclasses.
If one wants to use two metaclasses for a class, a new metaclass combining
those two needs to be created, typically manually.

This need often occurs as a surprise to a user: inheriting from two base
classes coming from two different libraries suddenly raises the necessity
to manually create a combined metaclass, where typically one is not
interested in those details about the libraries at all. This becomes
even worse if one library starts to make use of a metaclass which it
has not done before. While the library itself continues to work perfectly,
suddenly every code combining those classes with classes from another library
fails.

Proposal


While there are many possible ways to use a metaclass, the vast majority
of use cases falls into just three categories: some initialization code
running after class creation, the initalization of descriptors and
keeping the order in which class attributes were defined.

Those three use cases can easily be performed by just one metaclass. If
this metaclass is put into the standard library, and all libraries that
wish to customize class creation use this very metaclass, no combination
of metaclasses is necessary anymore. Said metaclass should live in the
``types`` module under the name ``Type``. This should hint the user that
in the future, this metaclass m

[Python-Dev] Here's what's going into 3.5.2 final and 3.4.5 final

[Larry Hastings]

Heads up!  This is a courtesy reminder from your friendly 3.4 and 3.5 
release manager.  Here's a list of all the changes since 3.5.2rc1 that 
are currently going into 3.5.2 final:


 * 155e665428c6 - Zachary: OpenSSL 1.0.2h build changes for Windows
 * cae0b7ffeb9f - Benjamin: fix % in Doc/whatsnew/3.5.rst that confuses
   latex
 * 783dfd77e4c1 - Terry Reed: allow non-ascii in idlelib/NEWS.txt
 *  - Matthias: fix for test_ssl test_options on Ubuntu


3.4.5 final only has one change from 3.4.5rc1: the test_ssl test_options 
fix from Matthias.



If there's something else that needs to go into one of these releases, 
and it's not on the list above, speak up now.  I may actually tag these 
late Friday as I'm traveling Saturday.  So you have approximately, let's 
say 20 hours from when I post this.



Thanks,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] unittest.TestResult lacks API to separate subtests

[Ilya Kazakevich]

Hello,

 

We're developing Python IDE and integrated it with unittest module using
TestResult

inheritor to track test start, end etc. With Py3K, it supports addSubTest
method, that is called after all subtests. But there is no method called
before and after _each_ subtest (like it is done for regular tests). With
out of it I can't fetch each subtest output and display it correctly.

 

I suggest to add subTestStart / subTestEnd  methods to help me with my issue
and other people with similar issues. I can send patch if you think this is
a good idea. 

 

 

Ilya Kazakevich

 

JetBrains

  http://www.jetbrains.com

The Drive to Develop

 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2016-06-17 - 2016-06-24)
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:
  open5531 (-13)
  closed 33609 (+52)
  total  39140 (+39)

Open issues with patches: 2419 


Issues opened (27)
==

#21106: Updated Mac folder icon
http://bugs.python.org/issue21106  reopened by r.david.murray

#27196: Eliminate 'ThemeChanged' warning when running IDLE tests
http://bugs.python.org/issue27196  reopened by ned.deily

#27346: Implement os.readv() / os.writev()
http://bugs.python.org/issue27346  opened by mmarkk

#27348: Non-main thread exception handler drops exception message
http://bugs.python.org/issue27348  opened by martin.panter

#27350: Compact and ordered dict
http://bugs.python.org/issue27350  opened by naoki

#27351: Unexpected ConfigParser.read() behavior when passed fileobject
http://bugs.python.org/issue27351  opened by Rich.Rauenzahn

#27352: Bug in IMPORT_NAME
http://bugs.python.org/issue27352  opened by serhiy.storchaka

#27353: Add nroot function to math
http://bugs.python.org/issue27353  opened by steven.daprano

#27354: SSLContext.load_verify_locations cannot handle paths on Window
http://bugs.python.org/issue27354  opened by Ilya.Kulakov

#27355: Strip out the last lingering vestiges of Windows CE support
http://bugs.python.org/issue27355  opened by larry

#27357: Enhancing the Windows installer
http://bugs.python.org/issue27357  opened by Sworddragon

#27358: BUILD_MAP_UNPACK_WITH_CALL is slow
http://bugs.python.org/issue27358  opened by Demur Rumed

#27359: OrderedDict pseudo-literals (WIP)
http://bugs.python.org/issue27359  opened by ll

#27363: Complex with negative zero imaginary part
http://bugs.python.org/issue27363  opened by Vedran.Čačić

#27364: Deprecate invalid unicode escape sequences
http://bugs.python.org/issue27364  opened by ebarry

#27365: Allow non-ascii chars in IDLE NEWS.txt (for contributor names)
http://bugs.python.org/issue27365  opened by terry.reedy

#27366: PEP487: Simpler customization of class creation
http://bugs.python.org/issue27366  opened by Martin.Teichmann

#27367: Windows buildbot: random timeout failure on test_threading
http://bugs.python.org/issue27367  opened by haypo

#27369: [PATCH] Tests break with --with-system-expat and Expat 2.2.0
http://bugs.python.org/issue27369  opened by sping

#27372: Test_idle should stop changing locale
http://bugs.python.org/issue27372  opened by terry.reedy

#27373: logging.handlers.SysLogHandler with TCP not working on rsyslog
http://bugs.python.org/issue27373  opened by 吴冉波

#27374: Cygwin: Makefile does not install DLL import library
http://bugs.python.org/issue27374  opened by erik.bray

#27376: Add mock_import method to mock module
http://bugs.python.org/issue27376  opened by Eyal Posener

#27377: Add smarter socket.fromfd()
http://bugs.python.org/issue27377  opened by nascheme

#27379: SocketType changed in Python 3
http://bugs.python.org/issue27379  opened by martin.panter

#27380: IDLE: add base Query dialog with ttk widgets
http://bugs.python.org/issue27380  opened by terry.reedy

#27383: executuable in distutils triggering microsoft anti virus
http://bugs.python.org/issue27383  opened by Rob Bairos



Most recent 15 issues with no replies (15)
==

#27383: executuable in distutils triggering microsoft anti virus
http://bugs.python.org/issue27383

#27380: IDLE: add base Query dialog with ttk widgets
http://bugs.python.org/issue27380

#27379: SocketType changed in Python 3
http://bugs.python.org/issue27379

#27376: Add mock_import method to mock module
http://bugs.python.org/issue27376

#27374: Cygwin: Makefile does not install DLL import library
http://bugs.python.org/issue27374

#27372: Test_idle should stop changing locale
http://bugs.python.org/issue27372

#27367: Windows buildbot: random timeout failure on test_threading
http://bugs.python.org/issue27367

#27366: PEP487: Simpler customization of class creation
http://bugs.python.org/issue27366

#27348: Non-main thread exception handler drops exception message
http://bugs.python.org/issue27348

#27340: bytes-like objects with socket.sendall(), SSL, and http.client
http://bugs.python.org/issue27340

#27332: Clinic: first parameter for module-level functions should be P
http://bugs.python.org/issue27332

#27331: Add a policy argument to email.mime.MIMEBase
http://bugs.python.org/issue27331

#27329: Document behavior when CDLL is called  with None as an argumen
http://bugs.python.org/issue27329

#27326: SIGSEV in test_window_funcs of test_curses
http://bugs.python.org/issue27326

#27323: ncurses putwin() fails in test_module_funcs
http://bugs.python.org/issue27323



Most recent 15 issues waiting for review (15)
=

#27380: IDLE: add base Query dialog with ttk widgets
http://bugs.python.org/issue27380

#27377

Re: [Python-Dev] Idea: more compact, interned string key only dict for namespace.

[INADA Naoki]

Hi, all.

I implemented my new idea. (still wip)
https://github.com/methane/cpython/pull/3/files

Memory usage when building Python doc with sphinx are:

1) master (shared key)
176MB

2) compact (w/ shared key)
158MB

3) compact (w/o shared key)
166MB

4) compact & interned (new)
160MB

Memory usage is close to compact w/ shared key, and more efficient than current.

In case of Python benchmark (master vs compact & interned):

$ python perf.py  -fm ~/local/python-master/bin/python3
~/local/python-intern/bin/python3
### 2to3 ###
Mem max: 20392.000 -> 16936.000: 1.2041x smaller

### chameleon_v2 ###
Mem max: 364604.000 -> 359904.000: 1.0131x smaller

### django_v3 ###
Mem max: 26648.000 -> 24948.000: 1.0681x smaller

### fastpickle ###
Mem max: 8296.000 -> 8996.000: 1.0844x larger

### fastunpickle ###
Mem max: 8332.000 -> 7964.000: 1.0462x smaller

### json_dump_v2 ###
Mem max: 10400.000 -> 9972.000: 1.0429x smaller

### json_load ###
Mem max: 8088.000 -> 7644.000: 1.0581x smaller

### nbody ###
Mem max: 7460.000 -> 7036.000: 1.0603x smaller

### regex_v8 ###
Mem max: 12572.000 -> 12520.000: 1.0042x smaller

### tornado_http ###
Mem max: 27860.000 -> 26792.000: 1.0399x smaller


I'll do more hack in next week to prove my idea.
(interned string only vs string only, revive embedded small table or not).

If someone interested in, please try my interned-dict branch
and report difference of performance and memory usage.

https://github.com/methane/cpython/tree/interned-dict
(cb0a125c79 passes most tests, except tests using sys.getsizeof()).

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest.TestResult lacks API to separate subtests

[Guido van Rossum]

Hi Ilya,

That sounds like a fine idea. Can you submit a patch to our bug tracker?
bugs.python.org. You'll need to fill out a contributor form as well (
https://www.python.org/psf/contrib/contrib-form/)

--Guido

On Fri, Jun 24, 2016 at 8:52 AM, Ilya Kazakevich <
ilya.kazakev...@jetbrains.com> wrote:

> Hello,
>
>
>
> We’re developing Python IDE and integrated it with unittest module using
> TestResult
> 
> inheritor to track test start, end etc. With Py3K, it supports addSubTest 
> method,
> that is called after all subtests. But there is no method called before and
> after _*each*_ subtest (like it is done for regular tests). With out of
> it I can’t fetch each subtest output and display it correctly.
>
>
>
> I suggest to add subTestStart / subTestEnd  methods to help me with my
> issue and other people with similar issues. I can send patch if you think
> this is a good idea.
>
>
>
>
>
> Ilya Kazakevich
>
>
>
> JetBrains
>
> http://www.jetbrains.com
>
> The Drive to Develop
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Nick Coghlan]

On 24 June 2016 at 00:41, Martin Teichmann  wrote:
> Hi list,
>
> just recently, I posted about the implementation of PEP 487. The
> discussion quickly diverted to PEP 520, which happened to be
> strongly related.
>
> Hoping to get some comments about the rest of PEP 487, I took
> out the part that is also in PEP 520.

Good idea :)

=
> Proposal
> 
>
> While there are many possible ways to use a metaclass, the vast majority
> of use cases falls into just three categories: some initialization code
> running after class creation, the initalization of descriptors and
> keeping the order in which class attributes were defined.
>
> Those three use cases can easily be performed by just one metaclass.

This section needs to be tweaked a bit to defer to PEP 520 for
discussion of the 3rd case.

> If
> this metaclass is put into the standard library, and all libraries that
> wish to customize class creation use this very metaclass, no combination
> of metaclasses is necessary anymore. Said metaclass should live in the
> ``types`` module under the name ``Type``. This should hint the user that
> in the future, this metaclass may become the default metaclass ``type``.

As long as the PEP still proposes phased integration into the standard
library and builtins (more on that below) I'd suggest being explicit
here in the proposal section that the non-default metaclasses in the
standard library (abc.ABCMeta and enum.EnumMeta) should be updated to
inherit from the new types.Type.

> The three use cases are achieved as follows:

"The three ..." -> "These ..."

> 1. The metaclass contains an ``__init_subclass__`` hook that initializes
>all subclasses of a given class,
> 2. the metaclass calls a ``__set_owner__`` hook on all the attribute
>(descriptors) defined in the class, and

This part isn't entirely clear to me, so you may want to give some
Python pseudo-code that:

- is explicit regarding exactly when this new code runs in the type
creation process
- whether the __set_owner__ hooks are called before or after
__init_subclass__ runs, or only when the subclass calls up to
super().__init_subclass__, and the implications of each choice (either
descriptors see a partially initialised class object, or init_subclass
sees partially initialised descriptor objects, or that choice is
delegated to individual subclasses)
- how the list of objects to be checked for "__set_owner__" methods is
retrieved (presumably via "ns.items()" on the class definition
namespace, but the PEP should be explicit)

For the second point, my personal preference would be for descriptors
to have their owner set first and independently of __init_subclass__
super calls (as it seems more likely that __init_subclass__ will
depend on having access to fully initialised descriptors than the
other way around).

> Reduced chance of metaclass conflicts
> -
>
> One of the big issues that makes library authors reluctant to use metaclasses
> (even when they would be appropriate) is the risk of metaclass conflicts.
> These occur whenever two unrelated metaclasses are used by the desired
> parents of a class definition. This risk also makes it very difficult to
> *add* a metaclass to a class that has previously been published without one.
>
> By contrast, adding an ``__init_subclass__`` method to an existing type poses
> a similar level of risk to adding an ``__init__`` method: technically, there
> is a risk of breaking poorly implemented subclasses, but when that occurs,
> it is recognised as a bug in the subclass rather than the library author
> breaching backwards compatibility guarantees.

This section needs some additional explanation of how it fares given
the proposed migration plan below. I *think* it would be fine,
assuming that in 3.7, the types module gains the lines:

Type = type
Object = object

As that would collapse the hierarchy again, even for classes that had
declared inheritance from types.Object or the direct use of types.Type
as their metaclass in 3.6

Honestly though, I'm not sure this additional user-visible complexity
is worth it - "The default type metaclass has this new behaviour" is a
lot easier to document and explain than "We added a new opt-in
alternate metaclass that you can use if you want, and in the next
version that will just become an alias for the builtin types again".
We'd also end up being stuck with types.Type and types.Object as
aliases for the type and object builtins forever (with the associated
"How does 'class name:' or 'class name(object)' differ from 'class
name(types.Object)'?" question and "It doesn't, unless you're using
Python 3.6" answer for folks learning the language for the first
time).

If we decide __init_subclass__ and __set_owner__ are good ideas, let's
just implement them, with a backport available on PyPI for folks that
want to use them on earlier versions, including in Python 2/3
compatible code.

> A path of introduction into Pyt

[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Eric Snow]

- a clearer motivation section
- include "dunder" names
- 2 open questions (__slots__?  drop read-only requirement?)

-eric

---

PEP: 520
Title: Preserving Class Attribute Definition Order
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 7-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016, 11-Jun-2016, 20-Jun-2016, 24-Jun-2016


Abstract


The class definition syntax is ordered by its very nature. Class
attributes defined there are thus ordered.  Aside from helping with
readability, that ordering is sometimes significant.  If it were
automatically available outside the class definition then the
attribute order could be used without the need for extra boilerplate
(such as metaclasses or manually enumerating the attribute order).
Given that this information already exists, access to the definition
order of attributes is a reasonable expectation.  However, currently
Python does not preserve the attribute order from the class
definition.

This PEP changes that by preserving the order in which attributes
are introduced in the class definition body.  That order will now be
preserved in the ``__definition_order__`` attribute of the class.
This allows introspection of the original definition order, e.g. by
class decorators.

Additionally, this PEP changes the default class definition namespace
to ``OrderedDict``.  The long-lived class namespace (``__dict__``) will
remain a ``dict``.


Motivation
==

The attribute order from a class definition may be useful to tools
that rely on name order.  However, without the automatic availability
of the definition order, those tools must impose extra requirements on
users.  For example, use of such a tool may require that your class use
a particular metaclass.  Such requirements are often enough to
discourage use of the tool.

Some tools that could make use of this PEP include:

* documentation generators
* testing frameworks
* CLI frameworks
* web frameworks
* config generators
* data serializers
* enum factories (my original motivation)


Background
==

When a class is defined using a ``class`` statement, the class body
is executed within a namespace.  Currently that namespace defaults to
``dict``.  If the metaclass defines ``__prepare__()`` then the result
of calling it is used for the class definition namespace.

After the execution completes, the definition namespace namespace is
copied into new ``dict``.  Then the original definition namespace is
discarded.  The new copy is stored away as the class's namespace and
is exposed as ``__dict__`` through a read-only proxy.

The class attribute definition order is represented by the insertion
order of names in the *definition* namespace.  Thus, we can have
access to the definition order by switching the definition namespace
to an ordered mapping, such as ``collections.OrderedDict``.  This is
feasible using a metaclass and ``__prepare__``, as described above.
In fact, exactly this is by far the most common use case for using
``__prepare__`` (see PEP 487).

At that point, the only missing thing for later access to the
definition order is storing it on the class before the definition
namespace is thrown away.  Again, this may be done using a metaclass.
However, this means that the definition order is preserved only for
classes that use such a metaclass.  There are two practical problems
with that:

First, it requires the use of a metaclass.  Metaclasses introduce an
extra level of complexity to code and in some cases (e.g. conflicts)
are a problem.  So reducing the need for them is worth doing when the
opportunity presents itself.  PEP 422 and PEP 487 discuss this at
length.  Given that we now have a C implementation of ``OrderedDict``
and that ``OrderedDict`` is the common use case for ``__prepare__()``,
we have such an opportunity by defaulting to ``OrderedDict``.

Second, only classes that opt in to using the ``OrderedDict``-based
metaclass will have access to the definition order. This is problematic
for cases where universal access to the definition order is important.


Specification
=

Part 1:

* all classes have a ``__definition_order__`` attribute
* ``__definition_order__`` is a ``tuple`` of identifiers (or ``None``)
* ``__definition_order__`` is a read-only attribute
* ``__definition_order__`` is always set:

  1. during execution of the class body, the insertion order of names
 into the class *definition* namespace is stored in a tuple
  2. if ``__definition_order__`` is defined in the class body then it
 must be a ``tuple`` of identifiers or ``None``; any other value
 will result in ``TypeError``
  3. classes that do not have a class definition (e.g. builtins) have
 their ``__definition_order__`` set to ``None``
  4. classes for which `__prepare__()`` returned something other than
 ``OrderedDict`` (or a subclass) have their ``__definition_order__`

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Eric Snow]

On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan  wrote:
> Honestly though, I'm not sure this additional user-visible complexity
> is worth it - "The default type metaclass has this new behaviour" is a
> lot easier to document and explain than "We added a new opt-in
> alternate metaclass that you can use if you want, and in the next
> version that will just become an alias for the builtin types again".
> We'd also end up being stuck with types.Type and types.Object as
> aliases for the type and object builtins forever (with the associated
> "How does 'class name:' or 'class name(object)' differ from 'class
> name(types.Object)'?" question and "It doesn't, unless you're using
> Python 3.6" answer for folks learning the language for the first
> time).
>
> If we decide __init_subclass__ and __set_owner__ are good ideas, let's
> just implement them, with a backport available on PyPI for folks that
> want to use them on earlier versions, including in Python 2/3
> compatible code.

+1

Could you clarify the value of the staged approach over jumping
straight to changing builtins.type?

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP XXX: Compact ordered dict

[Eric Snow]

There are a number of ways to make it work (mostly).  However, I'll
defer to Raymond on how strictly OrderedDict should "subclass" from
dict.

-eric

On Thu, Jun 23, 2016 at 9:26 AM, INADA Naoki  wrote:
> On Fri, Jun 24, 2016 at 12:03 AM, Eric Snow  
> wrote:
>> On Mon, Jun 20, 2016 at 11:02 PM, INADA Naoki  wrote:
>>> On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman  wrote:
 (if a PEP is needed at all)
>>>
>>> I don't think so. My PEP is not for changing Python Language,
>>> just describe implementation detail.
>>>
>>> Python 3.5 has new OrderedDict implemented in C without PEP.
>>> My patch is relatively small than it.  And the idea has been well known.
>>
>> How about, for 3.6, target re-implementing OrderedDict using the
>> compact dict approach (and leave dict alone for now).  That way we
>> have an extra release cycle to iron out the kinks before switching
>> dict over for 3.7. :)
>>
>> -eric
>
> I can't.  Since OrderedDict inherits dict.  OrderedDict implementation
> based on dict
> implementation.
> Since I'm not expert of Python object system,  I don't know how to
> separate OrderedDict
> implementation from dict.
>
>
> --
> INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Eric Snow]

On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan  wrote:
> This version looks fine to me.

\o/

> The definition order question has been dropped from PEP 487, so this
> cross-reference doesn't really make sense any more :)

Ah, so much for my appeal to authority. 

> I'd characterise this section at the language definition level as the
> default class definition namespace now being *permitted* to be an
> OrderedDict. For implementations where dict is ordered by default,
> there's no requirement to switch specifically to
> collections.OrderedDict.

Yeah, I'd meant to fix that.

> This paragraph is a little confusing, since "set
> ``__definition_order__`` manually" is ambiguous.
>
> "supply an explicit ``__definition_order__`` via the class namespace"
> might be clearer.

ack

> I realised there's another important reason for doing it this way by
> default: it's *really easy* to write a "skip_dunder_names" filter that
> leaves out dunder names from an arbitrary interable of strings. It's
> flatout *impossible* to restore the dunder attribute order if the
> class definition process throws it away.

Yep.  That's why I felt fine with relaxing that.  I guess I didn't
actually put that in the PEP though. :)

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 487: Simpler customization of class creation

[Ivan Levkivskyi]

I think in any case Type is a bad name, since we now have typing.Type (and
it is completely different) I could imagine a lot of confusion.

--
Ivan



On 25 June 2016 at 00:17, Eric Snow  wrote:

> On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan  wrote:
> > Honestly though, I'm not sure this additional user-visible complexity
> > is worth it - "The default type metaclass has this new behaviour" is a
> > lot easier to document and explain than "We added a new opt-in
> > alternate metaclass that you can use if you want, and in the next
> > version that will just become an alias for the builtin types again".
> > We'd also end up being stuck with types.Type and types.Object as
> > aliases for the type and object builtins forever (with the associated
> > "How does 'class name:' or 'class name(object)' differ from 'class
> > name(types.Object)'?" question and "It doesn't, unless you're using
> > Python 3.6" answer for folks learning the language for the first
> > time).
> >
> > If we decide __init_subclass__ and __set_owner__ are good ideas, let's
> > just implement them, with a backport available on PyPI for folks that
> > want to use them on earlier versions, including in Python 2/3
> > compatible code.
>
> +1
>
> Could you clarify the value of the staged approach over jumping
> straight to changing builtins.type?
>
> -eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Random832]

On Fri, Jun 24, 2016, at 17:52, Eric Snow wrote:
> - 2 open questions (__slots__?  drop read-only requirement?)

It's worth noting that __slots__ itself doesn't have a read-only
requirement. It can be a tuple, any iterable of strings, or a single
string (which means the object has a single slot).

Should dir() iterate in the order of __definition_order__? What, if so,
should be done about instance attributes, or attributes of multiple
classes, or class attributes not present in __definition_order__?

What happens to classes whose __prepare__ doesn't return an OrderedDict?

Can __definition_order__ be reassigned at runtime? Will it have the same
constraints?

What if a metaclass defines __getattribute__ in a way that specially
handles __definition_order__? If someone really wants to put a non-tuple
there they will find a way. How hard do we want to think about ways to
stop consenting adults from doing weird things with the
__definition_order__ attribute?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Eric Snow]

On Fri, Jun 24, 2016 at 5:56 PM, Random832  wrote:
> On Fri, Jun 24, 2016, at 17:52, Eric Snow wrote:
>> - 2 open questions (__slots__?  drop read-only requirement?)
>
> It's worth noting that __slots__ itself doesn't have a read-only
> requirement. It can be a tuple, any iterable of strings, or a single
> string (which means the object has a single slot).

That is somewhat orthogonal to this PEP.

>
> Should dir() iterate in the order of __definition_order__? What, if so,
> should be done about instance attributes, or attributes of multiple
> classes, or class attributes not present in __definition_order__?

dir() relates to the object's namespace, not its class's definition namespace.

>
> What happens to classes whose __prepare__ doesn't return an OrderedDict?

The PEP already indicates that __definition_order__ will be set to None.

>
> Can __definition_order__ be reassigned at runtime?

That is the subject of one of the open questions.  Guido has suggested
that it should.  I don't agree, but then I'm not Dutch. :)

> Will it have the same
> constraints?

Given that folks generally shouldn't be setting it at runtime, there
isn't much point to constraining it. :)

>
> What if a metaclass defines __getattribute__ in a way that specially
> handles __definition_order__? If someone really wants to put a non-tuple
> there they will find a way. How hard do we want to think about ways to
> stop consenting adults from doing weird things with the
> __definition_order__ attribute?

The point of "consenting adults" is that the person breaking the rules
is aware that they are doing so and that they are willing to accept
the consequences.  Also, note that the interpreter does not depend on
__definition_order__ in any way.  As I say in the PEP, I'd rather
__definition_order__ remain read-only until there's a need.

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Nick Coghlan]

This version looks fine to me.

On 24 June 2016 at 14:52, Eric Snow  wrote:
> Background
> ==
>
> When a class is defined using a ``class`` statement, the class body
> is executed within a namespace.  Currently that namespace defaults to
> ``dict``.  If the metaclass defines ``__prepare__()`` then the result
> of calling it is used for the class definition namespace.
>
> After the execution completes, the definition namespace namespace is
> copied into new ``dict``.  Then the original definition namespace is
> discarded.  The new copy is stored away as the class's namespace and
> is exposed as ``__dict__`` through a read-only proxy.
>
> The class attribute definition order is represented by the insertion
> order of names in the *definition* namespace.  Thus, we can have
> access to the definition order by switching the definition namespace
> to an ordered mapping, such as ``collections.OrderedDict``.  This is
> feasible using a metaclass and ``__prepare__``, as described above.
> In fact, exactly this is by far the most common use case for using
> ``__prepare__`` (see PEP 487).

The definition order question has been dropped from PEP 487, so this
cross-reference doesn't really make sense any more :)

> Part 2:
>
> * the default class *definition* namespace is now ``OrderdDict``
>
> The following code demonstrates roughly equivalent semantics for the
> default behavior::
>
>class Meta(type):
>@classmethod
>def __prepare__(cls, *args, **kwargs):
>return OrderedDict()
>
>class Spam(metaclass=Meta):
>ham = None
>eggs = 5
>__definition_order__ = tuple(locals())

I'd characterise this section at the language definition level as the
default class definition namespace now being *permitted* to be an
OrderedDict. For implementations where dict is ordered by default,
there's no requirement to switch specifically to
collections.OrderedDict.

> Why a read-only attribute?
> --
>
> As with the use of tuple, making ``__definition_order__`` a read-only
> attribute communicates the fact that the information it represents is
> complete.  Since it represents the state of a particular one-time event
> (execution of the class definition body), allowing the value to be
> replaced would reduce confidence that the attribute corresponds to the
> original class body.
>
> If a use case for a writable (or mutable) ``__definition_order__``
> arises, the restriction may be loosened later.  Presently this seems
> unlikely and furthermore it is usually best to go immutable-by-default.
>
> Note that the ability to set ``__definition_order__`` manually allows
> a dynamically created class (e.g. Cython, ``type()``) to still have
> ``__definition_order__`` properly set.

This paragraph is a little confusing, since "set
``__definition_order__`` manually" is ambiguous.

"supply an explicit ``__definition_order__`` via the class namespace"
might be clearer.

> Why not ignore "dunder" names?
> --
>
> Names starting and ending with "__" are reserved for use by the
> interpreter.  In practice they should not be relevant to the users of
> ``__definition_order__``.  Instead, for nearly everyone they would only
> be clutter, causing the same extra work for everyone.
>
> However, dropping dunder names by default may inadvertantly cause
> problems for classes that use dunder names unconventionally. In this
> case it's better to play it safe and preserve *all* the names from
> the class definition.
>
> Note that a couple of dunder names (``__name__`` and ``__qualname__``)
> are injected by default by the compiler.  So they will be included even
> though they are not strictly part of the class definition body.

I realised there's another important reason for doing it this way by
default: it's *really easy* to write a "skip_dunder_names" filter that
leaves out dunder names from an arbitrary interable of strings. It's
flatout *impossible* to restore the dunder attribute order if the
class definition process throws it away.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com