[Python-Dev] Re: The repr of a sentinel

[micro codery]

I think that would be the primary motivating factor behind recommending
Ellipsis, it’s already a builtin and we are not likely it to get another
builtin singleton. Ever? But besides that “...” in a function signature,
although maybe looking magical, does immediately call out to the reader
that something special is happening  here. And for beginners who might not
know that three dots are an Ellipsis or what an Ellipsis even is, it would
be fairly easy to internet search “three dots in a function signature” or
even “python def ...” would probably be enough to surface an explanation if
this became somewhat common.
___
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/5WX2WNVXPMRD23M7NYVQWOOOCEH2U774/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Nick Coghlan]

On Fri, 14 May 2021, 1:47 am Stéfane Fermigier,  wrote:

>
>
> On Thu, May 13, 2021 at 8:42 AM Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
>> Actual quote by "a Python Software Foundation fellow and contrib-
>> utor to Python infrastructure projects"
>>
>
> Ah, this is what you were referring to. The document was published 5 years
> ago, so this may or may not reflect the current situation.
>
>
>> What frustrates me most is that we have an all-time high of
>> Python developers and an all-time low on high quality contri-
>> butions.[...] As soon as pivotal developers like Armin Ronacher
>> slow down their churn, the whole community feels it immedi-
>> ately.
>>
>
> That's true, but, AFAIK, Armin was never a direct contributor to CPython
> (confirmed by looking at
> https://github.com/python/cpython/graphs/contributors ) so I guess that's
> another issue.
>


The problems mentioned in the Ford Foundation report definitely aren't
solved, but one of the contributing factors that the PSF identified at the
time was that if core projects like CPython and pypi.org are underfunded,
that poor precedent severely hurts fund raising and other sustainability
efforts in the wider Python ecosystem.

Thus efforts like the "developer in residence" role that the PSF are
currently recruiting for, as well as the increased focus on (and investment
in) ecosystem sustainability from commercial users and redistributors.

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

[Python-Dev] Re: The repr of a sentinel

[Joao S. O. Bueno]

Since the subject is this,
I will note that past week, I resorted twice to create an Enum with a
single element,
and then alias the element on the module namespace, so that it would work
as a "polished" sentinel.

So:

import enum

class Whatever(enum.Enum):
 EMPTY = "EMPTY"

EMPTY = Whatever.EMPTY

A "repeat yourself three times" - certainly not that nice.
But its use was a bit off the ones listed here in a sense these
are meant to be explicitly passed to some methods (rather,
placed inside data structures) to indicate a desired behavior.



On Fri, 14 May 2021 at 21:03, Nick Coghlan  wrote:

> On Sat, 15 May 2021, 5:39 am Tal Einat,  wrote:
>
> (snip useful feature summary)
>
> The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
>> what I've been using for years, and I now think that it isn't good
>> enough. This not having a nice repr is what started this thread.
>>
>> I'd also personally prefer something simple, ideally without a new
>> class or module.
>>
>
> The key advantage of a new base class is that it offers a way to
> communicate a shift in the recommended development idiom. "sentinel =
> object()" is entrenched enough that I would expect that only a
> "types.Sentinel" base class would stand a good chance of displacing it.
>
> Why the "types" module? I don't think this is important enough to be a
> builtin type, and the types module is cheap to import, doesn't bring in
> many transitive dependencies, and the purpose of the new base class would
> be defining custom sentinel types with various desirable properties.
>
> 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/V67I4A6WX6INEAGGSJWYFX4WKQHA73NW/
> 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/2CKU2DRT3T7W7FX6PJARC7FUGB3Q7WKV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The repr of a sentinel

[Nick Coghlan]

On Sat, 15 May 2021, 5:39 am Tal Einat,  wrote:

(snip useful feature summary)

The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
> what I've been using for years, and I now think that it isn't good
> enough. This not having a nice repr is what started this thread.
>
> I'd also personally prefer something simple, ideally without a new
> class or module.
>

The key advantage of a new base class is that it offers a way to
communicate a shift in the recommended development idiom. "sentinel =
object()" is entrenched enough that I would expect that only a
"types.Sentinel" base class would stand a good chance of displacing it.

Why the "types" module? I don't think this is important enough to be a
builtin type, and the types module is cheap to import, doesn't bring in
many transitive dependencies, and the purpose of the new base class would
be defining custom sentinel types with various desirable properties.

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

[Python-Dev] Re: The repr of a sentinel

[David Mertz]

I think it's more future-looking to allow pickle round-tripping. Just add a
._uuid attribute and have object equality follow equality of that
attribute. There's no reason to expose that in the .__repr__, but it would
be inspectable in concept.

On Fri, May 14, 2021, 7:01 PM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

>
> If we drop the requirement for pickle round-tripping then I would add a
> requirement that sentinel is unpicklable, to prevent accidents.
>
> Irit
>
> On Fri, May 14, 2021 at 8:38 PM Tal Einat  wrote:
>
>>
>> I'll try to organize my thoughts a bit here. This is a bit long,
>> welcome to skip to the final sentence for the "tl;dr".
>>
>> Features one may want for a sentinel:
>> 1. Unique from other objects
>> 2. Globally unique, i.e. unique from other such sentinels (no consensus
>> here)
>> 3. Clear repr (the original subject of this thread) - significant
>> since these often appear in function signatures
>> 4. Survives pickling round-trip (I brought this up since I was bitten
>> by this once, but others have mentioned that this is usually
>> irrelevant)
>> 5. Can be given a clear type signature (this was brought up on
>> twitter[1]) - significant since without this nobody can add full type
>> signatures even if they want to
>>
>> The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
>> what I've been using for years, and I now think that it isn't good
>> enough. This not having a nice repr is what started this thread.
>>
>> I'd also personally prefer something simple, ideally without a new
>> class or module.
>>
>> There are several simple idioms using existing features that seem like
>> good options, so let's review those:
>>
>> 1. Ellipsis, a.k.a. `...`. This has all of the features outlined above
>> except #2. My main issue with using Ellipsis for this is that it could
>> be surprising and confusing for devs first encountering such use, and
>> could be relatively awkward to figure out.
>>
>> 2. An instance of a one-off class. dataclasses.MISSING is an example
>> of this. It is defined thus:
>>
>> class _MISSING:
>> pass
>> MISSING = _MISSING()
>>
>> Besides failing #4 (surviving pickle round-trips), its repr isn't
>> great: . That is easily
>> overcome by implementing __repr__.
>>
>> 3. A one-off class:
>>
>> class MISSING: pass
>>
>> This has all of the above features except #5: having a clear type
>> signature (since its type is type). Using a class as a value this way
>> could be surprising, though. It's repr also isn't great: > 'dataclasses._MISSING'>.
>>
>> 4. A value of an single-valued enum, for example (from [1]):
>>
>> class _UNSET(enum.Enum):
>> token = enum.auto()
>>
>> This has all of the features above and is simple, just requiring a
>> comment to explain what it is. It's repr is a bit awkward though:
>>
>> >>> repr(_UNSET.token)
>> '<_UNSET.token: 1>'
>>
>>
>> All of these are in use by some developers, though not necessarily in
>> the stdlib. None is perfect, though all are probably good enough.
>> Since pickling is likely not relevant in most cases, I'm currently in
>> favor of #2 making sure to implement a nice __repr__.
>>
>> - Tal
>>
>> [1] https://twitter.com/nolar/status/1392962447166877697
>> ___
>> 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/BYLTDD72RZUUKVRJL6TTSWF35JD3FL47/
>> 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/7I7S22KEOZY2MDDIYCUPQWG6WXLFZZR5/
> 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/AF5R5BAF3OF53O3CQ4JRZ2OQ2AXOVDZ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The repr of a sentinel

[Irit Katriel via Python-Dev]

If we drop the requirement for pickle round-tripping then I would add a
requirement that sentinel is unpicklable, to prevent accidents.

Irit

On Fri, May 14, 2021 at 8:38 PM Tal Einat  wrote:

>
> I'll try to organize my thoughts a bit here. This is a bit long,
> welcome to skip to the final sentence for the "tl;dr".
>
> Features one may want for a sentinel:
> 1. Unique from other objects
> 2. Globally unique, i.e. unique from other such sentinels (no consensus
> here)
> 3. Clear repr (the original subject of this thread) - significant
> since these often appear in function signatures
> 4. Survives pickling round-trip (I brought this up since I was bitten
> by this once, but others have mentioned that this is usually
> irrelevant)
> 5. Can be given a clear type signature (this was brought up on
> twitter[1]) - significant since without this nobody can add full type
> signatures even if they want to
>
> The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
> what I've been using for years, and I now think that it isn't good
> enough. This not having a nice repr is what started this thread.
>
> I'd also personally prefer something simple, ideally without a new
> class or module.
>
> There are several simple idioms using existing features that seem like
> good options, so let's review those:
>
> 1. Ellipsis, a.k.a. `...`. This has all of the features outlined above
> except #2. My main issue with using Ellipsis for this is that it could
> be surprising and confusing for devs first encountering such use, and
> could be relatively awkward to figure out.
>
> 2. An instance of a one-off class. dataclasses.MISSING is an example
> of this. It is defined thus:
>
> class _MISSING:
> pass
> MISSING = _MISSING()
>
> Besides failing #4 (surviving pickle round-trips), its repr isn't
> great: . That is easily
> overcome by implementing __repr__.
>
> 3. A one-off class:
>
> class MISSING: pass
>
> This has all of the above features except #5: having a clear type
> signature (since its type is type). Using a class as a value this way
> could be surprising, though. It's repr also isn't great:  'dataclasses._MISSING'>.
>
> 4. A value of an single-valued enum, for example (from [1]):
>
> class _UNSET(enum.Enum):
> token = enum.auto()
>
> This has all of the features above and is simple, just requiring a
> comment to explain what it is. It's repr is a bit awkward though:
>
> >>> repr(_UNSET.token)
> '<_UNSET.token: 1>'
>
>
> All of these are in use by some developers, though not necessarily in
> the stdlib. None is perfect, though all are probably good enough.
> Since pickling is likely not relevant in most cases, I'm currently in
> favor of #2 making sure to implement a nice __repr__.
>
> - Tal
>
> [1] https://twitter.com/nolar/status/1392962447166877697
> ___
> 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/BYLTDD72RZUUKVRJL6TTSWF35JD3FL47/
> 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/7I7S22KEOZY2MDDIYCUPQWG6WXLFZZR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Steve Holden]

