[Python-Dev] Restrict the type of __slots__

[Serhiy Storchaka]

Currently __slots__ can be either string or an iterable of strings.

1. If it is a string, it is a name of a single slot. Third-party code 
which iterates __slots__ will be confused.


2. If it is an iterable, it should emit names of slots. Note that 
non-reiterable iterators are accepted too, but it causes weird bugs if 
__slots__ is iterated more than once. For example it breaks default 
pickling and copying.


I propose to restrict the type of __slots__. Require it always been a 
tuple of strings. Most __slots__ in real code are tuples. It is rarely 
we need only single slot and set __slots__ as a string.


It will break some code (there are 2 occurrences in the stdlib an 1 in 
scripts), but that code can be easily fixed.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Serhiy Storchaka]

18.03.22 11:29, Serhiy Storchaka пише:
It will break some code (there are 2 occurrences in the stdlib an 1 in 
scripts), but that code can be easily fixed.


Actually it will break more code, because initializing __slots__ with a 
list is pretty common. Maybe restrict it to tuple or list? But having an 
immutable __slots__ may be more reliable.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Ronald Oussoren via Python-Dev]

> On 18 Mar 2022, at 10:29, Serhiy Storchaka  wrote:
> 
> Currently __slots__ can be either string or an iterable of strings.
> 
> 1. If it is a string, it is a name of a single slot. Third-party code which 
> iterates __slots__ will be confused.
> 
> 2. If it is an iterable, it should emit names of slots. Note that 
> non-reiterable iterators are accepted too, but it causes weird bugs if 
> __slots__ is iterated more than once. For example it breaks default pickling 
> and copying.
> 
> I propose to restrict the type of __slots__. Require it always been a tuple 
> of strings. Most __slots__ in real code are tuples. It is rarely we need only 
> single slot and set __slots__ as a string.
> 
> It will break some code (there are 2 occurrences in the stdlib an 1 in 
> scripts), but that code can be easily fixed.

Pydoc supports __slots__ that is a dict, and will use the values in the dict 
als documentation for the slots.   I’ve also seen code using ``__slots__ =  
“field1 field2”.split()``. I don’t particularly like this code pattern, but 
your proposal would break this.

Also note that __slots__ only has a side effect during class definition, 
changing it afterwards is possible but has no effect (“class Foo: pass; 
Foo.__slots__ = 42”). This surprised my recently and I have no idea if this 
feature is ever used.

Ronald

> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
> Code of Conduct: http://python.org/psf/codeofconduct/

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Joao S. O. Bueno]

IMO this is a purism that have little, if any place in language
restrictions.
I see that not allowing. "run once" iterables could indeed void attempts to
write
"deliberatly non cooperative code" - but can it even be reliably detected?

The other changes seem just to break backwards compatibility for little or
no gain at all.



On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev <
python-dev@python.org> wrote:

>
>
> On 18 Mar 2022, at 10:29, Serhiy Storchaka  wrote:
>
> Currently __slots__ can be either string or an iterable of strings.
>
> 1. If it is a string, it is a name of a single slot. Third-party code
> which iterates __slots__ will be confused.
>
> 2. If it is an iterable, it should emit names of slots. Note that
> non-reiterable iterators are accepted too, but it causes weird bugs if
> __slots__ is iterated more than once. For example it breaks default
> pickling and copying.
>
> I propose to restrict the type of __slots__. Require it always been a
> tuple of strings. Most __slots__ in real code are tuples. It is rarely we
> need only single slot and set __slots__ as a string.
>
> It will break some code (there are 2 occurrences in the stdlib an 1 in
> scripts), but that code can be easily fixed.
>
>
> Pydoc supports __slots__ that is a dict, and will use the values in the
> dict als documentation for the slots.   I’ve also seen code using
> ``__slots__ =  “field1 field2”.split()``. I don’t particularly like this
> code pattern, but your proposal would break this.
>
> Also note that __slots__ only has a side effect during class definition,
> changing it afterwards is possible but has no effect (“class Foo: pass;
> Foo.__slots__ = 42”). This surprised my recently and I have no idea if this
> feature is ever used.
>
> Ronald
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/54XYWCLCXPM75LOGHPONKKRUKPUFKYQS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Ronald Oussoren via Python-Dev]

> On 18 Mar 2022, at 14:37, Joao S. O. Bueno  wrote:

Please don’t toppost when responding to a normally threaded message. That makes 
it unnecessary hard to follow the conversation.

