Re: [Python-Dev] C99
Hi, 2016-06-04 19:47 GMT+02:00 Guido van Rossum : > Funny. Just two weeks ago I was helping someone who discovered a > compiler that doesn't support the new relaxed variable declaration > rules. I think it was on Windows. Maybe this move is a little too > aggressively deprecating older Windows compilers? I understood that Python only has a tiny list of officially supported compilers. For example, MinGW is somehow explicitly not supported and I see this as a deliberate choice. I'm quite sure that all supported compilers support C99. Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
I'll ask my colleague what his compiler setup was. On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner wrote: > Hi, > > 2016-06-04 19:47 GMT+02:00 Guido van Rossum : > > Funny. Just two weeks ago I was helping someone who discovered a > > compiler that doesn't support the new relaxed variable declaration > > rules. I think it was on Windows. Maybe this move is a little too > > aggressively deprecating older Windows compilers? > > I understood that Python only has a tiny list of officially supported > compilers. For example, MinGW is somehow explicitly not supported and > I see this as a deliberate choice. > > I'm quite sure that all supported compilers support C99. > > Is it worth to support a compiler that in 2016 doesn't support the C > standard released in 1999, 17 years ago? > > Victor > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
So here's the diffs that seem to indicate we were working with a compiler that wasn't full C99 (or maybe previously we were working with a compiler that had extensions?) https://github.com/dropbox/typed_ast/commit/f7497e25abc3bcceced3ca6c3be3786d8805df41 On Tue, Jun 7, 2016 at 8:18 AM, Guido van Rossum wrote: > I'll ask my colleague what his compiler setup was. > > On Tue, Jun 7, 2016 at 3:24 AM, Victor Stinner > wrote: > >> Hi, >> >> 2016-06-04 19:47 GMT+02:00 Guido van Rossum : >> > Funny. Just two weeks ago I was helping someone who discovered a >> > compiler that doesn't support the new relaxed variable declaration >> > rules. I think it was on Windows. Maybe this move is a little too >> > aggressively deprecating older Windows compilers? >> >> I understood that Python only has a tiny list of officially supported >> compilers. For example, MinGW is somehow explicitly not supported and >> I see this as a deliberate choice. >> >> I'm quite sure that all supported compilers support C99. >> >> Is it worth to support a compiler that in 2016 doesn't support the C >> standard released in 1999, 17 years ago? >> >> Victor >> > > > > -- > --Guido van Rossum (python.org/~guido) > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proper way to specify that a method is not defined for a type
For binary methods, such as __add__, either do not implement or return NotImplemented if the other operand/class is not supported. For non-binary methods, simply do not define. Except for subclasses when the super-class defines __hash__ and the subclass is not hashable -- then set __hash__ to None. Question: Are there any other methods that should be set to None to tell the run-time that the method is not supported? Or is this a general mechanism for subclasses to declare any method is unsupported? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP: Ordered Class Definition Namespace
Hi all,
Following discussion a few years back (and rough approval from Guido
[1]), I started work on using OrderedDict for the class definition
namespace by default. The bulk of the effort lay in implementing
OrderedDict in C, which I got landed just in time for 3.5. The
remaining work was quite minimal and the actual change is quite small.
My intention was to land the patch soon, having gone through code
review during PyCon. However, Nick pointed out to me the benefit of
having a concrete point of reference for the change, as well as making
sure it isn't a problem for other implementations. So in that spirit,
here's a PEP for the change. Feedback is welcome, particularly from
from other implementors.
-eric
[1] https://mail.python.org/pipermail/python-ideas/2013-February/019704.html
==
PEP: XXX
Title: Ordered Class Definition Namespace
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 4-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016
Abstract
This PEP changes the default class definition namespace to ``OrderedDict``.
Furthermore, the order in which the attributes are defined in each class
body will now be preserved in ``type.__definition_order__``. This allows
introspection of the original definition order, e.g. by class decorators.
Note: just to be clear, this PEP is *not* about changing ``type.__dict__``
to ``OrderedDict``.
Motivation
==
Currently the namespace used during execution of a class body defaults
to dict. If the metaclass defines ``__prepare__()`` then the result of
calling it is used. Thus, before this PEP, if you needed your class
definition namespace to be ``OrderedDict`` you had to use 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. 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``.
The usefulness of ``OrderedDict``-by-default is greatly increased if the
definition order is directly introspectable on classes afterward,
particularly by code that is independent of the original class definition.
One of the original motivating use cases for this PEP is generic class
decorators that make use of the definition order.
Changing the default class definition namespace has been discussed a
number of times, including on the mailing lists and in PEP 422 and
PEP 487 (see the References section below).
Specification
=
* the default class *definition* namespace is now ``OrderdDict``
* the order in which class attributes are defined is preserved in the
new ``__definition_order__`` attribute on each class
* "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
* ``__definition_order__`` is a tuple
* ``__definition_order__`` is a read-only attribute
* ``__definition_order__`` is always set:
* if ``__definition_order__`` is defined in the class body then it
is used
* types that do not have a class definition (e.g. builtins) have
their ``__definition_order__`` set to ``None``
* types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass) have their ``__definition_order__``
set to ``None``
The following code demonstrates roughly equivalent semantics::
class Meta(type):
def __prepare__(cls, *args, **kwargs):
return OrderedDict()
class Spam(metaclass=Meta):
ham = None
eggs = 5
__definition_order__ = tuple(k for k in locals()
if (!k.startswith('__') or
!k.endswith('__')))
Note that [pep487_] proposes a similar solution, albeit as part of a
broader proposal.
Compatibility
=
This PEP does not break backward compatibility, except in the case that
someone relies *strictly* on dicts as the class definition namespace. This
shouldn't be a problem.
Changes
=
In addition to the class syntax, the following expose the new behavior:
* builtins.__build_class__
* types.prepare_class
* types.new_class
Other Python Implementations
Pending feedback, the impact on Python implementations is expected to
be minimal. If a Python implementation cannot support switching to
`OrderedDict``-by-default then it can always set ``__definition_order__``
to ``None``.
Implementation
==
The implementation is found in the tracker. [impl_]
Alternatives
type.__dict__ as OrderedDict
Instead of storing the definition order in ``__definition_order__``,
the now-ordered definition namespace could be copied into a new
``OrderedDict``. This would mostly pr
Re: [Python-Dev] Proper way to specify that a method is not defined for a type
> From: Ethan Furman
> Sent: Tuesday, June 07, 2016 1:38 PM
> To: Python Dev
> Subject: [Python-Dev] Proper way to specify that a method is not defined
for
> a type
(Just so everyone follows, this is a followup of
http://bugs.python.org/issue27242 )
> For binary methods, such as __add__, either do not implement or return
> NotImplemented if the other operand/class is not supported.
>
> For non-binary methods, simply do not define.
>
> Except for subclasses when the super-class defines __hash__ and the
> subclass is not hashable -- then set __hash__ to None.
Should I mention the __hash__ special case in the
NotImplemented/NotImplementedError docs? If people are looking for a way to
declare this specific operation undefined, they'd find it there as well as
the hash() documentation.
> Question:
>
> Are there any other methods that should be set to None to tell the
> run-time that the method is not supported? Or is this a general
> mechanism for subclasses to declare any method is unsupported?
There was a discussion on one of Python-ideas or Python-dev some time ago
about exactly that, but I don't think any consensus was reached. However, I
think it would make sense for e.g. __iter__ and __reversed__ to tell the
interpreter to *not* fall back to the default sequence protocol (well, in
practice that already works, but it gives an unhelpful error message). I'm
not sure how useful it would be for arbitrary methods, though. __bytes__
(which originally sparked the issue) may or may not be a good candidate, I'm
not sure.
While I like the `__magic_method__ = None` approach, I think the main reason
__hash__ supports that is because there are legitimate use cases of
disallowing hashing (i.e. mutable objects which may or may not change hash
during their lifetime), but I don't think the same rationale applies to
everything ("accidentally" iterating over a not-meant-to-be-iterable object
will result in nonsensical data, but it won't bite the user later, unlike
changing hashes which definitely will).
> --
> ~Ethan~
Special-cases-aren't-special-enough-but-they're-still-there'ly yrs,
-Emanuel
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proper way to specify that a method is not defined for a type
Setting it to None in the subclass is the intended pattern. But CPython must explicitly handle that somewhere so I don't know how general it is supported. Try defining a list subclass with __len__ set to None and see what happens. Then try the same with MutableSequence. On Tue, Jun 7, 2016 at 10:37 AM, Ethan Furman wrote: > For binary methods, such as __add__, either do not implement or return > NotImplemented if the other operand/class is not supported. > > For non-binary methods, simply do not define. > > Except for subclasses when the super-class defines __hash__ and the > subclass is not hashable -- then set __hash__ to None. > > Question: > > Are there any other methods that should be set to None to tell the > run-time that the method is not supported? Or is this a general mechanism > for subclasses to declare any method is unsupported? > > -- > ~Ethan~ > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] 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: Ordered Class Definition Namespace
On 06/07/2016 10:51 AM, Eric Snow wrote: My intention was to land the patch soon, having gone through code review during PyCon. However, Nick pointed out to me the benefit of having a concrete point of reference for the change, as well as making sure it isn't a problem for other implementations. So in that spirit, here's a PEP for the change. Feedback is welcome, particularly from from other implementors. +1 Specification = * types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` I assume this check happens in type.__new__? If a non-OrderedDict is used as the namespace, but a __definition_order__ key and value are supplied, is it used or still set to None? -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: > On 06/07/2016 10:51 AM, Eric Snow wrote: >> Specification >> = > > >>* types for which `__prepare__()`` returned something other than >> ``OrderedDict`` (or a subclass) have their ``__definition_order__`` >> set to ``None`` > > > I assume this check happens in type.__new__? If a non-OrderedDict is used > as the namespace, but a __definition_order__ key and value are supplied, is > it used or still set to None? A __definition_order__ in the class body always takes precedence. So a supplied value will be honored (and not replaced with None). -eric ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 6/7/2016 1:51 PM, Eric Snow wrote: Note: just to be clear, this PEP is *not* about changing > ``type.__dict__`` to ``OrderedDict``. By 'type', do you mean the one and one objected named 'type or the class being defined? To be really clear, will the following change? >>> class C: pass >>> type(C.__dict__) If the proposal only affects (slows) the class definition process, and then only minimally, and has no effect on class use, then +1 on being able to avoid metaclass and prepare for its most common current usage. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 1:52 PM
> To: Python-Dev
> Subject: [Python-Dev] PEP: Ordered Class Definition Namespace
>
>
> Currently the namespace used during execution of a class body defaults
> to dict. If the metaclass defines ``__prepare__()`` then the result of
> calling it is used. Thus, before this PEP, if you needed your class
> definition namespace to be ``OrderedDict`` you had to use a metaclass.
Formatting nit: ``dict``
> Specification
> =
>
> * the default class *definition* namespace is now ``OrderdDict``
> * the order in which class attributes are defined is preserved in the
> new ``__definition_order__`` attribute on each class
> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
What does this imply? If I define some __dunder__ methods, will they simply
not be present in __definition_order__? What if I want to keep the order of
those? While keeping the order of these might be meaningless in most cases,
I don't think there's really a huge problem in doing so. Maybe I'm
overthinking it.
> * ``__definition_order__`` is a tuple
> * ``__definition_order__`` is a read-only attribute
> * ``__definition_order__`` is always set:
>
> * if ``__definition_order__`` is defined in the class body then it
> is used
> * types that do not have a class definition (e.g. builtins) have
> their ``__definition_order__`` set to ``None``
> * types for which `__prepare__()`` returned something other than
> ``OrderedDict`` (or a subclass) have their ``__definition_order__``
> set to ``None``
I would probably like a ``type.definition_order`` method, for which the
return value is bound to __definition_order__ when the class is created
(much like the link between ``type.mro`` and ``cls.__mro__``. Additionally
I'm not sure if setting the attribute to None is a good idea; I'd have it as
an empty tuple. Then again I tend to overthink a lot.
> The following code demonstrates roughly equivalent semantics::
>
>class Meta(type):
>def __prepare__(cls, *args, **kwargs):
>return OrderedDict()
>
>class Spam(metaclass=Meta):
>ham = None
>eggs = 5
>__definition_order__ = tuple(k for k in locals()
> if (!k.startswith('__') or
> !k.endswith('__')))
Mixing up C and Python syntax here.
> However, using ``OrderedDict`` for ``type,__dict__`` would obscure the
> relationship with the definition namespace, making it less useful.
> Additionally, doing this would require significant changes to the
> semantics of the concrete dict C-API.
Formatting nit: ``dict``
I'm +1 on the whole idea (one of my common uses of metaclasses was to keep
the definition order *somewhere*). Thank you for doing that!
-Emanuel
___
Python-Dev mailing list
[email protected]
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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > On 6/7/2016 1:51 PM, Eric Snow wrote: > >> Note: just to be clear, this PEP is *not* about changing > >> ``type.__dict__`` to ``OrderedDict``. > > By 'type', do you mean the one and one objected named 'type or the class > being defined? To be really clear, will the following change? > class C: pass > type(C.__dict__) > I mean the latter, "type" -> the class being defined. > > If the proposal only affects (slows) the class definition process, and then > only minimally, and has no effect on class use, then +1 on being able to > avoid metaclass and prepare for its most common current usage. That is all correct. -eric ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 06/07/2016 11:13 AM, Eric Snow wrote: On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: On 06/07/2016 10:51 AM, Eric Snow wrote: Specification = * types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` I assume this check happens in type.__new__? If a non-OrderedDict is used as the namespace, but a __definition_order__ key and value are supplied, is it used or still set to None? A __definition_order__ in the class body always takes precedence. So a supplied value will be honored (and not replaced with None). Will the supplied __definition_order__ be made a tuple, and still be read-only? -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proper way to specify that a method is not defined for a type
For those interested in this topic, if you are not already aware of it, see also http://bugs.python.org/issue25958, which among other things has a relevant proposed patch for datamode.rst. On Tue, 07 Jun 2016 10:56:37 -0700, Guido van Rossum wrote: > Setting it to None in the subclass is the intended pattern. But CPython > must explicitly handle that somewhere so I don't know how general it is > supported. Try defining a list subclass with __len__ set to None and see > what happens. Then try the same with MutableSequence. > > On Tue, Jun 7, 2016 at 10:37 AM, Ethan Furman wrote: > > > For binary methods, such as __add__, either do not implement or return > > NotImplemented if the other operand/class is not supported. > > > > For non-binary methods, simply do not define. > > > > Except for subclasses when the super-class defines __hash__ and the > > subclass is not hashable -- then set __hash__ to None. > > > > Question: > > > > Are there any other methods that should be set to None to tell the > > run-time that the method is not supported? Or is this a general mechanism > > for subclasses to declare any method is unsupported? ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 11:36 AM, Émanuel Barry wrote:
>> From: Eric Snow
>> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
>
> What does this imply? If I define some __dunder__ methods, will they simply
> not be present in __definition_order__? What if I want to keep the order of
> those? While keeping the order of these might be meaningless in most cases,
> I don't think there's really a huge problem in doing so. Maybe I'm
> overthinking it.
"dunder" names (not just methods) will not be present in
__definition_order__. I'll add an explanation to the PEP. The gist
of it is that they are reserved for use by the interpreter and will
always clutter up __definition_order__. Since needing dunder names
included in __definition_order__ would be rather exceptional, and
there are other options available, leaving them out by default is a
matter of practicality.
>
>> * ``__definition_order__`` is a tuple
>> * ``__definition_order__`` is a read-only attribute
>> * ``__definition_order__`` is always set:
>>
>> * if ``__definition_order__`` is defined in the class body then it
>> is used
>> * types that do not have a class definition (e.g. builtins) have
>> their ``__definition_order__`` set to ``None``
>> * types for which `__prepare__()`` returned something other than
>> ``OrderedDict`` (or a subclass) have their ``__definition_order__``
>> set to ``None``
>
> I would probably like a ``type.definition_order`` method, for which the
> return value is bound to __definition_order__ when the class is created
> (much like the link between ``type.mro`` and ``cls.__mro__``.
What is the value of type.definition_order()? If you need a mutable
copy then pass __definition_order__ to list().
> Additionally
> I'm not sure if setting the attribute to None is a good idea; I'd have it as
> an empty tuple. Then again I tend to overthink a lot.
None indicates that there is no order. An empty tuple indicates that
there were no attributes.
>>__definition_order__ = tuple(k for k in locals()
>> if (!k.startswith('__') or
>> !k.endswith('__')))
>
> Mixing up C and Python syntax here.
nice catch :)
> I'm +1 on the whole idea (one of my common uses of metaclasses was to keep
> the definition order *somewhere*). Thank you for doing that!
:)
-eric
___
Python-Dev mailing list
[email protected]
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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 11:45 AM, Ethan Furman wrote: > On 06/07/2016 11:13 AM, Eric Snow wrote: >> A __definition_order__ in the class body always takes precedence. So >> a supplied value will be honored (and not replaced with None). > > Will the supplied __definition_order__ be made a tuple, and still be > read-only? I had planned on leaving a supplied one alone. So no change to tuple. It remain a read-only attribute though, since that is handled via a descriptor (a la type.__dict__). -eric ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
> From: Eric Snow > Sent: Tuesday, June 07, 2016 2:52 PM > To: Émanuel Barry > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP: Ordered Class Definition Namespace > > "dunder" names (not just methods) will not be present in > __definition_order__. I'll add an explanation to the PEP. The gist > of it is that they are reserved for use by the interpreter and will > always clutter up __definition_order__. Since needing dunder names > included in __definition_order__ would be rather exceptional, and > there are other options available, leaving them out by default is a > matter of practicality. Good point. I'll assume that if we need that we'll do something in the metaclass. > What is the value of type.definition_order()? If you need a mutable > copy then pass __definition_order__ to list(). I think I explained it backwards. I meant to have a method on ``type`` (which metaclasses can override at will) which will set what is passed to the resulting __definition_order__ attribute. But it might not be needed, as we can probably sneak that inside the namespace in the metaclass' __new__. > > Additionally > > I'm not sure if setting the attribute to None is a good idea; I'd have it as > > an empty tuple. Then again I tend to overthink a lot. > > None indicates that there is no order. An empty tuple indicates that > there were no attributes. Fair enough. > > -eric -Emanuel ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 7 June 2016 at 10:51, Eric Snow wrote: > Specification > = > > * the default class *definition* namespace is now ``OrderdDict`` > * the order in which class attributes are defined is preserved in the > new ``__definition_order__`` attribute on each class > * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored > * ``__definition_order__`` is a tuple > * ``__definition_order__`` is a read-only attribute Thinking about the class decorator use case, I think this may need to be reconsidered, as class decorators may: 1. Remove class attributes 2. Add class attributes This will then lead to __definition_order__ getting out of sync with the current state of the class namespace. One option for dealing with that would be to make type.__setattr__ and type.__delattr__ aware of __definition_order__, and have them replace the tuple with a new one as needed. If we did that, then the main question would be whether updating an existing attribute changed the definition order, and I'd be inclined to say "No" (to minimise the side effects of monkey-patching). The main alternative would be to make __definition_order__ writable, so the default behaviour would be for it to reflect the original class body, but decorators would be free to update it to reflect their changes, as well as to make other modifications (e.g. stripping out all callables from the list). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
Victor Stinner wrote: > Is it worth to support a compiler that in 2016 doesn't support the C > standard released in 1999, 17 years ago? MSVC only supports C99 when its needed for C++11 or some MS extension to C. Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC are the viable options we have on Windows (and perhaps Embarcadero, but I haven't used C++ builder for a very long time). Even MinGW does not fully support C99, because it depends on Microsoft's CRT. If we think MSVC and MinGW are worth supporting, we cannot just use C99 indiscriminantly. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
Doesn't Cygwin build against the posix abstraction layer? Wouldn't a python built as such operate as though it was on a unix of some sort? It has been quite a while since I messed with Cygwin - if it hasn't changed, it's not really an option, especially when we have native windows builds now. It would be too much of a downgrade in experience and performance. > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > [email protected]] On Behalf Of Sturla Molden > Sent: Tuesday, June 7, 2016 3:37 PM > To: [email protected] > Subject: Re: [Python-Dev] C99 > > Victor Stinner wrote: > > > Is it worth to support a compiler that in 2016 doesn't support the C > > standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for C++11 or some MS extension > to C. > > Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC > are the viable options we have on Windows (and perhaps Embarcadero, but I > haven't used C++ builder for a very long time). Even MinGW does not fully > support C99, because it depends on Microsoft's CRT. If we think MSVC and > MinGW are worth supporting, we cannot just use C99 indiscriminantly. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- > list%40sdamon.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
Minor changes: updated version numbers, add punctuation. The current text seems to take into account Guido's last comments. Thoughts before asking for acceptance? PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-03-30 Python-Version: 3.5 Post-History: 2014-03-30 2014-08-15 2014-08-16 Abstract During the initial development of the Python 3 language specification, the core ``bytes`` type for arbitrary binary data started as the mutable type that is now referred to as ``bytearray``. Other aspects of operating in the binary domain in Python have also evolved over the course of the Python 3 series. This PEP proposes four small adjustments to the APIs of the ``bytes``, ``bytearray`` and ``memoryview`` types to make it easier to operate entirely in the binary domain: * Deprecate passing single integer values to ``bytes`` and ``bytearray`` * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors * Add ``bytes.byte`` and ``bytearray.byte`` alternative constructors * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and ``memoryview.iterbytes`` alternative iterators Proposals = Deprecation of current "zero-initialised sequence" behaviour Currently, the ``bytes`` and ``bytearray`` constructors accept an integer argument and interpret it as meaning to create a zero-initialised sequence of the given size:: >>> bytes(3) b'\x00\x00\x00' >>> bytearray(3) bytearray(b'\x00\x00\x00') This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entirely in Python 3.7. No other changes are proposed to the existing constructors. Addition of explicit "zero-initialised sequence" constructors - To replace the deprecated behaviour, this PEP proposes the addition of an explicit ``zeros`` alternative constructor as a class method on both ``bytes`` and ``bytearray``:: >>> bytes.zeros(3) b'\x00\x00\x00' >>> bytearray.zeros(3) bytearray(b'\x00\x00\x00') It will behave just as the current constructors behave when passed a single integer. The specific choice of ``zeros`` as the alternative constructor name is taken from the corresponding initialisation function in NumPy (although, as these are 1-dimensional sequence types rather than N-dimensional matrices, the constructors take a length as input rather than a shape tuple). Addition of explicit "single byte" constructors --- As binary counterparts to the text ``chr`` function, this PEP proposes the addition of an explicit ``byte`` alternative constructor as a class method on both ``bytes`` and ``bytearray``:: >>> bytes.byte(3) b'\x03' >>> bytearray.byte(3) bytearray(b'\x03') These methods will only accept integers in the range 0 to 255 (inclusive):: >>> bytes.byte(512) Traceback (most recent call last): File "", line 1, in ValueError: bytes must be in range(0, 256) >>> bytes.byte(1.0) Traceback (most recent call last): File "", line 1, in TypeError: 'float' object cannot be interpreted as an integer The documentation of the ``ord`` builtin will be updated to explicitly note that ``bytes.byte`` is the inverse operation for binary data, while ``chr`` is the inverse operation for text data. Behaviourally, ``bytes.byte(x)`` will be equivalent to the current ``bytes([x])`` (and similarly for ``bytearray``). The new spelling is expected to be easier to discover and easier to read (especially when used in conjunction with indexing operations on binary sequence types). As a separate method, the new spelling will also work better with higher order functions like ``map``. Addition of optimised iterator methods that produce ``bytes`` objects - This PEP proposes that ``bytes``, ``bytearray`` and ``memoryview`` gain an optimised ``iterbytes`` method that produces length 1 ``bytes`` objects rather than integers:: for x in data.iterbytes(): # x is a length 1 ``bytes`` object, rather than an integer The method can be used with arbitrary buffer exporting objects by wrapping them in a ``memoryview`` instance first:: for x in memoryview(data).iterbytes(): # x is a length 1 ``bytes`` object, rather than an integer For ``memoryview``, the semantics of ``iterbytes()`` are defined such that:: memview.tobytes() == b''.join(memview.iterbytes()) This allows the raw bytes of the memory view to be iterated over without needing to make a copy, regardless of the defined shape and format. The main advantage this method offers over the ``map(bytes.byte, data)`` approach is that it is guaranteed *not*
Re: [Python-Dev] C99
We should definitely keep supporting MSVC. --Guido (mobile) On Jun 7, 2016 12:39 PM, "Sturla Molden" wrote: > Victor Stinner wrote: > > > Is it worth to support a compiler that in 2016 doesn't support the C > > standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for C++11 or some MS extension to C. > > Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC > are the viable options we have on Windows (and perhaps Embarcadero, but I > haven't used C++ builder for a very long time). Even MinGW does not fully > support C99, because it depends on Microsoft's CRT. If we think MSVC and > MinGW are worth supporting, we cannot just use C99 indiscriminantly. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
On Tue, Jun 7, 2016 at 12:37 PM, Sturla Molden wrote: > Victor Stinner wrote: > >> Is it worth to support a compiler that in 2016 doesn't support the C >> standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for C++11 or some MS extension to C. > > Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC > are the viable options we have on Windows (and perhaps Embarcadero, but I > haven't used C++ builder for a very long time). Even MinGW does not fully > support C99, because it depends on Microsoft's CRT. If we think MSVC and > MinGW are worth supporting, we cannot just use C99 indiscriminantly. No-one's proposing to use C99 indiscriminately; AFAICT the proposal was: it would make a big difference if the CPython core could start using some of C99's basic features like long long, inline functions, and mid-block declarations, and all interesting compilers support these, so let's officially switch from C89-only to C89-plus-the-bits-of-C99-that-MSVC-supports. This would be a big improvement and is just a matter of recognizing the status quo; no need to drag in anything controversial. There's no chance that CPython is going to drop MSVC support in 3.6. Intel C is hardly a viable option given that the license requires the people running the compiler to accept unbounded liability for Intel lawyer bills and imposes non-DFSG-free conditions on the compiled output. And Cygwin GCC isn't even real Windows. Maybe switching to Clang will make sense in 3.7 but that's a long ways off... -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C99
Nathaniel Smith wrote: > No-one's proposing to use C99 indiscriminately; > There's no chance that CPython is going to drop MSVC support in 3.6. Stinner was proposing that by saying "Is it worth to support a compiler that in 2016 doesn't support the C standard released in 1999, 17 years ago?" This is basically a suggestion to drop MSVC support, as I read it. That is never going to happen. Sturla ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: > On 7 June 2016 at 10:51, Eric Snow wrote: >> * ``__definition_order__`` is a tuple >> * ``__definition_order__`` is a read-only attribute > > Thinking about the class decorator use case, I think this may need to > be reconsidered, as class decorators may: > > 1. Remove class attributes > 2. Add class attributes > > This will then lead to __definition_order__ getting out of sync with > the current state of the class namespace. I'm not clear on your point. Decorators are applied after the class has been created. Hence they have no impact on the class's definition order. I'd expect __definition_order__ to strictly represent what happened in the class body during definition, and not anything afterward. Certainly __definition_order__ might not align with __dict__ (or dir()); we don't have any way to guarantee that it would, do we? If anything, the ability to diff __definition_order__ and __dict__ is a positive, since it allows you to see changes on the class since it was defined. > > One option for dealing with that would be to make type.__setattr__ and > type.__delattr__ aware of __definition_order__, and have them replace > the tuple with a new one as needed. If we did that, then the main > question would be whether updating an existing attribute changed the > definition order, and I'd be inclined to say "No" (to minimise the > side effects of monkey-patching). > > The main alternative would be to make __definition_order__ writable, > so the default behaviour would be for it to reflect the original class > body, but decorators would be free to update it to reflect their > changes, as well as to make other modifications (e.g. stripping out > all callables from the list). I think both of those make __definition_order__ more complicated and less useful. As the PEP stands, folks can be confident in what __definition_order__ represents. What would you consider to be the benefit of a mutable (or replaceable) __definition_order__ that outweighs the benefit of a simpler definition of what's in it. BTW, thanks for bringing this up. :) -eric ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > ``memoryview.iterbytes`` alternative iterators +1 but I want to go just a little farther. We can't change bytes.__getitem__ but we can add another method that returns single byte objects? I think it's still a bit of a pain to extract single bytes even with .iterbytes(). Maybe .iterbytes can take a single index argument (blech) or add a method like .byte_at(i). I'll let you bikeshed on the name. Cheers, -Barry ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Tue, Jun 7, 2016 at 11:28 PM, Ethan Furman wrote: > > Minor changes: updated version numbers, add punctuation. > > The current text seems to take into account Guido's last comments. > > Thoughts before asking for acceptance? > > PEP: 467 > Title: Minor API improvements for binary sequences > Version: $Revision$ > Last-Modified: $Date$ > Author: Nick Coghlan > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 2014-03-30 > Python-Version: 3.5 > Post-History: 2014-03-30 2014-08-15 2014-08-16 > > > Abstract > > > During the initial development of the Python 3 language specification, the > core ``bytes`` type for arbitrary binary data started as the mutable type > that is now referred to as ``bytearray``. Other aspects of operating in the > binary domain in Python have also evolved over the course of the Python 3 > series. > > This PEP proposes four small adjustments to the APIs of the ``bytes``, > ``bytearray`` and ``memoryview`` types to make it easier to operate entirely > in the binary domain: > > * Deprecate passing single integer values to ``bytes`` and ``bytearray`` > * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors > * Add ``bytes.byte`` and ``bytearray.byte`` alternative constructors > * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > ``memoryview.iterbytes`` alternative iterators > Why not bytes.viewbytes (or whatever name) so that one could also subscript it? And if it were a property, one could perhaps conveniently get the n'th byte: b'abcde'.viewbytes[n] # compared to b'abcde'[n:n+1] Also, would it not be more clear to call the int -> bytes method something like bytes.fromint or bytes.fromord and introduce the same thing on str? And perhaps allow multiple arguments to create a str/bytes of length > 1. I guess this may violate TOOWTDI, but anyway, just a thought. -- Koos ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 06/07/2016 02:20 PM, Eric Snow wrote: On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: On 7 June 2016 at 10:51, Eric Snow wrote: * ``__definition_order__`` is a tuple * ``__definition_order__`` is a read-only attribute Thinking about the class decorator use case, I think this may need to be reconsidered, as class decorators may: 1. Remove class attributes 2. Add class attributes This will then lead to __definition_order__ getting out of sync with the current state of the class namespace. I'm not clear on your point. Decorators are applied after the class has been created. Hence they have no impact on the class's definition order. I'd expect __definition_order__ to strictly represent what happened in the class body during definition, and not anything afterward. Certainly __definition_order__ might not align with __dict__ (or dir()); we don't have any way to guarantee that it would, do we? If anything, the ability to diff __definition_order__ and __dict__ is a positive, since it allows you to see changes on the class since it was defined. One option for dealing with that would be to make type.__setattr__ and type.__delattr__ aware of __definition_order__, and have them replace the tuple with a new one as needed. If we did that, then the main question would be whether updating an existing attribute changed the definition order, and I'd be inclined to say "No" (to minimise the side effects of monkey-patching). The main alternative would be to make __definition_order__ writable, so the default behaviour would be for it to reflect the original class body, but decorators would be free to update it to reflect their changes, as well as to make other modifications (e.g. stripping out all callables from the list). I think both of those make __definition_order__ more complicated and less useful. As the PEP stands, folks can be confident in what __definition_order__ represents. What would you consider to be the benefit of a mutable (or replaceable) __definition_order__ that outweighs the benefit of a simpler definition of what's in it. I think the question is which is more useful? - a definition order that lists items that are not in the class, as well as not having items that are in the class (set by the decorator) or - a definition order that is representative of the class state after all decorators have been applied One argument for the latter is that, even though the class has been technically "defined" (class body executed, type.__new__ called, etc.), applying decorators feels like continued class definition. One argument for the former is simplified implementation, and is definition order really important after the class body has been executed? (okay, two arguments ;) Perhaps the best thing is just to make it writeable -- after all, if __class__, __name__, etc., can all be changed, why should __definition_order__ be special? -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
Hello, On Tue, 7 Jun 2016 17:31:19 -0400 Barry Warsaw wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > ``memoryview.iterbytes`` alternative iterators > > +1 but I want to go just a little farther. > > We can't change bytes.__getitem__ but we can add another method that > returns single byte objects? I think it's still a bit of a pain to > extract single bytes even with .iterbytes(). > > Maybe .iterbytes can take a single index argument (blech) or add a > method like .byte_at(i). I'll let you bikeshed on the name. What's wrong with b[i:i+1] ? -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 7 June 2016 at 14:20, Eric Snow wrote: > On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: >> The main alternative would be to make __definition_order__ writable, >> so the default behaviour would be for it to reflect the original class >> body, but decorators would be free to update it to reflect their >> changes, as well as to make other modifications (e.g. stripping out >> all callables from the list). > > I think both of those make __definition_order__ more complicated and > less useful. As the PEP stands, folks can be confident in what > __definition_order__ represents. What would you consider to be the > benefit of a mutable (or replaceable) __definition_order__ that > outweighs the benefit of a simpler definition of what's in it. Mainly the fact that class decorators and metaclasses can't hide the difference between "attributes defined in the class body" and "attributes injected by a decorator or metaclass". I don't have a concrete use case for that, it just bothers me on general principles when we have things the interpreter can do that can't readily be emulated in Python code. However, if it proves to be a hassle in practice, making it writable can be done later based on specific use cases, so I don't mind if the PEP stays as it is on that front. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
Hello, On Tue, 07 Jun 2016 13:28:13 -0700 Ethan Furman wrote: > Minor changes: updated version numbers, add punctuation. > > The current text seems to take into account Guido's last comments. > > Thoughts before asking for acceptance? > > [] > Deprecation of current "zero-initialised sequence" behaviour > > > Currently, the ``bytes`` and ``bytearray`` constructors accept an > integer argument and interpret it as meaning to create a > zero-initialised sequence of the given size:: > > >>> bytes(3) > b'\x00\x00\x00' > >>> bytearray(3) > bytearray(b'\x00\x00\x00') > > This PEP proposes to deprecate that behaviour in Python 3.6, and > remove it entirely in Python 3.7. Why the desire to break applications of thousands and thousands of people? Besides, bytes(3) behavior is very logical. Everyone who knows what malloc(3) does also knows what bytes(3) does. Who doesn't, can learn, and eventually be grateful that learning Python actually helped them to learn other language as well. [] > Addition of explicit "single byte" constructors > --- > > As binary counterparts to the text ``chr`` function, this PEP > proposes the addition of an explicit ``byte`` alternative constructor > as a class method on both ``bytes`` and ``bytearray``:: > > >>> bytes.byte(3) > b'\x03' > >>> bytearray.byte(3) > bytearray(b'\x03') > > These methods will only accept integers in the range 0 to 255 > (inclusive):: > > >>> bytes.byte(512) > Traceback (most recent call last): >File "", line 1, in > ValueError: bytes must be in range(0, 256) > > >>> bytes.byte(1.0) > Traceback (most recent call last): >File "", line 1, in > TypeError: 'float' object cannot be interpreted as an integer > > The documentation of the ``ord`` builtin will be updated to > explicitly note that ``bytes.byte`` is the inverse operation for > binary data, while ``chr`` is the inverse operation for text data. The documentation should probably also mention that bytes.byte(x) is equivalent to x.to_bytes(1, "little"). [] -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 7 June 2016 at 14:31, Barry Warsaw wrote: > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and >> ``memoryview.iterbytes`` alternative iterators > > +1 but I want to go just a little farther. > > We can't change bytes.__getitem__ but we can add another method that returns > single byte objects? I think it's still a bit of a pain to extract single > bytes even with .iterbytes(). > > Maybe .iterbytes can take a single index argument (blech) or add a method like > .byte_at(i). I'll let you bikeshed on the name. Perhaps: data.getbyte(i) data.iterbytes() The rationale for "Why not a live view?" is that an iterator is simple to define and implement, while we know from experience with memoryview and the various dict views that live views are a minefield for folks defining new container types. Since this PEP would in some sense change what it means to implement a full "bytes-like object", it's worth keeping implementation complexity in mind. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: > Hello, > > On Tue, 7 Jun 2016 17:31:19 -0400 > Barry Warsaw wrote: > > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > > >* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > > ``memoryview.iterbytes`` alternative iterators > > > > +1 but I want to go just a little farther. > > > > We can't change bytes.__getitem__ but we can add another method that > > returns single byte objects? I think it's still a bit of a pain to > > extract single bytes even with .iterbytes(). > > > > Maybe .iterbytes can take a single index argument (blech) or add a > > method like .byte_at(i). I'll let you bikeshed on the name. > > What's wrong with b[i:i+1] ? > It always succeeds while indexing can trigger an IndexError. ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > [email protected]] On Behalf Of Nick Coghlan > Sent: Tuesday, June 7, 2016 5:40 PM > To: Barry Warsaw > Cc: [email protected] > Subject: Re: [Python-Dev] PEP 467: Minor API improvements to bytes, > bytearray, and memoryview > > On 7 June 2016 at 14:31, Barry Warsaw wrote: > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > >> ``memoryview.iterbytes`` alternative iterators > > > > +1 but I want to go just a little farther. > > > > We can't change bytes.__getitem__ but we can add another method that > returns > > single byte objects? I think it's still a bit of a pain to extract single > > bytes even with .iterbytes(). > > > > Maybe .iterbytes can take a single index argument (blech) or add a method > like > > .byte_at(i). I'll let you bikeshed on the name. > > Perhaps: > > data.getbyte(i) > data.iterbytes() data.getbyte(index_or_slice_object) ? while it might not be... ideal... to create a sliceable live view object, we can have a method that accepts a slice, even if we have to create it manually (or at least make it convenient for those who wish to wrap a bytes object in their own type and blindly pass the first-non-self arg of a custom __getitem__ to the method). > The rationale for "Why not a live view?" is that an iterator is simple > to define and implement, while we know from experience with memoryview > and the various dict views that live views are a minefield for folks > defining new container types. Since this PEP would in some sense > change what it means to implement a full "bytes-like object", it's > worth keeping implementation complexity in mind. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium- > list%40sdamon.com ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 2:34 PM, Nick Coghlan wrote: > On 7 June 2016 at 14:20, Eric Snow wrote: >> What would you consider to be the >> benefit of a mutable (or replaceable) __definition_order__ that >> outweighs the benefit of a simpler definition of what's in it. > > Mainly the fact that class decorators and metaclasses can't hide the > difference between "attributes defined in the class body" and > "attributes injected by a decorator or metaclass". I don't have a > concrete use case for that, it just bothers me on general principles > when we have things the interpreter can do that can't readily be > emulated in Python code. Yeah, I see what you mean. > > However, if it proves to be a hassle in practice, making it writable > can be done later based on specific use cases, so I don't mind if the > PEP stays as it is on that front. Agreed. -eric ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 7 June 2016 at 14:33, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 13:28:13 -0700 > Ethan Furman wrote: > >> Minor changes: updated version numbers, add punctuation. >> >> The current text seems to take into account Guido's last comments. >> >> Thoughts before asking for acceptance? >> >> > [] > >> Deprecation of current "zero-initialised sequence" behaviour >> >> >> Currently, the ``bytes`` and ``bytearray`` constructors accept an >> integer argument and interpret it as meaning to create a >> zero-initialised sequence of the given size:: >> >> >>> bytes(3) >> b'\x00\x00\x00' >> >>> bytearray(3) >> bytearray(b'\x00\x00\x00') >> >> This PEP proposes to deprecate that behaviour in Python 3.6, and >> remove it entirely in Python 3.7. > > Why the desire to break applications of thousands and thousands of > people? Same argument as any deprecation: to make existing and future defects easier to find or easier to debug. That said, this is the main part I was referring to in the other thread when I mentioned some of the constructor changes were potentially controversial and probably not worth the hassle - it's the only one with the potential to break currently working code, while the others are just a matter of choosing suitable names. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
Ignore that message. I hit send before brain and hands were fully in sync. > -Original Message- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, June 7, 2016 5:51 PM > To: 'Nick Coghlan' ; 'Barry Warsaw' > > Cc: [email protected] > Subject: RE: [Python-Dev] PEP 467: Minor API improvements to bytes, > bytearray, and memoryview > > > > > -Original Message- > > From: Python-Dev [mailto:python-dev-bounces+tritium- > > [email protected]] On Behalf Of Nick Coghlan > > Sent: Tuesday, June 7, 2016 5:40 PM > > To: Barry Warsaw > > Cc: [email protected] > > Subject: Re: [Python-Dev] PEP 467: Minor API improvements to bytes, > > bytearray, and memoryview > > > > On 7 June 2016 at 14:31, Barry Warsaw wrote: > > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > > > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > >> ``memoryview.iterbytes`` alternative iterators > > > > > > +1 but I want to go just a little farther. > > > > > > We can't change bytes.__getitem__ but we can add another method > that > > returns > > > single byte objects? I think it's still a bit of a pain to extract > single > > > bytes even with .iterbytes(). > > > > > > Maybe .iterbytes can take a single index argument (blech) or add a > method > > like > > > .byte_at(i). I'll let you bikeshed on the name. > > > > Perhaps: > > > > data.getbyte(i) > > data.iterbytes() > > data.getbyte(index_or_slice_object) ? > > while it might not be... ideal... to create a sliceable live view object, we > can have a method that accepts a slice, even if we have to create it > manually (or at least make it convenient for those who wish to wrap a bytes > object in their own type and blindly pass the first-non-self arg of a custom > __getitem__ to the method). > > > The rationale for "Why not a live view?" is that an iterator is simple > > to define and implement, while we know from experience with > memoryview > > and the various dict views that live views are a minefield for folks > > defining new container types. Since this PEP would in some sense > > change what it means to implement a full "bytes-like object", it's > > worth keeping implementation complexity in mind. > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | [email protected] | Brisbane, Australia > > ___ > > Python-Dev mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python- > dev/tritium- > > list%40sdamon.com ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >> What's wrong with b[i:i+1] ? >It always succeeds while indexing can trigger an IndexError. Right. You want a method with the semantics of __getitem__() but that returns the desired type. -Barry pgpKzXeYAKnPj.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote: > On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: > >>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >>> What's wrong with b[i:i+1] ? >>It always succeeds while indexing can trigger an IndexError. > > Right. You want a method with the semantics of __getitem__() but that returns > the desired type. > And if this is called __getitem__ (with slices delegated to bytes.__getitem__) and implemented in a class, one has a view. Maybe I'm missing something, but I fail to understand what makes this significantly more problematic than an iterator. Ok, I guess we might also need __len__. -- Koos > -Barry > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com > ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman wrote: > On 06/07/2016 02:20 PM, Eric Snow wrote: >> I think both of those make __definition_order__ more complicated and >> less useful. As the PEP stands, folks can be confident in what >> __definition_order__ represents. What would you consider to be the >> benefit of a mutable (or replaceable) __definition_order__ that >> outweighs the benefit of a simpler definition of what's in it. > > I think the question is which is more useful? > > - a definition order that lists items that are not in the class, as > well as not having items that are in the class (set by the decorator) > > or > > - a definition order that is representative of the class state after > all decorators have been applied "definition" refers explicitly to the execution of the class body in a class statement. So what you've described is a bit confusing to me. If we're talking about some other semantics then the name "__definition_order__" is misleading. Also, consider that __definition_order__ is, IMHO, most useful when interpreted as the actual order of attributes in the class definition body. The point is that code outside the class body can leverage the order of assigned names within that block. So, relative to the class definition, I'm not clear on valid use cases that divorce themselves from the class definition, such that either of your scenarios is relevant. Semantics that relate more to the class namespace (__dict__) are a separate matter from this PEP. I'd welcome a broader solution that still met the needs at which __definition_order__ is aiming. For example, consider if the class's __dict__ (or rather the proxied value) were OrderedDict. In fact, Guido was originally (in 2013) amenable to that idea. However, I tried it and making it work was a challenge due to use of the concrete dict C-API. I'd be glad if it was worked out. In the meantime, this PEP is more focused on a practical representation of the ordering information inside just the class definition body. > > One argument for the latter is that, even though the class has been > technically "defined" (class body executed, type.__new__ called, etc.), > applying decorators feels like continued class definition. Perhaps. That doesn't align with my intuition on decorators, but I'll readily concede that my views aren't always particularly representative of everyone else. :) That said, there are many different uses for decorators and modifying the class namespace (__dict__) isn't the only one (and in my experience not necessarily the most common). > > One argument for the former is simplified implementation, I'm not sure what you're implying about the implementation. Do you mean that it's easier than just letting __definition_order__ be writable (or mutable)? It's actually slightly more work to make it a read-only attr. Perhaps you mean that the semantics in the PEP are easier to implement than something that tracks changes to the class namespace (__dict__) after definition is over? Probably, though I don't see anything like that happening (other than if OrderedDict were used for __dict__). > and is definition > order really important after the class body has been executed? (okay, two > arguments ;) Given that the focus is on class definition, I'd argue no. :) > > Perhaps the best thing is just to make it writeable -- after all, if > __class__, __name__, etc., can all be changed, why should > __definition_order__ be special? Not all attrs are writable and it's a case-by-case situation: some of the ones that are writable started out read-only and changed once there was a valid reason. If anything, it's arguably safer in general to take an immutable-by-default approach. -eric ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 06/07/2016 03:27 PM, Eric Snow wrote: Not all attrs are writable and it's a case-by-case situation: some of the ones that are writable started out read-only and changed once there was a valid reason. If anything, it's arguably safer in general to take an immutable-by-default approach. I'm sold. Leave it read-only. :) -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entirely in Python 3.7. Why the desire to break applications of thousands and thousands of people? Besides, bytes(3) behavior is very logical. Everyone who knows what malloc(3) does also knows what bytes(3) does. Who doesn't, can learn, and eventually be grateful that learning Python actually helped them to learn other language as well. Two reasons: 1) bytes are immutable, so creating a 3-byte 0x00 string seems ridiculous; 2) Python is not C, and the vagaries of malloc are not relevant to Python. However, there is little point in breaking working code, so a deprecation without removal is fine by me. -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 7 June 2016 at 15:22, Koos Zevenhoven wrote: > On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote: >> On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: >> >>>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: What's wrong with b[i:i+1] ? >>>It always succeeds while indexing can trigger an IndexError. >> >> Right. You want a method with the semantics of __getitem__() but that >> returns >> the desired type. >> > > And if this is called __getitem__ (with slices delegated to > bytes.__getitem__) and implemented in a class, one has a view. Maybe > I'm missing something, but I fail to understand what makes this > significantly more problematic than an iterator. Ok, I guess we might > also need __len__. Right, it's the fact that a view is a much broader API than we need, since most of the operations on the base type are already fine. The two alternate operations that people are interested in are: - like indexing, but producing bytes instead of ints - like iteration, but producing bytes instead of ints That said, it occurs to me that there's a reasonably strong composability argument in favour of a view-based approach: a view will work with operator.itemgetter() and other sequence consuming APIs, while special methods won't. The "like-memoryview-but-not" view type could also take any bytes-like object as input, similar to memoryview itself. Cheers, Nick. P.S. I'm starting to remember why I stopped working on this - I'm genuinely unsure of the right way forward, so I wasn't prepared to advocate strongly for the particular approach in the PEP :) -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote: > > This PEP changes the default class definition namespace to ``OrderedDict``. I think this would be a nice improvement. > Furthermore, the order in which the attributes are defined in each class > body will now be preserved in ``type.__definition_order__``. This allows > introspection of the original definition order, e.g. by class decorators. I'm unclear on why this would be needed. Wouldn't the OrderedDict be sufficient for preserving definition order? Raymond ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 7 June 2016 at 16:03, Raymond Hettinger wrote: > >> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote: >> >> This PEP changes the default class definition namespace to ``OrderedDict``. > > I think this would be a nice improvement. > >> Furthermore, the order in which the attributes are defined in each class >> body will now be preserved in ``type.__definition_order__``. This allows >> introspection of the original definition order, e.g. by class decorators. > > I'm unclear on why this would be needed. Wouldn't the OrderedDict be > sufficient for preserving definition order? By the time decorators run, the original execution namespace is no longer available - the contents have been copied into the class dict, which will still be a plain dict (and there's a lot of code that calls PyDict_* APIs on tp_dict, so replacing the latter with a subclass is neither trivial nor particularly safe in the presence of extension modules). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
Hello, On Tue, 07 Jun 2016 15:46:00 -0700 Ethan Furman wrote: > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > >> remove it entirely in Python 3.7. > > > > Why the desire to break applications of thousands and thousands of > > people? Besides, bytes(3) behavior is very logical. Everyone who > > knows what malloc(3) does also knows what bytes(3) does. Who > > doesn't, can learn, and eventually be grateful that learning Python > > actually helped them to learn other language as well. > > Two reasons: > > 1) bytes are immutable, so creating a 3-byte 0x00 string seems > ridiculous; There's nothing ridiculous in sending N zero bytes over network, writing to a file, transferring to a hardware device. That however raises questions e.g. how to (efficiently) fill a (subsection) of bytearray with something but a 0, and how to apply all that consistently to array.array, but I don't even want to bring it, because the answer will be "we need first to deal with subjects of this PEP". > > 2) Python is not C, and the vagaries of malloc are not relevant to > Python. Yes, but Python has always had some traits nicely similar to C, (% formatting, os.read/write at the fingertips, this bytes/bytearray constructor, etc.), and that certainly catered for sizable share of its audience. It's nice that nowadays Python is truly multi-paradigm and taught to pre-schools and used by folks who know how to analyze data much better than how to allocate memory to hold that data in the first place. But hopefully people who used Python since 1.x as a nice system-level integration language, concise without much ambiguity (definitely less than other languages, maybe COBOL excluded) shouldn't suffer and have their stuff broken. > > However, there is little point in breaking working code, so a > deprecation without removal is fine by me. Thanks. > > -- > ~Ethan~ -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 520: Ordered Class Definition Namespace
I've grabbed a PEP # (520) and updated the PEP to clarify points that
were brought up earlier today. Given positive feedback I got at PyCon
and the reaction today, I'm hopeful the PEP isn't far off from
pronouncement. :)
-eric
==
PEP: 520
Title: Ordered Class Definition Namespace
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
Abstract
This PEP changes the default class definition namespace to ``OrderedDict``.
Furthermore, the order in which the attributes are defined in each class
body will now be preserved in ``type.__definition_order__``. This allows
introspection of the original definition order, e.g. by class decorators.
Note: just to be clear, this PEP is *not* about changing ``__dict__`` for
classes to ``OrderedDict``.
Motivation
==
Currently the namespace used during execution of a class body defaults
to ``dict``. If the metaclass defines ``__prepare__()`` then the result
of calling it is used. Thus, before this PEP, if you needed your class
definition namespace to be ``OrderedDict`` you had to use 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. 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``.
The usefulness of ``OrderedDict``-by-default is greatly increased if the
definition order is directly introspectable on classes afterward,
particularly by code that is independent of the original class definition.
One of the original motivating use cases for this PEP is generic class
decorators that make use of the definition order.
Changing the default class definition namespace has been discussed a
number of times, including on the mailing lists and in PEP 422 and
PEP 487 (see the References section below).
Specification
=
* the default class *definition* namespace is now ``OrderdDict``
* the order in which class attributes are defined is preserved in the
new ``__definition_order__`` attribute on each class
* "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
* ``__definition_order__`` is a tuple
* ``__definition_order__`` is a read-only attribute
* ``__definition_order__`` is always set:
1. if ``__definition_order__`` is defined in the class body then the
value is used as-is, though the attribute will still be read-only
2. types that do not have a class definition (e.g. builtins) have
their ``__definition_order__`` set to ``None``
3. types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass) have their ``__definition_order__``
set to ``None`` (except where #1 applies)
The following code demonstrates roughly equivalent semantics::
class Meta(type):
def __prepare__(cls, *args, **kwargs):
return OrderedDict()
class Spam(metaclass=Meta):
ham = None
eggs = 5
__definition_order__ = tuple(k for k in locals()
if (!k.startswith('__') or
!k.endswith('__')))
Note that [pep487_] proposes a similar solution, albeit as part of a
broader proposal.
Why a tuple?
Use of a tuple reflects the fact that we are exposing the order in
which attributes on the class were *defined*. Since the definition
is already complete by the time ``definition_order__`` is set, the
content and order of the value won't be changing. Thus we use a type
that communicates that state of immutability.
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 ``__definition_order__`` is centered on the class definition
body. The use cases for dealing with the class namespace (``__dict__``)
post-definition are a separate matter. ``__definition_order__`` would
be a significantly misleading name for a supporting feature.
See [nick_concern_] for more discussion.
Why ignore "dunder" names?
--
Names starting and ending with "__" are reserved for use by the
interpreter. In practice they should not be relevant to
Re: [Python-Dev] PEP: Ordered Class Definition Namespace
On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote: > On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote: > > On 6/7/2016 1:51 PM, Eric Snow wrote: > > > >> Note: just to be clear, this PEP is *not* about changing > > > >> ``type.__dict__`` to ``OrderedDict``. > > > > By 'type', do you mean the one and one objected named 'type or the class > > being defined? To be really clear, will the following change? > > > class C: pass > > > type(C.__dict__) > > > > I mean the latter, "type" -> the class being defined. Could you clarify that in the PEP please? Like Terry, I too found it unclear. I think there are a couple of places where you refer to `type` and it isn't clear whether you mean builtins.type or something else. -- Steve ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 06/07/2016 05:50 PM, Eric Snow wrote:
Overall +1. Some nits below.
Specification
=
3. types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass) have their ``__definition_order__``
set to ``None``
(unless ``__definition_order__`` is present in
the class dict either by virtue of being in the class body or
because the metaclass inserted it before calling
``type.__new__``)
__definition_order__ = tuple(k for k in locals()
if (!k.startswith('__') or
!k.endswith('__')))
Still mixing C and Python! ;)
Why a tuple?
Use of a tuple reflects the fact that we are exposing the order in
which attributes on the class were *defined*. Since the definition
is already complete by the time ``definition_order__`` is set, the
content and order of the value won't be changing. Thus we use a type
that communicates that state of immutability.
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.
If __definition_order__ is supposed to be immutable as well as read-only
then we should convert non-tuples to tuples. No point in letting that
user bug slip through.
Why 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 early everyone they would only
s/early/nearly
Why is __definition_order__ even necessary?
---
Since the definition order is not preserved in ``__dict__``, it would be
lost once class definition execution completes. Classes *could*
explicitly set the attribute as the last thing in the body. However,
then independent decorators could only make use of classes that had done
so. Instead, ``__definition_order__`` preserves this one bit of info
from the class body so that it is universally available.
s/would be/is
--
~Ethan~
___
Python-Dev mailing list
[email protected]
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 467: Minor API improvements to bytes, bytearray, and memoryview
On 7 June 2016 at 20:28, Ethan Furman wrote: > Addition of explicit "single byte" constructors > --- > > As binary counterparts to the text ``chr`` function, this PEP proposes the > addition of an explicit ``byte`` alternative constructor as a class method > on both ``bytes`` and ``bytearray``:: > > >>> bytes.byte(3) > b'\x03' > >>> bytearray.byte(3) > bytearray(b'\x03') Bytes.byte() is a great idea. But what’s the point or use case of bytearray.byte(), a mutable array of one pre-defined byte? > Addition of optimised iterator methods that produce ``bytes`` objects > - > > This PEP proposes that ``bytes``, ``bytearray`` and ``memoryview`` gain an > optimised ``iterbytes`` method that produces length 1 ``bytes`` objects > rather than integers:: > > for x in data.iterbytes(): > # x is a length 1 ``bytes`` object, rather than an integer Might be good to have an example with concrete output, so you see the one-byte strings coming out of it. >>> tuple(b"ABC".iterbytes()) (b'A', b'B', b'C') ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote: > Hello, > > On Tue, 07 Jun 2016 15:46:00 -0700 > Ethan Furman wrote: > > > On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: > > > > >> This PEP proposes to deprecate that behaviour in Python 3.6, and > > >> remove it entirely in Python 3.7. > > > > > > Why the desire to break applications of thousands and thousands of > > > people? I'm not so sure that *thousands* of people are relying on this behaviour, but your point is taken that it is a backwards-incompatible change. > > > Besides, bytes(3) behavior is very logical. Everyone who > > > knows what malloc(3) does also knows what bytes(3) does. Most Python coders are not C coders. Knowing C is not and should not be a pre-requisite for using Python. > > > Who > > > doesn't, can learn, and eventually be grateful that learning Python > > > actually helped them to learn other language as well. I really don't think that learning Python will help with C. > > Two reasons: > > > > 1) bytes are immutable, so creating a 3-byte 0x00 string seems > > ridiculous; > > There's nothing ridiculous in sending N zero bytes over network, > writing to a file, transferring to a hardware device. True, but there is a good way of writing N identical bytes, not limited to nulls, using the replication operator: py> b'\xff'*10 b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' which is more useful than `bytes(10)` since that can only produce zeroes. > That however > raises questions e.g. how to (efficiently) fill a (subsection) of > bytearray with something but a 0 Slicing. py> b = bytearray(10) py> b[4:4] = b'\xff'*4 py> b bytearray(b'\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00') -- Steve ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote:
> On 06/07/2016 05:50 PM, Eric Snow wrote:
>> __definition_order__ = tuple(k for k in locals()
>> if (!k.startswith('__') or
>> !k.endswith('__')))
>
>
> Still mixing C and Python! ;)
I knew I was missing something!
>
>
>> Why a tuple?
>>
>>
>> Use of a tuple reflects the fact that we are exposing the order in
>> which attributes on the class were *defined*. Since the definition
>> is already complete by the time ``definition_order__`` is set, the
>> content and order of the value won't be changing. Thus we use a type
>> that communicates that state of immutability.
>
>
>> 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.
>
>
> If __definition_order__ is supposed to be immutable as well as read-only
> then we should convert non-tuples to tuples. No point in letting that
> user bug slip through.
Do you mean if a class explicitly defines __definition_order__? If
so, I'm not clear on how that would work. It could be set to
anything, including None or a value that does not iterate into a
definition order. If someone explicitly set __definition_order__ then
I think it should be used as-is.
>
>
>> Why 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 early everyone they would only
>
>
> s/early/nearly
fixed
>
>> Why is __definition_order__ even necessary?
>> ---
>>
>> Since the definition order is not preserved in ``__dict__``, it would be
>> lost once class definition execution completes. Classes *could*
>> explicitly set the attribute as the last thing in the body. However,
>> then independent decorators could only make use of classes that had done
>> so. Instead, ``__definition_order__`` preserves this one bit of info
>> from the class body so that it is universally available.
>
>
> s/would be/is
fixed
Thanks!
-eric
___
Python-Dev mailing list
[email protected]
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: Ordered Class Definition Namespace
On Tue, Jun 7, 2016 at 6:09 PM, Steven D'Aprano wrote: > On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote: >> I mean the latter, "type" -> the class being defined. > > Could you clarify that in the PEP please? Like Terry, I too found it > unclear. I think there are a couple of places where you refer to `type` > and it isn't clear whether you mean builtins.type or something else. Yep. Done. -eric ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 7 June 2016 at 21:56, Nick Coghlan wrote: > On 7 June 2016 at 14:33, Paul Sokolovsky wrote: >> Ethan Furman wrote: >>> Deprecation of current "zero-initialised sequence" behaviour >>> >>> >>> Currently, the ``bytes`` and ``bytearray`` constructors accept an >>> integer argument and interpret it as meaning to create a >>> zero-initialised sequence of the given size:: >>> >>> >>> bytes(3) >>> b'\x00\x00\x00' >>> >>> bytearray(3) >>> bytearray(b'\x00\x00\x00') >>> >>> This PEP proposes to deprecate that behaviour in Python 3.6, and >>> remove it entirely in Python 3.7. >> >> Why the desire to break applications of thousands and thousands of >> people? > > Same argument as any deprecation: to make existing and future defects > easier to find or easier to debug. > > That said, this is the main part I was referring to in the other > thread when I mentioned some of the constructor changes were > potentially controversial and probably not worth the hassle - it's the > only one with the potential to break currently working code, while the > others are just a matter of choosing suitable names. An argument against deprecating bytearray(n) in particular is that this is supported in Python 2. I think I have (ab)used this fact to work around the problem with bytes(n) in Python 2 & 3 compatible code. ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
> On Jun 7, 2016, at 4:12 PM, Nick Coghlan wrote: > > By the time decorators run, the original execution namespace is no > longer available - the contents have been copied into the class dict, > which will still be a plain dict (and there's a lot of code that calls > PyDict_* APIs on tp_dict, so replacing the latter with a subclass is > neither trivial nor particularly safe in the presence of extension > modules). That makes sense. +1 all around. Raymond ___ Python-Dev mailing list [email protected] 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: Ordered Class Definition Namespace
On 07.06.16 20:51, Eric Snow wrote: Hi all, Following discussion a few years back (and rough approval from Guido [1]), I started work on using OrderedDict for the class definition namespace by default. The bulk of the effort lay in implementing OrderedDict in C, which I got landed just in time for 3.5. The remaining work was quite minimal and the actual change is quite small. My intention was to land the patch soon, having gone through code review during PyCon. However, Nick pointed out to me the benefit of having a concrete point of reference for the change, as well as making sure it isn't a problem for other implementations. So in that spirit, here's a PEP for the change. Feedback is welcome, particularly from from other implementors. Be aware that C implementation of OrderedDict still is not free from problems. ___ Python-Dev mailing list [email protected] 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 07.06.16 23:28, Ethan Furman wrote: Minor changes: updated version numbers, add punctuation. The current text seems to take into account Guido's last comments. Thoughts before asking for acceptance? PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-03-30 Python-Version: 3.5 Post-History: 2014-03-30 2014-08-15 2014-08-16 Abstract During the initial development of the Python 3 language specification, the core ``bytes`` type for arbitrary binary data started as the mutable type that is now referred to as ``bytearray``. Other aspects of operating in the binary domain in Python have also evolved over the course of the Python 3 series. This PEP proposes four small adjustments to the APIs of the ``bytes``, ``bytearray`` and ``memoryview`` types to make it easier to operate entirely in the binary domain: * Deprecate passing single integer values to ``bytes`` and ``bytearray`` * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors * Add ``bytes.byte`` and ``bytearray.byte`` alternative constructors * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and ``memoryview.iterbytes`` alternative iterators "Byte" is an alias to "octet" (8-bit integer) in modern terminology. Iterating bytes and bytearray already produce bytes. Wouldn't this be confused? May be name these methods "iterbytestrings", since they adds str-like behavior? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
Ethan Furman writes: > * Deprecate passing single integer values to ``bytes`` and > ``bytearray`` Why? This is a slightly awkward idiom compared to .zeros (EITBI etc), but your 32-bit clock will roll over before we can actually remove it. There are a lot of languages that do this kind of initialization of arrays based on ``count``. If you want to do something useful here, add an optional argument (here in ridiculous :-) generality: bytes(count, tile=[0]) -> bytes(tile * count) where ``tile`` is a Sequence of a type that is acceptable to bytes anyway, or Sequence[int], which is treated as b"".join([bytes(chr(i)) for i in tile] * count]) Interpretation of ``count`` of course i bikesheddable, with at least one alternative interpretation (length of result bytes, with last tile truncated if necessary). > * Add ``bytes.zeros`` and ``bytearray.zeros`` alternative constructors this is an API break if you take the deprecation as a mandate (which eventual removal does indicate). And backward compatibility for clients of the bytes API means that we violate TOOWTDI indefinitely, on a constructor of quite specialized utility. Yuck. -1 on both. Barry Warsaw writes later in thread: > We can't change bytes.__getitem__ but we can add another method > that returns single byte objects? I think it's still a bit of a > pain to extract single bytes even with .iterbytes(). +1 ISTM that more than the other changes, this is the most important one. Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