On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano 
wrote:

> Steve
> (one of the other ones)
>

We are all other Steves!
___
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/NRESFICCEFQGUYUIQMMPO2E7SOUQDXRI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The repr of a sentinel

[Tal Einat]

On Fri, May 14, 2021 at 12:45 PM Steve Dower  wrote:
>
> On 14May2021 0622, micro codery wrote:
> >
> > There was a discussion a while back ( a year or so?? ) on
> > Python-ideas that introduced the idea of having more "sentinel-like"
> > singletons in Python -- right now, we only have None.
> >
> > Not quite true, we also have Ellipsis, which already has a nice repr
> > that both reads easily and still follows the convention of eval(repr(x))
> > == x. It also is already safe from instantiation, survives pickle
> > round-trip and is multi-thread safe.
> > So long as you are not dealing with scientific projects, it seems a
> > quick (if dirty) solution to having a sentinel that is not None.
>
> I don't think using "..." to indicate "some currently unknown or
> unspecified value" is dirty at all, it seems perfectly consistent with
> how we use it in English (and indexing in scientific projects, for that
> matter, where it tends to imply "figure out the rest for me").
>
> All that's really missing is some kind of endorsement (from python-dev,
> presumably in the docs) that it's okay to use it as a default parameter
> value. I can't think of any reason you'd need to accept Ellipsis as a
> *specified* value that wouldn't also apply to any other kind of shared
> sentinel.