> 
> IMO this is a purism that have little, if any place in language restrictions.
> I see that not allowing. "run once" iterables could indeed void attempts to 
> write
> "deliberatly non cooperative code" - but can it even be reliably detected? 
> 
> The other changes seem just to break backwards compatibility for little or no 
> gain at all. 

It may not be worth the trouble to fix this, but Serhiy’s proposal does try to 
fix a ward.  

It may be better to rely on linter’s here, but one way to do this with few 
backward compatibility concerns:

- if __slots__ is a dict keep it as is
- Otherwise use tuple(__slots__) while constructing the class and store that 
value in the __slots__ attribute of the class

That way the value of the attribute reflects the slots that were created while 
not breaking code that uses __slots__ and doesn’t change the value after class 
creation.

Ronald

> 
> 
> 
> On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev 
> mailto:python-dev@python.org>> wrote:
> 
> 
>> On 18 Mar 2022, at 10:29, Serhiy Storchaka > > wrote:
>> 
>> Currently __slots__ can be either string or an iterable of strings.
>> 
>> 1. If it is a string, it is a name of a single slot. Third-party code which 
>> iterates __slots__ will be confused.
>> 
>> 2. If it is an iterable, it should emit names of slots. Note that 
>> non-reiterable iterators are accepted too, but it causes weird bugs if 
>> __slots__ is iterated more than once. For example it breaks default pickling 
>> and copying.
>> 
>> I propose to restrict the type of __slots__. Require it always been a tuple 
>> of strings. Most __slots__ in real code are tuples. It is rarely we need 
>> only single slot and set __slots__ as a string.
>> 
>> It will break some code (there are 2 occurrences in the stdlib an 1 in 
>> scripts), but that code can be easily fixed.
> 
> Pydoc supports __slots__ that is a dict, and will use the values in the dict 
> als documentation for the slots.   I’ve also seen code using ``__slots__ =  
> “field1 field2”.split()``. I don’t particularly like this code pattern, but 
> your proposal would break this.
> 
> Also note that __slots__ only has a side effect during class definition, 
> changing it afterwards is possible but has no effect (“class Foo: pass; 
> Foo.__slots__ = 42”). This surprised my recently and I have no idea if this 
> feature is ever used.
> 
> Ronald
> 
>> 
>> ___
>> Python-Dev mailing list -- python-dev@python.org 
>> 
>> To unsubscribe send an email to python-dev-le...@python.org 
>> 
>> https://mail.python.org/mailman3/lists/python-dev.python.org/ 
>> 
>> Message archived at 
>> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
>>  
>> 
>> Code of Conduct: http://python.org/psf/codeofconduct/ 
>> 
> 
> —
> 
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/ 
> ___
> Python-Dev mailing list -- python-dev@python.org 
> 
> To unsubscribe send an email to python-dev-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FZFRSHSJ3HQU37V6RFZNHMFGJXUPJ32X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Eric V. Smith]

On 3/18/2022 10:01 AM, Ronald Oussoren via Python-Dev wrote:




On 18 Mar 2022, at 14:37, Joao S. O. Bueno  wrote:

IMO this is a purism that have little, if any place in language 
restrictions.
I see that not allowing. "run once" iterables could indeed void 
attempts to write
"deliberatly non cooperative code" - but can it even be reliably 
detected?


The other changes seem just to break backwards compatibility for 
little or no gain at all.
There a practical need for these changes. See 
https://bugs.python.org/issue46382 for a case where dataclasses needs 
__slots__ to be iterated over after the class has been created. And it 
would be good if __slots__ accurately reflected the slots that were 
actually created.


It may not be worth the trouble to fix this, but Serhiy’s proposal 
does try to fix a ward.


It may be better to rely on linter’s here, but one way to do this with 
few backward compatibility concerns:


- if __slots__ is a dict keep it as is
- Otherwise use tuple(__slots__) while constructing the class and 
store that value in the __slots__ attribute of the class


That way the value of the attribute reflects the slots that were 
created while not breaking code that uses __slots__ and doesn’t change 
the value after class creation.


I like this approach, too.

Eric



Ronald





On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev 
 wrote:





On 18 Mar 2022, at 10:29, Serhiy Storchaka 
wrote:

Currently __slots__ can be either string or an iterable of strings.

1. If it is a string, it is a name of a single slot. Third-party
code which iterates __slots__ will be confused.

