[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Serhiy Storchaka]

07.06.21 06:05, Inada Naoki пише:
> Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted
> DeprecationWarning when
> '#' format is used without PY_SSIZE_T_CLEAN defined.
> In Python 3.10, they raise a RuntimeError, not a warning. Extension
> modules can not use '#' format with int.
> 
> So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
> Extension modules can use '#' format with ssize_t, without
> PY_SSIZE_T_CLEAN defined.
> 
> Or should we wait one more version?

Many users still use 3.6 or 3.7. Jumping from 3.7 to 3.11 could break
extensions in bad way (crash, truncated data, leaked sensitive
information, execution of arbitrary code). Also, deprecation warnings in
3.8 and 3.9 can be easily ignored.

I propose to wait until both of conditions became true:

* 3.7 no longer maintained
* 3.10 reaches security-only mode.

___
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/UXJAG63XCVRUC4ENDF7V2Q6FLLBFWM2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GDB not breaking at the right place

[Skip Montanaro]

>
> I'm having a hard time debugging some virtual machine code because GDB
> won't break where it's supposed to.
>

A quick follow-up. The GDB folks were able to reproduce this in an XUbuntu
20.04 VM. I don't know if they tried straight Ubuntu, but as the main
difference between the two is the user interface it seems likely the bug
might surface there as well.

The use of a VM thus provides another option as a workaround for me, though
my simple-minded label-to-line number script works as well.

Skip

>
___
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/W5PHGSKBDCWWLOFNUYFX3USO4OSWHIIS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Nick Coghlan]

On Fri, 4 Jun 2021, 4:17 am Gregory P. Smith,  wrote:

> Overall agreement. Your list of ast and code objects and bytecode
> instructions are things that I'd _hope_ people already consider unstable so
> declaring them as such just makes sense if we're not doing that already.
>

Another example of a public API that explicitly declares itself unstable is
"ssl.get_default_context()" (along with any TLS-enabled API that uses it).
It was made that way so the default TLS settings could evolve with the
times, even on maintenance branches. The secrets module has a similar
caveat on its default token lengths (i.e. making them longer is considered
an acceptable API change - if consuming code can't handle that for some
reason, it should set an explicit length).

The metaprogramming APIs for customisation of class creation also arguably
qualify - we've previously imposed new obligations on metaclass developers
as a consequence of adding features like zero-arg super() and the
descriptor naming hooks.

It occurs to me that PEP 387 (the backwards compatibility policy) should
probably mention that these formally unstable APIs exist, and link to a
page in the standard library docs that:

* references the formally unstable APIs
* specifies the points where potentially incompatible changes are allowed
(normally new feature releases, but the default SSL/TLS context definition
may change in maintenance releases if necessary)

Cheers,
Nick.



>
>
___
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/VQFAP6PVIO7HPN6JFBASECH6R67DHL37/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Senthil Kumaran]

On Sun, Jun 06, 2021 at 04:07:57PM -0700, Dan Stromberg wrote:
> I've got a comparison of sort algorithms in both Cython and Pure Python (your
> choice) at:
> https://stromberg.dnsalias.org/~strombrg/sort-comparison/ 
> ...including a version of timsort that is in Cython or Pure Python.
> 

Interesting! timsort get's to near-linear in your benchmark.

-- 
Senthil
___
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/PK2CURNB67WNDEQJQISAYNGRMB4BQ26N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Antoine Pitrou]

On Mon, 7 Jun 2021 06:49:24 -0700
Senthil Kumaran  wrote:
> On Sun, Jun 06, 2021 at 04:07:57PM -0700, Dan Stromberg wrote:
> > I've got a comparison of sort algorithms in both Cython and Pure Python 
> > (your
> > choice) at:
> > https://stromberg.dnsalias.org/~strombrg/sort-comparison/ 
> > ...including a version of timsort that is in Cython or Pure Python.
> >   
> 
> Interesting! timsort get's to near-linear in your benchmark.

O(n log n) always looks linear when n is small enough...