I'll try to organize my thoughts a bit here. This is a bit long,
welcome to skip to the final sentence for the "tl;dr".

Features one may want for a sentinel:
1. Unique from other objects
2. Globally unique, i.e. unique from other such sentinels (no consensus here)
3. Clear repr (the original subject of this thread) - significant
since these often appear in function signatures
4. Survives pickling round-trip (I brought this up since I was bitten
by this once, but others have mentioned that this is usually
irrelevant)
5. Can be given a clear type signature (this was brought up on
twitter[1]) - significant since without this nobody can add full type
signatures even if they want to

The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is
what I've been using for years, and I now think that it isn't good
enough. This not having a nice repr is what started this thread.

I'd also personally prefer something simple, ideally without a new
class or module.

There are several simple idioms using existing features that seem like
good options, so let's review those:

1. Ellipsis, a.k.a. `...`. This has all of the features outlined above
except #2. My main issue with using Ellipsis for this is that it could
be surprising and confusing for devs first encountering such use, and
could be relatively awkward to figure out.

2. An instance of a one-off class. dataclasses.MISSING is an example
of this. It is defined thus:

class _MISSING:
pass
MISSING = _MISSING()

Besides failing #4 (surviving pickle round-trips), its repr isn't
great: . That is easily
overcome by implementing __repr__.