2. If it is an iterable, it should emit names of slots. Note
that non-reiterable iterators are accepted too, but it causes
weird bugs if __slots__ is iterated more than once. For example
it breaks default pickling and copying.

I propose to restrict the type of __slots__. Require it always
been a tuple of strings. Most __slots__ in real code are tuples.
It is rarely we need only single slot and set __slots__ as a string.

It will break some code (there are 2 occurrences in the stdlib
an 1 in scripts), but that code can be easily fixed.


Pydoc supports __slots__ that is a dict, and will use the values
in the dict als documentation for the slots.   I’ve also seen
code using ``__slots__ =  “field1 field2”.split()``. I don’t
particularly like this code pattern, but your proposal would
break this.

Also note that __slots__ only has a side effect during class
definition, changing it afterwards is possible but has no effect
(“class Foo: pass; Foo.__slots__ = 42”). This surprised my
recently and I have no idea if this feature is ever used.

Ronald



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
Code of Conduct: http://python.org/psf/codeofconduct/


—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
Code of Conduct: http://python.org/psf/codeofconduct/



—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/


___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/FZFRSHSJ3HQU37V6RFZNHMFGJXUPJ32X/
Code of Conduct:http://python.org/psf/codeofconduct/___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/J5LE3OPM2GTT3N7BYJTBZDDYYBXQ34Z7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Paul Bryan]

You've proposed a "what", but I don't see a "why".

Indeed, it will break some code.

I've been (currently legally) expressing __slots__ as sets, which is
arguably more consistent with its purpose, and in testing appeared to
perform better than tuples.

So, I would request that you amend the allowed types to include sets.

Also, people are using dicts to provide docstrings on attributes, so
that would need to be addressed as well. 

On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
> 18.03.22 11:29, Serhiy Storchaka пише:
> > It will break some code (there are 2 occurrences in the stdlib an 1
> > in 
> > scripts), but that code can be easily fixed.
> 
> Actually it will break more code, because initializing __slots__ with
> a 
> list is pretty common. Maybe restrict it to tuple or list? But having
> an 
> immutable __slots__ may be more reliable.
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Guido van Rossum]

The motivation has been explained already.

What on earth did your test do that got a speedup by using sets? Was it
repeatedly checking whether a variable was in a slot? The other thing this
does is rearrange the order in which slots appear from run to run (since
set order is affected by hash randomization) and you might have gotten
lucky with a popular attribute being moved to the front, where it's more
likely to be in the memory cache already (cache lines being 64 bytes and
pointers being 8 bytes nowadays).

I agree that dicts are a use case to preserve.

On Fri, Mar 18, 2022 at 08:59 Paul Bryan  wrote:

> You've proposed a "what", but I don't see a "why".
>
> Indeed, it will break some code.
>
> I've been (currently legally) expressing __slots__ as sets, which is
> arguably more consistent with its purpose, and in testing appeared to
> perform better than tuples.
>
> So, I would request that you amend the allowed types to include sets.
>
> Also, people are using dicts to provide docstrings on attributes, so that
> would need to be addressed as well.
>
> On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
>
> 18.03.22 11:29, Serhiy Storchaka пише:
>
> It will break some code (there are 2 occurrences in the stdlib an 1 in
> scripts), but that code can be easily fixed.
>
>
> Actually it will break more code, because initializing __slots__ with a
> list is pretty common. Maybe restrict it to tuple or list? But having an
> immutable __slots__ may be more reliable.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZMH4DECXV3AF5M3BFVHEEMF7FE6FLU6H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Paul Bryan]

On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:
> The motivation has been explained already.

In this thread?

> What on earth did your test do that got a speedup by using sets? Was
> it repeatedly checking whether a variable was in a slot? The other
> thing this does is rearrange the order in which slots appear from run
> to run (since set order is affected by hash randomization) and you
> might have gotten lucky with a popular attribute being moved to the
> front, where it's more likely to be in the memory cache already
> (cache lines being 64 bytes and pointers being 8 bytes nowadays).

I created objects in a tight loop, populating attributes, noting the
elapsed time.

