[Python-checkins] peps (merge default -> default): merge
daniel.holth
python-checkins at python.org
Tue Feb 12 04:50:13 CET 2013
http://hg.python.org/peps/rev/6c0ec082c797
changeset: 4735:6c0ec082c797
parent: 4734:08105ae9d5af
parent: 4732:fe7cd22d1064
user: Daniel Holth <dholth at fastmail.fm>
date: Mon Feb 11 22:50:02 2013 -0500
summary:
merge
files:
pep-0422.txt | 48 ++++++++++++++++++++++++++++++----------
pep-0431.txt | 28 ++++++++++-------------
2 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/pep-0422.txt b/pep-0422.txt
--- a/pep-0422.txt
+++ b/pep-0422.txt
@@ -2,13 +2,14 @@
Title: Simple class initialisation hook
Version: $Revision$
Last-Modified: $Date$
-Author: Nick Coghlan <ncoghlan at gmail.com>
+Author: Nick Coghlan <ncoghlan at gmail.com>,
+ Daniel Urban <urban.dani+py at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 5-Jun-2012
Python-Version: 3.4
-Post-History: 5-Jun-2012
+Post-History: 5-Jun-2012, 10-Feb-2012
Abstract
@@ -19,7 +20,7 @@
by setting the ``__metaclass__`` attribute in the class body. While doing
this implicitly from called code required the use of an implementation detail
(specifically, ``sys._getframes()``), it could also be done explicitly in a
-fully supported fashion (for example, by passing ``locals()`` to an
+fully supported fashion (for example, by passing ``locals()`` to a
function that calculated a suitable ``__metaclass__`` value)
There is currently no corresponding mechanism in Python 3 that allows the
@@ -44,7 +45,7 @@
While in many cases these two meanings end up referring to one and the same
object, there are two situations where that is not the case:
-* If the metaclass hint refers to a subclass of ``type``, then it is
+* If the metaclass hint refers to an instance of ``type``, then it is
considered as a candidate metaclass along with the metaclasses of all of
the parents of the class being defined. If a more appropriate metaclass is
found amongst the candidates, then it will be used instead of the one
@@ -114,7 +115,7 @@
# This is invoked after the class is created, but before any
# explicit decorators are called
# The usual super() mechanisms are used to correctly support
- # multiple inheritance. The decorator style invocation helps
+ # multiple inheritance. The class decorator style signature helps
# ensure that invoking the parent class is as simple as possible.
If present on the created object, this new hook will be called by the class
@@ -125,10 +126,17 @@
If a metaclass wishes to block class initialisation for some reason, it
must arrange for ``cls.__init_class__`` to trigger ``AttributeError``.
+Note, that when ``__init_class__`` is called, the name of the class is not
+bound to the new class object yet. As a consequence, the two argument form
+of ``super()`` cannot be used to call methods (e.g., ``super(Example, cls)``
+wouldn't work in the example above). However, the zero argument form of
+``super()`` works as expected, since the ``__class__`` reference is already
+initialised.
+
This general proposal is not a new idea (it was first suggested for
inclusion in the language definition `more than 10 years ago`_, and a
similar mechanism has long been supported by `Zope's ExtensionClass`_),
-but I believe the situation has changed sufficiently in recent years that
+but the situation has changed sufficiently in recent years that
the idea is worth reconsidering.
@@ -156,7 +164,7 @@
class object) clearly distinct in your mind. Even when you know the rules,
it's still easy to make a mistake if you're not being extremely careful.
An earlier version of this PEP actually included such a mistake: it
-stated "instance of type" for a constraint that is actually "subclass of
+stated "subclass of type" for a constraint that is actually "instance of
type".
Understanding the proposed class initialisation hook only requires
@@ -278,17 +286,24 @@
Using the current version of the PEP, the scheme originally proposed could
be implemented as::
- class DynamicDecorators:
+ class DynamicDecorators(Base):
@classmethod
def __init_class__(cls):
- super(DynamicDecorators, cls).__init_class__()
+ # Process any classes later in the MRO
+ try:
+ mro_chain = super().__init_class__
+ except AttributeError:
+ pass
+ else:
+ mro_chain()
+ # Process any __decorators__ attributes in the MRO
for entry in reversed(cls.mro()):
decorators = entry.__dict__.get("__decorators__", ())
for deco in reversed(decorators):
cls = deco(cls)
-Any subclasses of this type would automatically have the contents of any
-``__decorators__`` attributes processed and invoked.
+Any subclasses of ``DynamicDecorators`` would then automatically have the
+contents of any ``__decorators__`` attributes processed and invoked.
The mechanism in the current PEP is considered superior, as many issues
to do with ordering and the same decorator being invoked multiple times
@@ -325,6 +340,12 @@
``super()``), and could not make use of those features themselves.
+Reference Implementation
+========================
+
+The reference implementation has been posted to the `issue tracker`_.
+
+
References
==========
@@ -337,12 +358,15 @@
.. _Zope's ExtensionClass:
http://docs.zope.org/zope_secrets/extensionclass.html
+.. _issue tracker:
+ http://bugs.python.org/issue17044
+
Copyright
=========
This document has been placed in the public domain.
-
+
..
Local Variables:
mode: indented-text
diff --git a/pep-0431.txt b/pep-0431.txt
--- a/pep-0431.txt
+++ b/pep-0431.txt
@@ -8,7 +8,7 @@
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
-Post-History: 11-Dec-2012, 28-Dec-2012
+Post-History: 11-Dec-2012, 28-Dec-2012, 28-Jan-2013
Abstract
@@ -94,7 +94,7 @@
When changing over from daylight savings time (DST) the clock is turned back
one hour. This means that the times during that hour happens twice, once
-without DST and then once with DST. Similarly, when changing to daylight
+with DST and then once without DST. Similarly, when changing to daylight
savings time, one hour goes missing.
The current time zone API can not differentiate between the two ambiguous
@@ -156,10 +156,10 @@
function, one new exception and four new collections. In addition to this, several
methods on the datetime object gets a new ``is_dst`` parameter.
-New class ``DstTzInfo``
-^^^^^^^^^^^^^^^^^^^^^^^^
+New class ``dsttimezone``
+^^^^^^^^^^^^^^^^^^^^^^^^^
-This class provides a concrete implementation of the ``zoneinfo`` base
+This class provides a concrete implementation of the ``tzinfo`` base
class that implements DST support.
@@ -176,10 +176,10 @@
database which should be used. If not specified, the function will look for
databases in the following order:
-1. Use the database in ``/usr/share/zoneinfo``, if it exists.
+1. Check if the `tzdata-update` module is installed, and then use that
+ database.
-2. Check if the `tzdata-update` module is installed, and then use that
- database.
+2. Use the database in ``/usr/share/zoneinfo``, if it exists.
3. Use the Python-provided database in ``Lib/tzdata``.
@@ -206,7 +206,7 @@
``False`` will specify that the given datetime should be interpreted as not
happening during daylight savings time, i.e. that the time specified is after
-the change from DST.
+the change from DST. This is default to preserve existing behavior.
``True`` will specify that the given datetime should be interpreted as happening
during daylight savings time, i.e. that the time specified is before the change
@@ -224,7 +224,7 @@
This exception is a subclass of KeyError and raised when giving a time
zone specification that can't be found::
- >>> datetime.Timezone('Europe/New_York')
+ >>> datetime.zoneinfo('Europe/New_York')
Traceback (most recent call last):
...
UnknownTimeZoneError: There is no time zone called 'Europe/New_York'
@@ -250,8 +250,8 @@
* ``NonExistentTimeError``
- This exception is raised when giving a datetime specification that is ambiguous
- while setting ``is_dst`` to None::
+ This exception is raised when giving a datetime specification for a time that due to
+ daylight saving does not exist, while setting ``is_dst`` to None::
>>> datetime(2012, 3, 25, 2, 0, tzinfo=zoneinfo('Europe/Stockholm'), is_dst=None)
>>>
@@ -266,13 +266,9 @@
* ``all_timezones`` is the exhaustive list of the time zone names that can
be used, listed alphabethically.
-* ``all_timezones_set`` is a set of the time zones in ``all_timezones``.
-
* ``common_timezones`` is a list of useful, current time zones, listed
alphabethically.
-* ``common_timezones_set`` is a set of the time zones in ``common_timezones``.
-
The ``tzdata-update``-package
-----------------------------
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list