3. A one-off class:

class MISSING: pass

This has all of the above features except #5: having a clear type
signature (since its type is type). Using a class as a value this way
could be surprising, though. It's repr also isn't great: .

4. A value of an single-valued enum, for example (from [1]):

class _UNSET(enum.Enum):
token = enum.auto()

This has all of the features above and is simple, just requiring a
comment to explain what it is. It's repr is a bit awkward though:

>>> repr(_UNSET.token)
'<_UNSET.token: 1>'


All of these are in use by some developers, though not necessarily in
the stdlib. None is perfect, though all are probably good enough.
Since pickling is likely not relevant in most cases, I'm currently in
favor of #2 making sure to implement a nice __repr__.

- Tal

[1] https://twitter.com/nolar/status/1392962447166877697
___
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/BYLTDD72RZUUKVRJL6TTSWF35JD3FL47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-05-07 - 2021-05-14)
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:
  open7429 ( +1)
  closed 48441 (+64)
  total  55870 (+65)

Open issues with patches: 2949 


Issues opened (41)
==

#41730: Show deprecation warnings for tkinter.tix
https://bugs.python.org/issue41730  reopened by pablogsal

#44072: Doc: power operator (`**`) present for numbers.Complex, not ad
https://bugs.python.org/issue44072  opened by roryyorke

#44073: [sqlite3] drop statement in_use field in favour of sqlite3_stm
https://bugs.python.org/issue44073  opened by erlendaasland

#44075: Add a PEP578 audit hook for Asyncio loop stalls
https://bugs.python.org/issue44075  opened by orf

#44077: IP_RECVTOS option is missing from socket module
https://bugs.python.org/issue44077  opened by gms

#44078: Output relative path when using PurePath.relative_to
https://bugs.python.org/issue44078  opened by mhammondr

#44079: [sqlite3] remove superfluous statement weak ref list from conn
https://bugs.python.org/issue44079  opened by erlendaasland

#44081: ast.unparse: dont use redundant space separator for lambdas wi
https://bugs.python.org/issue44081  opened by BTaskaya

#44082: Add a method to check interpolation errors in configparser
https://bugs.python.org/issue44082  opened by munircontractor

#44085: Remaining invalid rules in simplified grammar
https://bugs.python.org/issue44085  opened by quentel

#44086: py.svg not found on search result page
https://bugs.python.org/issue44086  opened by jugmac00

#44087: [sqlite3] consider adding Py_TPFLAGS_DISALLOW_INSTANTIATION to
https://bugs.python.org/issue44087  opened by erlendaasland

#44090: Add class binding to unbound super objects for allowing autosu
https://bugs.python.org/issue44090  opened by maggyero

#44091: traceback & inspect modules should verify that the .py source 
https://bugs.python.org/issue44091  opened by gregory.p.smith

#44092: [sqlite3] consider removing special rollback handling
https://bugs.python.org/issue44092  opened by erlendaasland

#44093: compiler detection on macOS seems to be incorrect
https://bugs.python.org/issue44093  opened by xrisk

#44096: Bad clang detection in configure script
https://bugs.python.org/issue44096  opened by xrisk

#44097: add configure option to control the groups of .pyc files to in
https://bugs.python.org/issue44097  opened by pxinwr

#44099: [c-api] Introduce a new slot in PyModuleDef to hold the classe
https://bugs.python.org/issue44099  opened by shreyanavigyan

#44100: test__xxsubinterpreters: test_one() fails in AMD64 Fedora Stab
https://bugs.python.org/issue44100  opened by pablogsal

#44101: Generation of an executable's library file when python is buil
https://bugs.python.org/issue44101  opened by lakor64

#44102: mock_open does not support the use of 'seek()'
https://bugs.python.org/issue44102  opened by nikle

#44105: tempfile.TemporaryDirectory deleted after sleep in threads
https://bugs.python.org/issue44105  opened by colas.le.guernic