> I agree that dicts are a use case to preserve.
> 
> On Fri, Mar 18, 2022 at 08:59 Paul Bryan  wrote:
> > You've proposed a "what", but I don't see a "why".
> > 
> > Indeed, it will break some code.
> > 
> > I've been (currently legally) expressing __slots__ as sets, which
> > is arguably more consistent with its purpose, and in testing
> > appeared to perform better than tuples.
> > 
> > So, I would request that you amend the allowed types to include
> > sets.
> > 
> > Also, people are using dicts to provide docstrings on attributes,
> > so that would need to be addressed as well. 
> > 
> > On Fri, 2022-03-18 at 11:42 +0200, Serhiy Storchaka wrote:
> > > 18.03.22 11:29, Serhiy Storchaka пише:
> > > > It will break some code (there are 2 occurrences in the stdlib
> > > > an 1 in 
> > > > scripts), but that code can be easily fixed.
> > > 
> > > Actually it will break more code, because initializing __slots__
> > > with a 
> > > list is pretty common. Maybe restrict it to tuple or list? But
> > > having an 
> > > immutable __slots__ may be more reliable.
> > > 
> > > ___
> > > Python-Dev mailing list -- python-dev@python.org
> > > To unsubscribe send an email to python-dev-le...@python.org
> > > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > > Message archived at
> > > https://mail.python.org/archives/list/python-dev@python.org/message/HCZHJN2LSD2NXFLSFAO7VVOMEZRTLDBQ/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
> > 
> > 
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-dev@python.org/message/6AKHUOVUQ2SQRPE4HAGWAEW2VYRKPFCL/
> > Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YL2SX4TOFSE6U77C6VXEGPERN4V7WVW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Raymond Hettinger]

> I propose to restrict the type of __slots__.

-1 for adding a restriction.  This breaks code for no good reason.  This
API has been around for a very long time.  I've seen lists, tuples, dicts,
single strings, and occasionally something more exotic.  Why wreck stable
code?

Also, the inspect module will detect whether __slots__ is a dictionary and
will use it to display docstrings.  In the database world, data
dictionaries have proven value, so it would be a bummer to kill off this
functionality which is used in much the same way as docstrings for
properties.  It is still rarely used, but I'm hoping it will catch on (just
like people are slowly growing more aware that they can add docstringa to
fields in named tuples).

Raymond



On Fri, Mar 18, 2022 at 4:33 AM Serhiy Storchaka 
wrote:

> Currently __slots__ can be either string or an iterable of strings.
>
> 1. If it is a string, it is a name of a single slot. Third-party code
> which iterates __slots__ will be confused.
>
> 2. If it is an iterable, it should emit names of slots. Note that
> non-reiterable iterators are accepted too, but it causes weird bugs if
> __slots__ is iterated more than once. For example it breaks default
> pickling and copying.
>
> I propose to restrict the type of __slots__. Require it always been a
> tuple of strings. Most __slots__ in real code are tuples. It is rarely
> we need only single slot and set __slots__ as a string.
>
> It will break some code (there are 2 occurrences in the stdlib an 1 in
> scripts), but that code can be easily fixed.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E5ROGDNKI5FFPTXBQGHUQSVVHCAB7VUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Steve Dower]

On 3/18/2022 2:38 PM, Eric V. Smith wrote:
There a practical need for these changes. See 
https://bugs.python.org/issue46382 for a case where dataclasses needs 
__slots__ to be iterated over after the class has been created. And it 
would be good if __slots__ accurately reflected the slots that were 
actually created.


It seems totally sufficient for dataclasses to require that base class 
__slots__ are a string or iterables of strings. Which is apparently what 
would happen today, since anything else would cause incorrect behaviour.


A single special case doesn't have to become a language-wide backwards 
compatibility break, even if it perhaps would've been better to have had 
the restriction from the start.


Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R5PBNN36BMUM72QPRJG4DAHSD6UKUY3O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2022-03-11 - 2022-03-18)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7165 (-68)
  closed 51620 (+139)
  total  58785 (+71)

Open issues with patches: 2903 


Issues opened (50)
==

#22628: Idle: Tree lines are spaced too close together.
https://bugs.python.org/issue22628  reopened by exarkun

#43253: asyncio open_connection fails when a socket is explicitly clos
https://bugs.python.org/issue43253  reopened by asvetlov

#45405: configure fails on macOS with non-Apple clang version 13 which
https://bugs.python.org/issue45405  reopened by ned.deily

#46948: [CVE-2022-26488] Escalation of privilege via Windows Installer
https://bugs.python.org/issue46948  reopened by steve.dower

#46989: signal.signal, et al, doesn't support [SIGRTMIN,SIGRTMAX] on F
https://bugs.python.org/issue46989  opened by ngie

