[Python-Dev] Re: PEP 661: Sentinel Values

2021-06-06 Thread Kyle Stanley
 As someone who's had to make use of the pattern `_sentinel = object()` a
few times within stdlib code, I'd like to give a strong +1 for the proposal
to add a new `sentinel()` function. This is much more intuitive, easier to
look up, etc. From my experience, it's a common enough pattern to be well
worth the addition.

Thanks for the proposal, Tal. :)

On Sun, Jun 6, 2021 at 4:14 AM Tal Einat  wrote:

> Hi,
>
> I have prepared a PEP proposing adding a stdlib function for defining
> sentinel values. You can find the PEP here:
>
> https://www.python.org/dev/peps/pep-0661/
>
> The discussion is happening in the discourse server:
>
> https://discuss.python.org/t/pep-661-sentinel-values/9126
>
> To avoid splitting the discussion, *please redirect your comments there*
> instead of replying to this thread.
>
> Have a nice week,
> - Tal Einat
> ___
> 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/3QNLVLSMVSQ5MGLXRIQ5QM4BA5OJCVEN/
> 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/UM7EPUUSQPJAEU6QCA3FUOH3ULNUSXGV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-06 Thread Inada Naoki
Hi, folks,

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?

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


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

2021-06-06 Thread Dan Stromberg
On Sun, Jun 6, 2021 at 2:46 AM Marco Sulla 
wrote:

> As title. Is it faster for inplace sorting, or simply the
> implementation of list.sort() was done before the implementation of
> timsort?
>

As you already know, timsort is pretty close to merge sort.

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

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.

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


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

2021-06-06 Thread Irit Katriel via Python-Dev

> 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.
And the ‘exact’ requirement (that each bit is covered once) surely doesn’t 
apply.

It’s more like “full cover by singletons”.

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


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

2021-06-06 Thread Andrei Kulakov
On Thu, May 27, 2021 at 11:31 PM Ethan Furman  wrote:

> Greetings!
>
> The Flag type in the enum module has had some improvements, but I find it
> necessary to move one of those improvements
> into a decorator instead, and I'm having a hard time thinking up a name.
>
> What is the behavior?  Well, a name in a flag type can be either canonical
> (it represents one thing), or aliased (it
> represents two or more things).  To use Color as an example:
>
>  class Color(Flag):
>  RED = 1# 0001
>  GREEN = 2  # 0010
>  BLUE = 4   # 0100
>  PURPLE = RED | BLUE# 0101
>  WHITE = RED | GREEN | BLUE # 0111
>
> The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE
> are aliases for certain flag combinations.  But
> what if we have something like:
>
>  class Color(Flag):
>  RED = 1# 0001
>  BLUE = 4   # 0100
>  WHITE = 7  # 0111
>
> As you see, WHITE is an "alias" for a value that does not exist in the
> Flag (0010, or 2).  That seems like it's probably
> an error.  But what about this?
>
>  class FlagWithMasks(IntFlag):
>  DEFAULT = 0x0
>
>  FIRST_MASK = 0xF
>  FIRST_ROUND = 0x0
>  FIRST_CEIL = 0x1
>  FIRST_TRUNC = 0x2
>
>  SECOND_MASK = 0xF0
>  SECOND_RECALC = 0x00
>  SECOND_NO_RECALC = 0x10
>
>  THIRD_MASK = 0xF00
>  THIRD_DISCARD = 0x000
>  THIRD_KEEP = 0x100
>
> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are
> aliasing values that don't exist, but it seems
> intentional and not an error.
>
> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator
> to verify that a Flag has no missing aliased values that can be used when
> the programmer thinks it's appropriate... but
> I have no idea what to call it.
>
> Any nominations?
>
> --
> ~Ethan~
>
>
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.

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


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

2021-06-06 Thread Marco Sulla
On Sun, 6 Jun 2021 at 11:57, Christian Heimes  wrote:
>
> On 06/06/2021 11.42, Marco Sulla wrote:
> > As title. Is it faster for inplace sorting, or simply the
> > implementation of list.sort() was done before the implementation of
> > timsort?
>
> list.sort() uses timsort. What makes you think that Python uses mergesort?

In listobject.c, in the comment above list_sort_impl, there's written
"An adaptive, stable, natural mergesort". But now I see that after
there is "See listsort.txt" where it's stated "This describes an
adaptive, stable, natural mergesort, modestly called timsort".