#44106: [sqlite3] don't use politicians in examples/docs
https://bugs.python.org/issue44106  opened by erlendaasland

#44107: HTTPServer can't close http client completely
https://bugs.python.org/issue44107  opened by ueJone

#44109: missing dataclass decorator in match-statement example
https://bugs.python.org/issue44109  opened by ahmetveburak

#44110: Improve string's __getitem__ error message
https://bugs.python.org/issue44110  opened by miguendes

#44112: [buildbot] test_asyncio hangs (killed after 3 hours) on Reflea
https://bugs.python.org/issue44112  opened by vstinner

#44115: Improve conversions for fractions
https://bugs.python.org/issue44115  opened by Martin.Teichmann

#44117: [C API] Remove deprecated PyEval_InitThreads()
https://bugs.python.org/issue44117  opened by vstinner

#44120: logging.config.fileConfig/dictConfig can not import class
https://bugs.python.org/issue44120  opened by akihiro

#44121: Missing implementation for formatHeader and formatFooter metho
https://bugs.python.org/issue44121  opened by Harmouch101

#44123: make function parameter sentinel value true singletons
https://bugs.python.org/issue44123  opened by taleinat

#44124: Unhelpful error messages with mis-ordering of f-string specifi
https://bugs.python.org/issue44124  opened by angus-lherrou

#44127: urllib.parse.ParseResult._replace() does not allow replacing u
https://bugs.python.org/issue44127  opened by AstraLuma

#44128: zipfile: Deduplicate ZipExtFile code for init and resetting wh
https://bugs.python.org/issue44128  opened by dhillier

#44129: zipfile: Add descriptive global variables for general purpose 
https://bugs.python.org/issue44129  opened by dhillier

#44131: [C API] Add tests on Py_FrozenMain()
https://bugs.python.org/issue44131  opened by vstinner

#44132: Local import conflict with system import

[Python-Dev] Re: The repr of a sentinel

[Barry Warsaw]

On May 14, 2021, at 02:38, Chris Angelico  wrote:
> 
> Do we ever really need the ability to pass a specific sentinel to a
> function, or are we actually looking for a way to say "and don't pass
> this argument”?

Very often, that’s the case.  Such a “it’s okay to not pass this argument” 
construct would have to work with the Optional type too.

The other use case I have for a special case single use singleton is for 
dict.get(), i.e.

missing = object()
value = somedict.get(‘key’, missing)
if value is missing:
# It ain’t there.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/2VTKCFCR6PPMS5ZYUYM3SF2BVFQYMSSE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The repr of a sentinel

[Chris Angelico]

On Sat, May 15, 2021 at 2:04 AM Barry Warsaw  wrote:
>
> On May 14, 2021, at 02:38, Chris Angelico  wrote:
> >
> > Do we ever really need the ability to pass a specific sentinel to a
> > function, or are we actually looking for a way to say "and don't pass
> > this argument”?
>
> Very often, that’s the case.  Such a “it’s okay to not pass this argument” 
> construct would have to work with the Optional type too.

What I mean is: how often do you actually need to pass the specific
sentinel, as opposed to the normal construct of asking if the argument
was or wasn't passed? Eg if you have a function like this:

_sentinel = object()
def func(x, y=_sentinel):
if y is _sentinel: ...
else: ...

Would you ever call it like this:

func(42, _sentinel)

? Because if there's no reason to ever pass the sentinel, then it's
nothing more than an implementation detail for the concept of "was
this argument passed?", and that's exactly what I'm asking about.

> The other use case I have for a special case single use singleton is for 
> dict.get(), i.e.
>
> missing = object()
> value = somedict.get(‘key’, missing)
> if value is missing:
> # It ain’t there.
>

I'd write that one with a try/except instead. The whole point of get()
is to provide the missing value.

try:
value = somedict['key']
except KeyError:
# It ain't there.

No sentinel needed. Same number of lines.

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

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Fabio Zadrozny]

>
> > 3. Another example: I'm working right now on a feature to step into a
> > method. To do that right now my approach is:
> >  - Compute the function call names and bytecode offsets in a given
> > frame.
> >  - When a frame is called (during a frame.f_trace call), check the
> > parent frame bytecode offset (frame.f_lasti) to detect if the last thing
> > was the expected call (and if it was, break the execution).
> >
> > This seems reasonable given the current implementation, where bytecodes
> > are all fixed and there's a mapping from the frame.f_lasti ... Will that
> > still work with the specializing adaptive interpreter?
>
> If you are implementing this in Python, then everything should work as
> it does now.
>