Regards

Antoine.


___
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/XU6JHUNZXPLG443Z62NFPXCJKGHLLLG4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Kyle Stanley]

On Sun, Jun 6, 2021 at 7:09 PM Dan Stromberg  wrote:

> I've got a comparison of sort algorithms in both Cython and Pure Python
> (your choice) at:
> https://stromberg.dnsalias.org/~strombrg/sort-comparison/
> ...including a version of timsort that is in Cython or Pure Python.
>

Thanks for sharing the graphs. I found the performance of radix sort in
particular to be interesting to see mapped out visually, and have never
heard of "shellsort" prior to now. :)
___
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/BVHSMLAOJKVDXJO37LF5WY7OEM6D5YWX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: March Steering Council update.

[Thomas Wouters]

On Tue, May 18, 2021 at 4:27 PM Nick Coghlan  wrote:

> Thanks for the update!
>
> I know this request is a little ironic coming from me, but would it be
> possible to state the PEP titles the first time they're mentioned each
> month?
>

Yep. I usually do this, not sure why I forgot this time. The update was
updated.


>
> Cross referencing is a little awkward when reading the summary on a phone
> rather than a full computer.
>
> Cheers,
> Nick.
>
> On Tue, 18 May 2021, 11:12 pm Thomas Wouters,  wrote:
>
>>
>> The SC has just published the community update for March:
>>
>>
>> https://github.com/python/steering-council/blob/main/updates/2021-03-steering-council-update.md
>>
>> We're still trying to get these done every month, but between the rush of
>> PEPs and other issues before the 3.10b1 deadline, and PyCon US, we're
>> delayed a little. (The April update hopefully won't be too long.) In the
>> meantime, the SC keynote from PyCon US covers our longer-term plans and our
>> points of view on a few other subjects, and that will hopefully be up on
>> YouTube (
>> https://www.youtube.com/playlist?list=PL2Uw4_HvXqvYk1Y5P8kryoyd83L_0Uk5K)
>> soon. (Since it's mentioned in the notes below, I just want to point out
>> that we didn't record on April 19th; it was pushed back to May 3rd, the
>> same day 3.10b1 was cut.)
>>
>> March 1
>>
>>- Steering Council synced up on the rejection draft for PEP 651.
>>Group discussed the importance of conveying that all aspects of the
>>proposal were reviewed and the decision is a holistic one. Group will
>>continue working on the draft and will sync up via Slack during the week 
>> so
>>it can be sent out.
>>- The Steering Council discussed PEP 648. Barry created a doc and the
>>group will consolidate feedback+questions into this document. Then the
>>Steering Council will post this on Discourse as well as to python-dev@
>>.
>>- The Steering Council extensively discussed PEP 637. The group
>>decided that it would reject the PEP based on the PEPs costs not being
>>worth the benefits.
>>- The Steering Council also discussed typing in general and who
>>should own it.
>>- Next week the SC will vote on the Documentation Work Group's
>>charter.
>>
>>
>> March
>> 8
>>
>>- The Steering Council discussed Mark's response to the rejection of
>>PEP 651.
>>- The group also discussed the notification for PEP 637.
>>- The group approved PEP 624 & PEP 597.
>>- The Steering Council discussed PEP 644 and decided further
>>communication was needed with Christian.
>>- The Steering Council voted on and approved the Documentation Work
>>Group.
>>- The group discussed moving master to main and decided it needed to
>>be done. The SC discussed communication around this change.
>>
>>
>> March
>> 15
>>
>>- Thomas updated the notifications for PEP 597, PEP 624 and PEP 637,
>>and sent out the notifications March 15th.
>>- Group checked in on the draft for PEP 648. Thomas has more text to
>>add to it.
>>- The Steering Council discussed what kind of presentation they will
>>give at PyCon US. The group decided on a combination of presentation and
>>Q&A. Team is working on an outline. SC members were also reminded to
>>register for PyCon US, and encourage others to do so.
>>- Barry proposed to the SC that they create a Work Group with a
>>subset of the Python Security Response Team members and that group can 
>> help
>>scope the future of the PSRT group. Everyone is fine with this.
>>- Steering Council discussed code of conduct situations around
>>changing master to main. The group decided on a warning to S.D. that
>>will be sent as a warning to all. Thomas is working on the initial draft.
>>
>>
>> March
>> 22
>>
>>- Barry and Thomas checked-in on PEP 648's draft response, they will
>>be sending it out soon.
>>- The SC reviewed PEP 644 more. Pablo raised a concern around users
>>that can be in an env without OpenSSL 1.1.1 or newer and then not being
>>able to use wheels. Pablo will email Christian to get clarification and
>>will keep the SC informed.
>>- Steering Council discussed their keynote at PyCon US 2021. They
>>would like to gather questions from the community. Ewa will create a 
>> Slido,
>>which will be live from April 5 to 11th. SC will review questions on the
>>12th. The current plan is to record on April 19th.
>>- Steering Council discussed the response to Debian. Carol's done
>>with her draft. Pablo is going to take a look at it to see if anything 
>> else
>>needs to be added.

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Hai Shi]

> So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
> Extension modules can use '#' format with ssize_t, without
> PY_SSIZE_T_CLEAN defined.
> Or should we wait one more version?

Hi, Inada,
I suggest we should wait until at least Python 3.12 or Python 4.0.

There have an another question. There have many C API defined under 
PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT().
Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?
___
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/MWMH6FWHJUUKI7OKBQR7OJJ6MZV6J35P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] My help with yours IDLE