#46990: Surprising list overallocation from .split()
https://bugs.python.org/issue46990  opened by tim.peters

#46992: If use textwrap.dedent with string formatting, may get uninten
https://bugs.python.org/issue46992  opened by xncbf12

#46997: Invalid memory write in bytearray
https://bugs.python.org/issue46997  opened by JelleZijlstra

#46998: Allow subclassing Any at runtime
https://bugs.python.org/issue46998  opened by hauntsaninja

#46999: test_multiprocessing_fork running without any timeout
https://bugs.python.org/issue46999  opened by doko

#47000: Make encoding="locale" uses locale encoding even in UTF-8 mode
https://bugs.python.org/issue47000  opened by methane

#47002: argparse - "expected one argument" when used -: in argument
https://bugs.python.org/issue47002  opened by Pythass

#47006: PEP 646: Decide on substitution behavior
https://bugs.python.org/issue47006  opened by JelleZijlstra

#47007: [doc] str docs are inconsistent with special method lookup
https://bugs.python.org/issue47007  opened by itsvs

#47009: Streamline list.append for the common case
https://bugs.python.org/issue47009  opened by Dennis Sweeney

#47010: Implement zero copy writes in SelectorSocketTransport in async
https://bugs.python.org/issue47010  opened by kumaraditya303

#47011: Cloned turtle pen is not cleared completely
https://bugs.python.org/issue47011  opened by learncoding

#47012: Speed up iteration of bytes and bytearray
https://bugs.python.org/issue47012  opened by kumaraditya303

#47013: test_bdb and test_distutils fail on installed Python 3.9, 3.10
https://bugs.python.org/issue47013  opened by vstinner

#47014: ProactorEventLoop ignores Ctrl+C after closing unrelated loop
https://bugs.python.org/issue47014  opened by mhils

#47015: Update tests from asyncore to asyncio
https://bugs.python.org/issue47015  opened by arhadthedev

#47016: Create a test verifying bundled pip and setuptools wheels
https://bugs.python.org/issue47016  opened by illia-v

#47017: frozen modules are on by default in dev build
https://bugs.python.org/issue47017  opened by gvanrossum

#47019: Fatal Python Error in sqlite3 Python 3.10
https://bugs.python.org/issue47019  opened by hydroflask

#47021: Add separate match and case doc to pydoc
https://bugs.python.org/issue47021  opened by duckboycool

#47022: PEP 594: Document removal of asynchat, asyncore and smtpd
https://bugs.python.org/issue47022  opened by hugovk

#47025: bytes do not work on sys.path
https://bugs.python.org/issue47025  opened by graingert

#47026: BytesWarning in zipimport paths on sys.path
https://bugs.python.org/issue47026  opened by graingert

#47027: subprocess.run(), subprocess.Popen() should accept file descri
https://bugs.python.org/issue47027  opened by ydroneaud

#47029: Fix a BrokenPipeError when a multiprocessing.Queue is garbage 
https://bugs.python.org/issue47029  opened by maggyero

#47030: singledispatch does not work with positional arguments with de
https://bugs.python.org/issue47030  opened by randolf.scholz

#47031: math.nan should note that NANs do not compare equal to anythin
https://bugs.python.org/issue47031  opened by steven.daprano

#47037: Build problems on Windows
https://bugs.python.org/issue47037  opened by terry.reedy

#47040: Remove invalid versionchanged in doc
https://bugs.python.org/issue47040  opened by malin

#47043: Argparse can't parse subparsers with parse_known_args
https://bugs.python.org/issue47043  opened by rive-n

#47045: Remove the RESUME instruction
https://bugs.python.org/issue47045  opened by Mark.Shannon

#47046: Add `f_state` attribute to FrameObjects.
https://bugs.python.org/issue47046  opened by Mark.Shannon

#47047: smtplib: allow custom policy or use msg.policy in send_message
https://bugs.python.org/issue47047  opened by Miksus

#47048: Python 3.10.3 + Osx Lion : fatal error (make) signalmodule or 
https://bugs.python.org/issue47048  opened by laurentang001

#47049: Incorrect shutil.copytree() behaviour with symlinks
https://bugs.python.org/issue

[Python-Dev] Re: Restrict the type of __slots__

[Guido van Rossum]

On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan  wrote:

> On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:
>
> The motivation has been explained already.
>
>
> In this thread?
>

Yes, Eric's message.