> Tim Peters invented timsort for Python about twenty years ago. Tim a
> first generation Python core dev. Other languages like Java adopted
> timsort from Python later.

I know. Thank you for the answer :)

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


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

2021-06-06 Thread Steve Holden
On Fri, May 28, 2021 at 10:26 PM Ethan Furman  wrote:

> On 5/28/21 12:43 AM, Petr Viktorin wrote:
>  > On 28. 05. 21 5:24, Ethan Furman wrote:
>
>  >>  class FlagWithMasks(IntFlag):
>  >>  DEFAULT = 0x0
>  >>
>  >>  FIRST_MASK = 0xF
>  >>  FIRST_ROUND = 0x0
>  >>  FIRST_CEIL = 0x1
>  >>  FIRST_TRUNC = 0x2
>  >>
>  >>  SECOND_MASK = 0xF0
>  >>  SECOND_RECALC = 0x00
>  >>  SECOND_NO_RECALC = 0x10
>  >>
>  >>  THIRD_MASK = 0xF00
>  >>  THIRD_DISCARD = 0x000
>  >>  THIRD_KEEP = 0x100
>  >>
>  >> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that
> are aliasing values
>  >> that don't exist, but it seems intentional and not an error.
>  >
>  > Are you looking for a decorator for the whole Enum, or a way to mark
> individual *values* as masks?
>
> The decorator is for whole enum.  The issue is not that some values are
> masks, but whether the absence of named bits
> covered by the mask is an error.
>
> If all masked bits must be defined by individual values then it's a
completely_masked  enum? This is quite a bikeshed we're painting here! ;-)

Kind regards,
Steve


> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OM5M774MP5QPLFXZ7OVGBPR7ZFB6X35A/
>
___
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/QMTTXVEI6TDFBXLT62QZME3S6QT5QZ33/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-06-06 Thread Christian Heimes
On 06/06/2021 11.42, Marco Sulla wrote:
> As title. Is it faster for inplace sorting, or simply the
> implementation of list.sort() was done before the implementation of
> timsort?

list.sort() uses timsort. What makes you think that Python uses mergesort?

Tim Peters invented timsort for Python about twenty years ago. Tim a
first generation Python core dev. Other languages like Java adopted
timsort from Python later.

Christian



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


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

2021-06-06 Thread Marco Sulla
As title. Is it faster for inplace sorting, or simply the
implementation of list.sort() was done before the implementation of
timsort?
___
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/HTSJ7K4GYFZ2P6XUIQYDOTDAGCJDXJH6/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-06-06 Thread Serhiy Storchaka
06.06.21 06:48, Guido van Rossum пише:
> On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner  > wrote:
> If possible, I would prefer to make PyThreadState, PyCodeObject and
> other structures opaque, and only go through getter and setter
> functions ;-) PyCode_New() is another problem :-/ The PEP 570 first
> changed it to add a new parameter. It broke Cython and other projects.
> The change was reverted, and PyCode_NewWithPosOnlyArgs() was added.
> The lesson is that it's possible to change PyCodeObject without
> breaking PyCode_New() (which handles the "backward compatibility" for
> you).
> 
> 
> I'm afraid that won't always be possible though. At some point there
> just may not be a valid meaning for the original PyCode_New() call. It
> was easy in the case of positional arguments (by default don't have any)
> but it may not always be that simple, and we shouldn't make guarantees here.

We have already reached this limit. In 3.11 the code object needs a
table of exception handlers. Only simplest code which do not contain any
"try" or "with" can now be created with old PyCode_New() and
PyCode_NewWithPosOnlyArgs().

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


[Python-Dev] PEP 661: Sentinel Values

2021-06-06 Thread Tal Einat
Hi,

I have prepared a PEP proposing adding a stdlib function for defining
sentinel values. You can find the PEP here:

https://www.python.org/dev/peps/pep-0661/

The discussion is happening in the discourse server:

https://discuss.python.org/t/pep-661-sentinel-values/9126

To avoid splitting the discussion, *please redirect your comments there*
instead of replying to this thread.

Have a nice week,
- Tal Einat
___
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/3QNLVLSMVSQ5MGLXRIQ5QM4BA5OJCVEN/
Code of Conduct: http://python.org/psf/codeofconduct/