[MatroCholo]

Dear Python Developers,
I have found that default IDLE can't open .py files on double click and
IDLE isn't shown in "Open with" menu. I have solved this problem by
converting idle.bat in \lib\idlelibs\ into .exe file.
If you are interested in my help, you can learn more in my GitHub repo -
https://github.com/MatroCholo/idle2exe
Thanks for your extremely helpful attention to this matter.
Yours faithfully, MatroCholo
___
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/AZSWYNWIZYOLIQQ4QPV4TSR5DRUV2KMX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Ethan Furman]

On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
> On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:

>> In Math / CompSci there is a definition that almost exactly matches this: 
Exact Cover -
>> https://en.wikipedia.org/wiki/Exact_cover
>>
>> The difference is that, IIRC, solving the problem is finding and removing 
all subsets that are unneeded to create an
>> exact cover, so it's kind of arriving at it from a different direction, but 
'exact cover' definition itself is a good
>> match.
>
> I’m not sure it’s a quite the same - it doesn’t require that the sets in the 
cover have cardinality 1, which I think
> Ethan does.

Well, I'm not sure what "cardinality 1" means, so I don't know if I do or not.  
:)

--
~Ethan~
___
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/BMCG6MA3HKYAQC4JARJFXZDOZGCSIPMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Andrei Kulakov]

On Mon, Jun 7, 2021 at 1:36 PM Ethan Furman  wrote:

> On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
>  > On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>
>  >> In Math / CompSci there is a definition that almost exactly matches
> this: Exact Cover -
>  >> https://en.wikipedia.org/wiki/Exact_cover
>  >>
>  >> The difference is that, IIRC, solving the problem is finding and
> removing all subsets that are unneeded to create an
>  >> exact cover, so it's kind of arriving at it from a different
> direction, but 'exact cover' definition itself is a good
>  >> match.
>  >
>  > I’m not sure it’s a quite the same - it doesn’t require that the sets
> in the cover have cardinality 1, which I think
>  > Ethan does.
>
> Well, I'm not sure what "cardinality 1" means, so I don't know if I do or
> not.  :)
>
>
> It means each bit flag has only one bit set. In the 'exact cover'
definition, that's not a requirement (if it were, it would
make the problem too trivial to solve).

I also want to mention that 'exact cover' seems a very direct, easy to
remember name also for users who are not
familiar with the Math definition..

 -andrei
