Re: [Python-ideas] Add new `Symbol` type
On Thu, Jul 5, 2018 at 1:25 PM, Flavio Curella wrote:
>
>> What functionality does such a thing actually need?
>
> I think the requirements should be:
> * The resulting symbol behave exactly like None. IE: the symbol should not
> be an instance of object, but an instance of its own class
> * A symbol can optionally be globally unique.
> * Two symbols created by the same key must not be equal. IE: they have equal
> key, but different value
>* if we're trying to create global symbols with the same key, an
> exception is thrown
>
> This is mostly based on the Javascript spec.
I think the name "symbol" here is pretty confusing. It comes
originally from Lisp, where it's used to refer to an interned-string
data type. It's a common source of confusion even there. Then it
sounds like JS took that name, and it ended up drifting to mean
something that's almost exactly the opposite of a Lisp symbol. In
Lisp, symbols are always "global"; the whole point is that if two
different pieces of code use the same name for the same symbol then
they end up with the same object. So this is *super* confusing. I
think I see how JS ended up here [1], but the rationale really doesn't
translate to other languages.
The thing you're talking about is what Python devs call a "sentinel"
object. If your proposal is to add a sentinel type to the stdlib, then
your chance of success will be *much* higher if you use the word
"sentinel" instead of "symbol". People don't read mailing list threads
carefully, so if you keep calling it "symbol" then you'll likely spend
infinite time responding to people rushing in to critique your
proposal based on some misconception about what you're trying to do,
which is no fun at all. Honestly I'd probably start a new thread with
a new subject, ideally with an initial straw-man proposal for the
semantics of these objects.
-n
[1] What was JS thinking? Well, I'm not sure I have all the details
right, but AFAICT it's all very logical... JS objects, like Python
objects, have attributes, e.g. 'console.log' is the 'log' attribute of
the 'console' object. There's a table inside the 'console' object
mapping keys like 'log' to their corresponding values, much like a
Python object's __dict__. But a Python dict can use arbitrary objects
as keys. JS attribute tables are different: the keys are required to
be Lisp-style symbol objects: they're arbitrary strings (and only
strings), that are then interned for speed. This kind of table lookup
is exactly why Lisp invented symbols in the first place; a Lisp scope
is also a table mapping symbols to values. BUT THEN, they decided to
enhance JS to add the equivalent of special methods like Python's
__add__. Now how do you tell which attributes are ordinary attributes,
and which ones are supposed to be special? In Python of course we use
a naming convention, which is simple and works well. But in JS, by the
time they decided to do this, it was too late: people might already be
using names like "__add__" for regular attributes, and making them
special would break compatibility. In fact, *all* possible strings
were potentially already in use for ordinary attributes; there were no
names left for special attributes. SO, they decided, they needed to
expand the set of symbol objects (i.e., attribute names) to include
new values that were different from all possible strings. So now the
JS Symbol class is effectively the union of {strings, compared as
values} + {sentinels, compared by identity}. And for string
attributes, you can mostly ignore all this and pretend they're
ordinary strings and the JS interpreter will paper over the details.
So the main kind of symbol that JS devs actually have to *know* about
is the new sentinel values. And that's how the name "symbol" flipped
to mean the opposite of what it used to. See? I told you it was all
very logical.
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)
On Thu, Jul 5, 2018 at 3:26 AM, David Mertz wrote: > Yes, he said a definite no to a built-in. But he expressed a less specific > lack of enthusiasm for collections classes (including Counter, which exists > and which I personally use often). > And a Grouping class would do more than Counter, which I find trivial enough that I generally don't bother to use it. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add new `Symbol` type
> What functionality does such a thing actually need? I think the requirements should be: * The resulting symbol behave exactly like None. IE: the symbol should not be an instance of object, but an instance of its own class * A symbol can optionally be globally unique. * Two symbols created by the same key must not be equal. IE: they have equal key, but different value * if we're trying to create global symbols with the same key, an exception is thrown This is mostly based on the Javascript spec. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add new `Symbol` type
I have also wanted sentinel objects many times. These are often useful for creating a "Not Specified" default value when explicitly passing `None` has semantic meaning. There are a few issues with the `sentinel = object()` code. One is that they don't repr well so they make debugging harder. Another issue is that they cannot be pickled or copied. You also cannot take a weak reference to a sentinel which can break some caching code and makes them harder to use. At work we have a small helper to create sentinels with a name and optional doc string which is open sourced here: https://github.com/quantopian/zipline/blob/master/zipline/utils/sentinel.py. On Thu, Jul 5, 2018 at 3:44 PM, Ed Kellett wrote: > Hi! > > On 2018-07-05 20:38, Flavio Curella wrote: >> More than once I've found myself wanting to create a 'sentinel' value. The >> most common use case is to differentiate between an argument that has not >> been provided, and an argument provided with the value `None`. > > I generally do something like > > _nothing = object() > >> Furthermore, without a common implementation in the std library, various >> Python libraries had to write their own implementations, which all differs >> in functionality and behavior. > > What functionality does such a thing actually need? > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add new `Symbol` type
Hi! On 2018-07-05 20:38, Flavio Curella wrote: > More than once I've found myself wanting to create a 'sentinel' value. The > most common use case is to differentiate between an argument that has not > been provided, and an argument provided with the value `None`. I generally do something like _nothing = object() > Furthermore, without a common implementation in the std library, various > Python libraries had to write their own implementations, which all differs > in functionality and behavior. What functionality does such a thing actually need? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add new `Symbol` type
More than once I've found myself wanting to create a 'sentinel' value. The most common use case is to differentiate between an argument that has not been provided, and an argument provided with the value `None`. This would be solvable by implementing something similar to what JavaScript calls [`Symbol`]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol ). This could be implemented as a 3rd-party library, but there won't be a way to have ['Global' Symbols]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/for ) Furthermore, without a common implementation in the std library, various Python libraries had to write their own implementations, which all differs in functionality and behavior. Is this something that the Python community is interested in? I'm willing to write the PEP ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add `rc` to distutils.version.StrictVersion
StrictVersion from distutils accepts version tags like 1.14.0 1.14.0a1 1.14.0b2 but not 1.14.0rc1 (nor 1.14.0c1). My suggestion: Add `rc` in the regexp and make it a `prerelease` (the latter comes for free by the current implementation). Most package maintainers have adopted the `rc` abbreviation for release candidate versioning, e.g. - numpy 1.14.0rc1 - scipy 1.1.0rc1 - plotly 3.0.0rc1 - pandas 0.23.0rc1 - matplotlib 2.2.0rc1 - dask 0.13.0rc1 - django 1.9rc1. All of these are available on PyPI. A natural way of sorting version numbers from pip is by simply using sorted(versions, key=distutils.version.StrictVersion), however, due to StrictVersion only accepting `a` and `b` as abbreviations, this does not work for the aforemention packages. The very obvious cons are: - touching 20 years old code [1] - StrictVersion is preserved "for anal retentives and software idealists", and I don't know if they agree. There might be more cons I fail to think of at this moment. [1] https://github.com/python/cpython/blob/master/Lib/distutils/version.py#L130 Pål Grønås Drange ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Where should grouping() live (was: grouping / dict of lists)
Yes, he said a definite no to a built-in. But he expressed a less specific lack of enthusiasm for collections classes (including Counter, which exists and which I personally use often). On Thu, Jul 5, 2018, 1:16 AM Chris Barker wrote: > On Tue, Jul 3, 2018 at 6:23 AM, David Mertz wrote: > >> Guido said he has muted this discussion >> > > ... > > But before putting it on auto-archive, the BDFL said (1) NO GO on getting > a new builtin; (2) NO OBJECTION to putting it in itertools. > > I don't recall him offering an opinion on a class in collections, did he? > > -CHB > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
