[Python-Dev] Re: The repr of a sentinel
> 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. There is also some symmetrical wholeness when considered with the other builtin sentinels: bool(None) is False; bool(Ellipsis) is True. ___ 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/UQPD5NNAVWIQWIACOY7YRZGWMJO4URJ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
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: The repr of a sentinel
> > But it nevertheless feels like a bit of an abuse - the original point >> > of ellipsis was for indexing, and in particular complex slices like >> > a[1:20:2, ..., 3:5]. That usage is common in numpy, as I understand >> > it, >> Interesting -- do you know what ... means in that context? >> > > In NumPy, the ellipsis means "fill in as many dimensions as needed (with > full range)". > I am in the same boat here in that until now I saw Ellipsis as a thing used by numpy and adjacent libraries in slicing. I don't think I have ever written a slice with "..." in it so please forgive any ignorance but wasn't the reason for having Ellipsis originally that None already had a special meaning to the slice object and a different sentinel was needed? In other words the normal case of a missing argument being None caused specific side effects that needed to be skipped, so a sentinel was created to distinguish these cases, just like we are discussing for other objects? It seems to me the current situation has more in common than not. Numpy could have created its own Sentinel object for its own use in these sliceses, just as it now creates its own Sentinel for NoValue, but somewhere along the way it was determined to be in the better interest of the community to have this object defined in the standard library so it could be shared by multiple scientific libraries without additional dependency burden, even though it had no use to CPython. I think there was perhaps a time when Ellipsis was so closely tied to the scientific libraries that recommending its use anywhere else would have been a poor idea, probably mostly because of the body of existing teaching around its use; but I also think that association is no longer as strong. "..." is being adopted across the typing landscape with several PEPs, such as 483, outlining their special meaning in annotations. In addition, stub files have since the beginning normalized on putting "..." as the function body despite already having the working conventions of `pass` `NotImplemented` or just a good old empty docstring "" filling the same purpose in standard python files. ___ 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/IEF42DESJEJITI4HR5SJZHM3FDILKX6Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Delayed evaluation of f-strings?
As pointed out already, f-strings and format are subtly different (not
counting that one can eval and the other cannot). Besides quoting, the
f-sting mini language has diverged from format's
>>> spam="Spam"
>>> f"{spam=}"
"spam='Spam'"
>>> "{spam=}".format(spam=spam)
Traceback (most recent call last):
File "", line 1, in
KeyError: 'spam='
I created a package some time ago to do exactly this
https://pypi.org/project/f-yeah/
On Thu, Jun 24, 2021 at 10:07 AM Luciano Ramalho
wrote:
> I don't think that would be a good idea since we already have
> .format() which covers that use case and is more flexible than
> f-strings (it supports positional arguments, as well as *args and
> **kwargs).
>
> I think keeping f-strings simple is a better idea.
>
> Best,
>
> Luciano
>
> On Thu, Jun 24, 2021 at 1:30 PM Eric Nieuwland
> wrote:
> >
> > In a recent discussion with a colleague we wondered if it would be
> possible to postpone the evaluation of an f-string so we could use it like
> a regular string and .format() or ‘%’.
> >
> > I found
> https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
> and tweaked it a bit to:
> >
> > import inspect
> >
> > class DelayedFString(str):
> > def __str__(self):
> > vars = inspect.currentframe().f_back.f_globals.copy()
> > vars.update(inspect.currentframe().f_back.f_locals)
> > return self.format(**vars)
> >
> > delayed_fstring = DelayedFString("The current name is {name}")
> >
> > # use it inside a function to demonstrate it gets the scoping right
> > def new_scope():
> > names = ["foo", "bar"]
> > for name in names:
> > print(delayed_fstring)
> >
> > new_scope()
> >
> >
> > While this does what it should it is very slow.
> > So I wondered whether it would be an idea to introduce d-strings
> (delayed f-strings) and make f-strings syntactic sugar for
> >
> > f"The current name is {name}" = str(d"The current name is {name}")
> >
> >
> > And perhaps access to the variables and conversions specified in the
> d-string.
> >
> > ___
> > 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/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Luciano Ramalho
> | Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> | Technical Principal at ThoughtWorks
> | Twitter: @ramalhoorg
> ___
> 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/LVPDNGURA677ODMLBVUURPXKYGBKJ6A4/
> 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/NVOONRQUMSBZUX4W6MTPM763DCXMOLC5/
Code of Conduct: http://python.org/psf/codeofconduct/