Ok... this part is all done in Python, so, if frame.f_lasti is still
updated properly according to the original bytecode while executing the
super instructions, then all seems to work properly on my side ;).

>
> OOI, would inserting a breakpoint at offset 0 in the callee function
> work?
>

Yes... if you're curious, for the breakpoint to actually work, what is done
is generate bytecode which calls a function to set the tracing and later
generates a spurious line event (so that the tracing function is then able
to make the pause. The related code that generates this bytecode would be:
https://github.com/fabioz/PyDev.Debugger/blob/pydev_debugger_2_4_1/_pydevd_frame_eval/pydevd_modify_bytecode.py#L74
).


>
> >
> > 4. Will it still be possible to change the frame.f_code prior to
> > execution from a callback set in `PyThreadState.interp.eval_frame`
> > (which will change the code to add a breakpoint to the bytecode and
> > later call `_PyEval_EvalFrameDefault`)? Note: this is done in the
> > debugger so that Python can run without any tracing until the breakpoint
> > is hit (tracing is set afterwards to actually pause the execution as
> > well as doing step operations).
>
> Since frame.f_code is read-only in Python, I assume you mean in C.
>
> I can make no guarantees about the layout or meaning of fields in the C
> frame struct, I'm afraid.
> But I'm sure we can get something to work for you.
>

Yes, it's indeed done in C (cython in this case... the related code for
reference is:
https://github.com/fabioz/PyDev.Debugger/blob/pydev_debugger_2_4_1/_pydevd_frame_eval/pydevd_frame_evaluator.template.pyx#L591
).

I'm fine in going through some other way or using some other API (this is
quite specific to a debugger after all), I just wanted to let you know of
the use case so that something along those lines can still be supported
(currently on CPython, this is as low-overhead for debugging as I can think
of, but since there'll be an adaptive bytecode specializer, using any other
custom API would also be reasonable).

Cheers,

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

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Mark Shannon]

Hi Fabio,

On 13/05/2021 7:11 pm, Fabio Zadrozny wrote:


Em qua., 12 de mai. de 2021 às 14:45, Mark Shannon > escreveu:


Hi everyone,

I would like to present PEP 659.

This is an informational PEP about a key part of our plan to improve
CPython performance for 3.11 and beyond.

For those of you aware of the recent releases of Cinder and Pyston,
PEP 659 might look similar.
It is similar, but I believe PEP 659 offers better interpreter
performance and is more suitable to a collaborative, open-source
development model.

As always, comments and suggestions are welcome.


Hi Mark,

I think this seems like a nice proposal... I do have some questions 
related to the PEP though (from the point of view of implementing a 
debugger over it some things are kind of vague to me):


1. When will the specialization happen? (i.e.: is bytecode expected to 
be changed while the code is running inside a frame or must it all be 
done prior to entering a frame on a subsequent call?)


The specialization is adaptive, so it can happen at anytime during 
execution.




2. When the adaptive specialization happens, will that be reflected on 
the actual bytecode seen externally in the frame or is that all 
internal? Will clients be able to make sense of that? -- i.e.: In the 
debugger right now I have a need on some occasions to detect the 
structure of the code from the bytecode itself (for instance to detect 
whether some exception would be handled or unhandled at raise time just 
given the bytecode).


The bytecode, as externally visible, will be unchanged. All 
specializations will be internal and should be invisible to all Python 
tools.




3. Another example: I'm working right now on a feature to step into a 
method. To do that right now my approach is:
     - Compute the function call names and bytecode offsets in a given 
frame.
     - When a frame is called (during a frame.f_trace call), check the 
parent frame bytecode offset (frame.f_lasti) to detect if the last thing 
was the expected call (and if it was, break the execution).


This seems reasonable given the current implementation, where bytecodes 
are all fixed and there's a mapping from the frame.f_lasti ... Will that 
still work with the specializing adaptive interpreter?


If you are implementing this in Python, then everything should work as 
it does now.


OOI, would inserting a breakpoint at offset 0 in the callee function
work?