___
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/MZTPKDWUE47ZXJKN6BISFCJ5RZ5XSOS5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Irit Katriel via Python-Dev]

Andrei is suggesting to look at each enum value as the set of "bits set to
1" in this value, and then apply a set-thoery term to the problem. A set of
"cardinality 1" in this context is an enum value with only one "1", what
you called canonical. The condition you defined is that any bit that is set
anywhere, is also in a canonical value.  Anyway, I don't know whether this
kind of terminology is widely accessible.

Maybe you could use something like @composite. As in, every non-canonical
value in the enum is the composition of canonical values.


On Mon, Jun 7, 2021 at 6:36 PM Ethan Furman  wrote:

> On 6/6/21 9:14 AM, Irit Katriel via Python-Dev wrote:
>  > On 6 Jun 2021, at 16:58, Andrei Kulakov wrote:
>
>  >> In Math / CompSci there is a definition that almost exactly matches
> this: Exact Cover -
>  >> https://en.wikipedia.org/wiki/Exact_cover
>  >>
>  >> The difference is that, IIRC, solving the problem is finding and
> removing all subsets that are unneeded to create an
>  >> exact cover, so it's kind of arriving at it from a different
> direction, but 'exact cover' definition itself is a good
>  >> match.
>  >
>  > I’m not sure it’s a quite the same - it doesn’t require that the sets
> in the cover have cardinality 1, which I think
>  > Ethan does.
>
> Well, I'm not sure what "cardinality 1" means, so I don't know if I do or
> not.  :)
>
> --
> ~Ethan~
> ___
> 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/BMCG6MA3HKYAQC4JARJFXZDOZGCSIPMM/
> 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/2OKVXULZMCEMWUNAMT4ENQVQP2JBSLDV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Tim Peters]

[Dan Stromberg ]
> ...
> Timsort added the innovation of making mergesort in-place, plus a little
> (though already common) O(*n^2) sorting for small sublists.

Actually, both were already very common in mergesorts. "timsort" is
much more a work of engineering than of insight ;-) That is, it
combined many pre-existing ideas, but pushed them hard, and got them
to work smoothly together.

The most novel part is "galloping" to vastly cut the number of
comparisons needed in many real-world cases of partially ordered
inputs. I took that idea from (as briefly explained in listsort.txt)
papers seeking to speed real-life unions and intersections of sorted
lists, presumably in database implementations.  I later discovered
that the idea had already been applied to a mergesort, as noted in a
paper by McIlroy (cited in listsort.txt) - but the paper didn't give
any details, and best I can tell he never published his code.

WIthout that, timsort wouldn't have been worth the bother of writing -
it was generally no faster than Python's prior sort implementation on
randomly-ordered inputs, and is quite a large pile of code.  But many
cases of real-world inputs do have significant pre-existing order of
some kind, where even a "perfect" quicksort (always picks _the_ median
as the partition pivot) remains O(n log n) but timsort O(n).

Curiously, though, it was the only implementation ever tried of a
mergesort-based algorithm that wasn't notably _slower_ on
randomly-ordered inputs than Python's prior "samplesort" algorithm
(like quicksort but with a very high-quality guess for the median
element based on recursively sample-sorting a largish random sample).
___
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/Y22TRSA5I4JCNC6GRBX7QZYF4MLGPCYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Dan Stromberg]

On Mon, Jun 7, 2021 at 11:20 AM Tim Peters  wrote:

> [Dan Stromberg ]
> > ...
> > Timsort added the innovation of making mergesort in-place, plus a little
> > (though already common) O(*n^2) sorting for small sublists.
>
> Actually, both were already very common in mergesorts. "timsort" is
> much more a work of engineering than of insight ;-) That is, it
> combined many pre-existing ideas, but pushed them hard, and got them
> to work smoothly together.
>
> The most novel part is "galloping" to vastly cut the number of
> comparisons needed in many real-world cases of partially ordered
> inputs.
>

Thanks Tim.