> What on earth did your test do that got a speedup by using sets? Was it
> repeatedly checking whether a variable was in a slot? The other thing this
> does is rearrange the order in which slots appear from run to run (since
> set order is affected by hash randomization) and you might have gotten
> lucky with a popular attribute being moved to the front, where it's more
> likely to be in the memory cache already (cache lines being 64 bytes and
> pointers being 8 bytes nowadays).
>
>
> I created objects in a tight loop, populating attributes, noting the
> elapsed time.
>

It does not make sense that that is correlated to the type of __slots__,
since __slots__ is not used for instance creation at all (it is only used
to create the class). I stick to my likely explanation.

Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on
disallowing things that can't be reiterated (but it's not a problem in
practice). Given other responses the status quo is likely best.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EYZ32GBU4QUTRPU26BDCYYMKG4GX633N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Eric V. Smith]

On 3/18/2022 4:58 PM, Guido van Rossum wrote:

On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan  wrote:

On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:

The motivation has been explained already.


In this thread?


Yes, Eric's message.


What on earth did your test do that got a speedup by using sets?
Was it repeatedly checking whether a variable was in a slot? The
other thing this does is rearrange the order in which slots
appear from run to run (since set order is affected by hash
randomization) and you might have gotten lucky with a popular
attribute being moved to the front, where it's more likely to be
in the memory cache already (cache lines being 64 bytes and
pointers being 8 bytes nowadays).


I created objects in a tight loop, populating attributes, noting
the elapsed time.


It does not make sense that that is correlated to the type of 
__slots__, since __slots__ is not used for instance creation at all 
(it is only used to create the class). I stick to my likely explanation.


Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on 
disallowing things that can't be reiterated (but it's not a problem in 
practice). Given other responses the status quo is likely best.


The PR for the issue I mentioned (https://bugs.python.org/issue46382) 
allows strings and iterables (but not iterators). And it uses a match 
statement, no less! I think that's good enough for dataclasses.


Eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BS2RRX62SHQDTM5O24WKAANPNHKXMG6F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Restrict the type of __slots__

[Alex Waygood]

I'm +1 on disallowing strings specifically. The unexpected behaviour that 
ensues if you try to iterate over a class's slots is a footgun that I've 
trodden on a few times, and it's always been annoying.

But I don't see any particular reason to disallow any other kind of iterable, 
and I'm definitely -1 on disallowing using a dictionary for __slots__. Using a 
dictionary for __slots__ as a way to document attributes is a feature I very 
much like.

Best,
Alex

> On 18 Mar 2022, at 20:59, Guido van Rossum  wrote:
> 
> 
>> On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan  wrote:
>>> On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote:
>>> The motivation has been explained already.
>> 
>> In this thread?
> 
> Yes, Eric's message.
>  
>>> What on earth did your test do that got a speedup by using sets? Was it 
>>> repeatedly checking whether a variable was in a slot? The other thing this 
>>> does is rearrange the order in which slots appear from run to run (since 
>>> set order is affected by hash randomization) and you might have gotten 
>>> lucky with a popular attribute being moved to the front, where it's more 
>>> likely to be in the memory cache already (cache lines being 64 bytes and 
>>> pointers being 8 bytes nowadays).
>> 
>> I created objects in a tight loop, populating attributes, noting the elapsed 
>> time.
> 
> It does not make sense that that is correlated to the type of __slots__, 
> since __slots__ is not used for instance creation at all (it is only used to 
> create the class). I stick to my likely explanation.
> 
> Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on 
> disallowing things that can't be reiterated (but it's not a problem in 
> practice). Given other responses the status quo is likely best.
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/EYZ32GBU4QUTRPU26BDCYYMKG4GX633N/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PO32SWLW27Y2MUWROXD7UUPTUTXTDEEE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New PEP website is horrible to read on mobile device

[Nick Coghlan]

On Thu, 17 Mar 2022, 10:29 am Inada Naoki,  wrote:

> I can reproduce it. I reported it on
> https://github.com/python/peps/issues/2437


Summarising the issues identified there for the thread: the gist is that
some elements in some PEPs (mainly tables and code blocks) could result in
the initial rendering width being wider than the initial view port size,
hence having to zoom out to see the full text.

The styling of affected elements is being adjusted so that mobile browsers
are better able to shrink them to fit on a phone screen.

Cheers,
Nick.


> Cheers
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NBZWV43XXS67LEQ44SAHUUTQK36KP3IY/
Code of Conduct: http://python.org/psf/codeofconduct/