4. Will it still be possible to change the frame.f_code prior to 
execution from a callback set in `PyThreadState.interp.eval_frame` 
(which will change the code to add a breakpoint to the bytecode and 
later call `_PyEval_EvalFrameDefault`)? Note: this is done in the 
debugger so that Python can run without any tracing until the breakpoint 
is hit (tracing is set afterwards to actually pause the execution as 
well as doing step operations).


Since frame.f_code is read-only in Python, I assume you mean in C.

I can make no guarantees about the layout or meaning of fields in the C 
frame struct, I'm afraid.

But I'm sure we can get something to work for you.

Cheers,
Mark.



Best regards,

Fabio




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

[Python-Dev] Re: The repr of a sentinel

[Steve Dower]

On 14May2021 0622, micro codery wrote:


There was a discussion a while back ( a year or so?? ) on
Python-ideas that introduced the idea of having more "sentinel-like"
singletons in Python -- right now, we only have None. 

Not quite true, we also have Ellipsis, which already has a nice repr 
that both reads easily and still follows the convention of eval(repr(x)) 
== x. It also is already safe from instantiation, survives pickle 
round-trip and is multi-thread safe.
So long as you are not dealing with scientific projects, it seems a 
quick (if dirty) solution to having a sentinel that is not None.


I don't think using "..." to indicate "some currently unknown or 
unspecified value" is dirty at all, it seems perfectly consistent with 
how we use it in English (and indexing in scientific projects, for that 
matter, where it tends to imply "figure out the rest for me").


All that's really missing is some kind of endorsement (from python-dev, 
presumably in the docs) that it's okay to use it as a default parameter 
value. I can't think of any reason you'd need to accept Ellipsis as a 
*specified* value that wouldn't also apply to any other kind of shared 
sentinel.


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

[Python-Dev] Re: The repr of a sentinel

[Chris Angelico]

On Fri, May 14, 2021 at 7:31 PM Petr Viktorin  wrote:
> Perhaps it would be beneficial to provide a common base class or
> factory, so we get a good repr. But I don't think another common value
> like None and Ellipsis would do much good.
>

Agreed - I think Sentinel would make a great class, from which you
instantiate purpose-specific sentinels.

But maybe there really needs to be a way to NOT specify an argument,
and to find out that an argument wasn't specified? Defaulting is only
one way to handle it. Consider:

def truly_optional_arg(x, y, *z):
"""Two mandatory args, and then an optional one"""
if z: print("Got an extra arg")

pass_arg = input("Pass the arg? ") == "y"
truly_optional_arg(10, 20, *([30] if pass_arg else []))

It's horrifically ugly, but it really and truly does/doesn't pass that
argument, and it really and truly detects whether one was passed. To
make that sort of thing actually viable, there'd need to be some sort
of language support; maybe something where the local name would start
out unbound, but testing for a local's boundness is a clunky
try/except, so that might also need some support.

Do we ever really need the ability to pass a specific sentinel to a
function, or are we actually looking for a way to say "and don't pass
this argument"?

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

[Python-Dev] Re: The repr of a sentinel

[Petr Viktorin]

On 14. 05. 21 10:55, Victor Stinner wrote:

Hi Tal,

Would it make sense to have an unique singleton for such sentinel, a
built-in singleton like None or Ellipsis? I propose the name
"Sentinel".

Sentinel would be similar to None, but the main property would be that
"Sentinel is None" is false :-)


If you need your Sentinel to be different from one particular sentinel 
(None), you'll usually want it to be different from all the other ones 
as well.


A sentinel for an optional parameter shouldn't really be used at all 
outside of the function it's defined for. That's why it's usually 
defined as a private module-level variable.


Perhaps it would be beneficial to provide a common base class or 
factory, so we get a good repr. But I don't think another common value 
like None and Ellipsis would do much good.




The stdlib contains tons of sentinels:

* _collections_abc: __marker__
* cgitb.__UNDEF__
* configparser: _UNSET
* dataclasses: _HAS_DEFAULT_FACTORY, MISSING, KW_ONLY
* datetime.timezone._Omitted
* fnmatch.translate() STAR
* functools.lru_cache.sentinel (each @lru_cache creates its own sentinel object)
* functools._NOT_FOUND
* heapq: temporary sentinel in nsmallest() and nlargest()
* inspect._sentinel
* inspect._signature_fromstr() invalid
* plistlib._undefined
* runpy._ModifiedArgv0._sentinel
* sched: _sentinel
* traceback: _sentinel

