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
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
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
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
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
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
> 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
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
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
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
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
> 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.
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
> 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
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
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,
16 matches
Mail list logo
