Re: [Python-Dev] Backward incompatible change about docstring AST
Hi, On 27 February 2018 at 15:32, Serhiy Storchaka wrote: > 1. CPython and PyPy set different position for multiline strings. PyPy sets > the position of the start of string, but CPython sets the position of the > end of the string. A program that utilizes the docstring position needs to > handle both of these cases. If that's true it's a PyPy bug. https://bitbucket.org/pypy/pypy/issues/2767/docstring-position-in-the-ast A bientôt, Armin. ___ 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] Backward incompatible change about docstring AST
28.02.18 12:49, Armin Rigo пише: On 27 February 2018 at 15:32, Serhiy Storchaka wrote: 1. CPython and PyPy set different position for multiline strings. PyPy sets the position of the start of string, but CPython sets the position of the end of the string. A program that utilizes the docstring position needs to handle both of these cases. If that's true it's a PyPy bug. https://bitbucket.org/pypy/pypy/issues/2767/docstring-position-in-the-ast This is rather a CPython bug (somewhere may be an open issue for this). ___ 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 for binary sequences) - any thoughts?
On 28 February 2018 at 03:15, Ethan Furman wrote:
> On 02/26/2018 11:34 PM, Elias Zamaria wrote:
>
> I don't know how I would feel working on something so general, of use to
>> so many people for lots of different purposes.
>> Do I know enough about all of the use cases and what everyone wants? I am
>> not completely against it but I'd need to
>> think about it.
>>
>
> Part of the PEP writing process is asking for and collecting use-cases;
> if possible, looking at other code projects for use-cases is also useful.
>
> Time needed can vary widely depending on the subject; if I recall
> correctly, PEP 409 only took a few days, while PEP 435 took several weeks.
> PEP 467 has already gone through a few iterations, so hopefully not too
> much more time is required.
>
One of the main developments not yet accounted for in the PEP is the fact
that `memoryview` now supports efficient bytes-based iteration over
arbitrary buffer-exporting objects:
def iterbytes(obj):
with memoryview(obj) as m:
return iter(m.cast('c'))
This means that aspect of PEP 467 will need to lean more heavily on
discoverability arguments (since the above approach isn't obvious at all
unless you're already very familiar with the use of `memoryview`), since
the runtime benefit from avoiding the upfront cost of allocating and
initialising two memoryview objects by using a custom iterator type instead
is likely to be fairly small.
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] Should the dataclass frozen property apply to subclasses?
On 28 February 2018 at 10:37, Eric V. Smith wrote:
> So, given a frozen dataclass "C" with field names in "field_names", I
> propose changing __setattr__ to be:
>
> def __setattr__(self, name, value):
> if type(self) is C or name in field_names:
> raise FrozenInstanceError(f'cannot assign to field {name!r}')
> super(cls, self).__setattr__(name, value)
>
> In the current 3.7.0a2 implementation of frozen dataclasses, __setattr__
> always raises. The change is the test and then call to super().__setattr__
> if it's a derived class. The result is an exception if either self is an
> instance of C, or if self is an instance of a derived class, but the
> attribute being set is a field of C.
>
I'm assuming you meant "3.7.0b2" here (and similarly alpha->beta for the
other version numbers below)
> So going back to original questions above, my suggestions are:
>
> 1. What happens when a frozen dataclass inherits from a non-frozen
> dataclass? The result is a frozen dataclass, and all fields are
> non-writable. No non-fields can be added. This is a reversion to the
> 3.7.0a1 behavior.
>
> 2. What happens when a non-frozen dataclass inherits from a frozen
> dataclass? The result is a frozen dataclass, and all fields are
> non-writable. No non-fields can be added. This is a reversion to the
> 3.7.0a1 behavior. I'd also be okay with this case being an error, and you'd
> have to explicitly mark the derived class as frozen. This is the 3.7.0a2
> behavior.
>
> 3. What happens when a non-dataclass inherits from a frozen dataclass? The
> fields that are in the dataclass are non-writable, but new non-field
> attributes can be added. This is new behavior.
>
> 4. Can new non-field attributes be created for frozen dataclasses? No.
> This is existing behavior.
>
+1 from me for the variant of this where dataclasses inheriting from frozen
data classes must explicitly mark themselves as frozen (at least for now).
That way we leave the door open to allowing a variant where a non-frozen
dataclass that inherits from a frozen dataclass can set "hash=False" on all
of the new fields it adds to avoid becoming frozen itself.
> I'm hoping this change isn't so large that we can't get it in to 3.7.0a3
> next month.
>
I think this qualifies as the beta period serving its intended purpose
(i.e. reviewing and refining the behaviour of already added features,
without allowing completely new features).
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] Should the dataclass frozen property apply to subclasses?
On 3/1/2018 1:02 AM, Nick Coghlan wrote: I'm assuming you meant "3.7.0b2" here (and similarly alpha->beta for the other version numbers below) Oops, yes. Thanks. So going back to original questions above, my suggestions are: 1. What happens when a frozen dataclass inherits from a non-frozen dataclass? The result is a frozen dataclass, and all fields are non-writable. No non-fields can be added. This is a reversion to the 3.7.0a1 behavior. 2. What happens when a non-frozen dataclass inherits from a frozen dataclass? The result is a frozen dataclass, and all fields are non-writable. No non-fields can be added. This is a reversion to the 3.7.0a1 behavior. I'd also be okay with this case being an error, and you'd have to explicitly mark the derived class as frozen. This is the 3.7.0a2 behavior. 3. What happens when a non-dataclass inherits from a frozen dataclass? The fields that are in the dataclass are non-writable, but new non-field attributes can be added. This is new behavior. 4. Can new non-field attributes be created for frozen dataclasses? No. This is existing behavior. +1 from me for the variant of this where dataclasses inheriting from frozen data classes must explicitly mark themselves as frozen (at least for now). That way we leave the door open to allowing a variant where a non-frozen dataclass that inherits from a frozen dataclass can set "hash=False" on all of the new fields it adds to avoid becoming frozen itself. I tend to agree. It's not like this is a huge burden, and at least the author is acknowledging that the class will end up frozen. I'm hoping this change isn't so large that we can't get it in to 3.7.0a3 next month. I think this qualifies as the beta period serving its intended purpose (i.e. reviewing and refining the behaviour of already added features, without allowing completely new features). 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