There are different but similar use cases:

* Optional parameter: distinguish between func() and func(arg=value),
a sentinel is useful to distinguish func() from func(arg=None)
* Look into a data structure for a value and store the result in a
value, distinguish if 'result' variable was set ("result is not None"
doesn't work since None is a value). Quick example: "missing =
object(); tmsg = self._catalog.get(message, missing); if tmsg is
missing: ..."

Special cases:

* dataclases._EMPTY_METADATA = types.MappingProxyType({})
* string._sentinel_dict = {}
* enum: _auto_null = object()

Victor

On Thu, May 13, 2021 at 7:40 PM Tal Einat  wrote:


On Thu, May 13, 2021 at 7:44 PM Ethan Furman  wrote:


Consider me complaining.  ;-)


+1


An actual Sentinel class would be helpful:

  >>> class Sentinel:
  ... def __init__(self, repr):
  ... self.repr = repr
  ... def __repr__(self):
  ... return self.repr
  ...

  >>> MISSING = Sentinel('MISSING')
  >>> MISSING
  MISSING

  >>> implicit = Sentinel('')
  >>> implicit
  


Here is my suggestion (also posted on the related bpo-44123), which is
also simple, ensures a single instance is used, even considering
multi-threading and pickling, and has a better repr:

class Sentinel:
 def __new__(cls, *args, **kwargs):
 raise TypeError(f'{cls.__qualname__} cannot be instantiated')

class MISSING(Sentinel):
 pass

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

[Python-Dev] Re: The repr of a sentinel

[Victor Stinner]

Hi Tal,

Would it make sense to have an unique singleton for such sentinel, a
built-in singleton like None or Ellipsis? I propose the name
"Sentinel".

Sentinel would be similar to None, but the main property would be that
"Sentinel is None" is false :-)

The stdlib contains tons of sentinels:

* _collections_abc: __marker__
* cgitb.__UNDEF__
* configparser: _UNSET
* dataclasses: _HAS_DEFAULT_FACTORY, MISSING, KW_ONLY
* datetime.timezone._Omitted
* fnmatch.translate() STAR
* functools.lru_cache.sentinel (each @lru_cache creates its own sentinel object)
* functools._NOT_FOUND
* heapq: temporary sentinel in nsmallest() and nlargest()
* inspect._sentinel
* inspect._signature_fromstr() invalid
* plistlib._undefined
* runpy._ModifiedArgv0._sentinel
* sched: _sentinel
* traceback: _sentinel

There are different but similar use cases:

* Optional parameter: distinguish between func() and func(arg=value),
a sentinel is useful to distinguish func() from func(arg=None)
* Look into a data structure for a value and store the result in a
value, distinguish if 'result' variable was set ("result is not None"
doesn't work since None is a value). Quick example: "missing =
object(); tmsg = self._catalog.get(message, missing); if tmsg is
missing: ..."

Special cases:

* dataclases._EMPTY_METADATA = types.MappingProxyType({})
* string._sentinel_dict = {}
* enum: _auto_null = object()

Victor

On Thu, May 13, 2021 at 7:40 PM Tal Einat  wrote:
>
> On Thu, May 13, 2021 at 7:44 PM Ethan Furman  wrote:
> >
> > Consider me complaining.  ;-)
>
> +1
>
> > An actual Sentinel class would be helpful:
> >
> >  >>> class Sentinel:
> >  ... def __init__(self, repr):
> >  ... self.repr = repr
> >  ... def __repr__(self):
> >  ... return self.repr
> >  ...
> >
> >  >>> MISSING = Sentinel('MISSING')
> >  >>> MISSING
> >  MISSING
> >
> >  >>> implicit = Sentinel('')
> >  >>> implicit
> >  
>
> Here is my suggestion (also posted on the related bpo-44123), which is
> also simple, ensures a single instance is used, even considering
> multi-threading and pickling, and has a better repr:
>
> class Sentinel:
> def __new__(cls, *args, **kwargs):
> raise TypeError(f'{cls.__qualname__} cannot be instantiated')
>
> class MISSING(Sentinel):
> pass
>
> - Tal
> ___
> 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/URFRF634732GRICGLRPGJEJON2BYQZM4/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/JBYXQH3NV3YBF7P2HLHB5CD6V3GVTY55/
Code of Conduct: http://python.org/psf/codeofconduct/