Python itself is a great language, but in part it was your good-natured and
well-reasoned posts about Python that got me into Python instead of OCaml.
___
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/7K6WWWAYEGRNQOW47DQE45FFNSKZSG7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My help with yours IDLE

[Terry Reedy]

On 6/7/2021 12:20 PM, MatroCholo wrote:

Dear Python Developers,
I have found that default IDLE can't open .py files on double click


After installing with the python.org Windows installer, double-clicking 
x.py should run x.py with the default python.  It does for me.  The file 
should be designed for this to make much sense.



and IDLE isn't shown in "Open with" menu.


It should be shown in the Edit with IDLE menu.  For me, 3.10 is, 3.9 is 
not.  There might be a tracker issue for this.  IDLE is a development 
and learning environment, so running from the editor is usually the best 
way to run in Python.


I have solved this problem by 
converting idle.bat in \lib\idlelibs\ into .exe file.


The fact that one can only 'open' (run) with a .exe and not a .bat file 
has come up on a bugs.python.org tracker issue.


If you are interested in my help, you can learn more in my GitHub repo - 
https://github.com/MatroCholo/idle2exe 


I don't read Russian, so the readme is not useful to me.

If you want to discuss IDLE development more, in English, post on the 
idle-dev mailing list.


--
Terry Jan Reedy

___
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/UZK2M7MZTCB5ZK5OSVTVQRD2POV37RKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Inada Naoki]

On Mon, Jun 7, 2021 at 4:52 PM Serhiy Storchaka  wrote:
>
> Many users still use 3.6 or 3.7. Jumping from 3.7 to 3.11 could break
> extensions in bad way (crash, truncated data, leaked sensitive
> information, execution of arbitrary code). Also, deprecation warnings in
> 3.8 and 3.9 can be easily ignored.
>
> I propose to wait until both of conditions became true:
>
> * 3.7 no longer maintained
> * 3.10 reaches security-only mode.
>

Makes sense.

Python 3.7 will get security fix until 2023-06.
https://www.python.org/dev/peps/pep-0537/#and-beyond-schedule

Python 3.12 will be released at 2023-10.
So we can change PY_SSIZE_T_CLEAN by default from 3.12.

Regards,

-- 
Inada Naoki  
___
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/QZSSHINMXXZ4I3ODPDFPGFC7MBSKIOVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Inada Naoki]

On Tue, Jun 8, 2021 at 12:53 AM Hai Shi  wrote:
>
> > So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
> > Extension modules can use '#' format with ssize_t, without
> > PY_SSIZE_T_CLEAN defined.
> > Or should we wait one more version?
>
> Hi, Inada,
> I suggest we should wait until at least Python 3.12 or Python 4.0.
>

Serhiy and you suggest Python 3.12 and I agree with it.
Thank you for your reply.

> There have an another question. There have many C API defined under 
> PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT().
> Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?

They are part of stable ABIs. So we can remove/merge them at Python 4.0.

Regards,
-- 
Inada Naoki  
___
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/KNA7KVN6ZIBXWASUAJQRGT6OPCBDULFW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Stephen J. Turnbull]

Irit Katriel via Python-Dev writes:

 > Andrei is suggesting to look at each enum value as the set of "bits set to
 > 1" in this value, and then apply a set-thoery term to the problem.
 > [...]  Anyway, I don't know whether this kind of terminology is
 > widely accessible.

I think the everyday meaning of "cover" is close enough to the set
theory meaning that only set theorists can be confused.  (Not a joke,
because I'm not sure exactly what Ethan intends.)  I'm not sure
"exact_cover" or "complete_cover" or similar are good names, but
they're as good as any I've seen so far.

 > Maybe you could use something like @composite. As in, every non-canonical
 > value in the enum is the composition of canonical values.

-1 on "composite".  "Compose" has other, more important meanings, and
isn't very suggestive of this kind of factorization, to me at least.

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/OZOEOD3OT76OSWJ5ZZ4Y4X4JSYWCG4ZS/
Code of Conduct: http://python.org/psf/codeofconduct/