Re: [Python-ideas] Dictionary destructing and unpacking.
> > Maps with a known, fixed set of keys are relatively uncommon > in Python, though. This is false in interacting with HTTP services, where frequently you're working with deserialized JSON dictionaries you expect to be in a precise format (and fail if not). On Wed, Jun 7, 2017 at 11:32 PM, Greg Ewing wrote: > C Anthony Risinger wrote: > >> Incredibly useful and intuitive, and for me again, way more generally >> applicable than iterable unpacking. Maps are ubiquitous. >> > > Maps with a known, fixed set of keys are relatively uncommon > in Python, though. Such an object is more likely to be an > object with named attributes. > > -- > Greg > > > ___ > 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] Dictionary destructing and unpacking.
C Anthony Risinger wrote: Incredibly useful and intuitive, and for me again, way more generally applicable than iterable unpacking. Maps are ubiquitous. Maps with a known, fixed set of keys are relatively uncommon in Python, though. Such an object is more likely to be an object with named attributes. -- Greg ___ 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] Dictionary destructing and unpacking.
One existing way to do this:
a, b, c = (mydict[k] for k in ('a', 'b', 'c'))
--
Greg
___
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] Dictionary destructing and unpacking.
> In python 3.6+ this is better since the dictionary is insertion-ordered, but is still not really what one would probably want. Be careful: ordered dict is an implementation detail. You must use explicitly collections.OrderedDict() to avoid bad surprises. In CPython 3.7, dict might change again. Victor ___ 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] Dictionary destructing and unpacking.
Thank you! This overview really helps!
On Thu, Jun 08, 2017 at 11:18:06AM +1000, Steven D'Aprano
wrote:
> On Wed, Jun 07, 2017 at 06:14:08PM +, Nick Humrich wrote:
>
> > It would be cool to have a syntax that would unpack the dictionary to
> > values based on the names of the variables. Something perhaps like:
> >
> > a, b, c = **mydict
>
> This was discussed (briefly, to very little interest) in March/April
> 2008:
>
> https://mail.python.org/pipermail/python-ideas/2008-March/001511.html
> https://mail.python.org/pipermail/python-ideas/2008-April/001513.html
>
> and then again in 2016, when it spawned a very large thread starting
> here:
>
> https://mail.python.org/pipermail/python-ideas/2016-May/040430.html
>
> I know there's a lot of messages, but I STRONGLY encourage anyone,
> whether you are for or against this idea, to read the previous
> discussion before continuing it here.
>
> Guido was luke-warm about the **mapping syntax:
>
> https://mail.python.org/pipermail/python-ideas/2016-May/040466.html
>
> Nathan Schneider proposed making dict.values() take optional key names:
>
> https://mail.python.org/pipermail/python-ideas/2016-May/040517.html
>
> Guido suggested that this should be a different method:
>
> https://mail.python.org/pipermail/python-ideas/2016-May/040518.html
>
> My recollection is that the discussion evertually petered out with a
> more-or-less consensus that having a dict method (perhaps "getvalues"?)
> plus regular item unpacking is sufficient for the common use-case of
> unpacking a subset of keys:
>
> prefs = {'width': 80, 'height': 200, 'verbose': False, 'mode': PLAIN,
> 'name': 'Fnord', 'flags': spam|eggs|cheese, ... }
> # dict includes many more items
>
> width, height, size = prefs.getvalues(
> 'width', 'height', 'papersize',
> )
>
>
> This trivially supports the cases where keys are not strings or valid
> identifiers:
>
> class_, spam, eggs = mapping.getvalues('class', 42, '~')
>
> It easily supports assignment targets which aren't simple variable
> names:
>
> obj.attribute[index], spam().attr = mapping.getvalues('foo', 'bar')
>
> An optional (defaults to False) "pop" keyword argument supports
> extracting and removing values from the dict in one call, which is
> commonly needed inside __init__ methods with **kwargs:
>
> class K(parent):
> def __init__(self, a, b, c, **kwargs):
> self.spam = kwargs.pop('spam')
> self.eggs = kwargs.pop('eggs')
> self.cheese = kwargs.pop('cheese')
> super().__init__(a, b, c, **kwargs)
>
>
> becomes:
>
> self.spam, self.eggs, self.cheese = kwargs.getvalues(
> 'spam eggs cheese'.split(), pop=True
> )
>
>
> I don't recall this being proposed at the time, but we could support
> keyword arguments for missing or default values:
>
> DEFAULTS = {'height': 100, 'width': 50}
> prefs = get_prefs() # returns a dict
>
> height, width, size = prefs.getvalues(
> 'height', 'width', 'papersize',
> defaults=DEFAULTS,
> missing=None
> )
>
>
> A basic implementation might be:
>
> # Untested.
> def getvalues(self, *keys, pop=False, defaults=None, missing=SENTINEL):
> values = []
> for key in keys:
> try:
> x = self[key]
> except KeyError:
> if defaults is not None:
> x = defaults.get(key, SENTINEL)
> if x is SENTINEL:
> x = missing
> if x is SENTINEL:
> raise KeyError('missing key %r' % key)
> if pop:
> del self[key]
> values.append(x)
> return tuple(values)
>
>
>
> It's a bit repetitive for the common case where keys are the same as the
> assignment targets, but that's a hard problem to solve, and besides,
> "explicit is better than implicit".
>
> It also doesn't really work well for the case where you want to blindly
> create new assignment targets for
> *every* key, but:
>
> - my recollection is that nobody really came up with a convincing
> use-case for this (apologies if I missed any);
>
> - and if you really need this, you can do:
>
> locals().update(mapping)
>
> inside a class body or at the top-level of the module (but not inside a
> function).
>
> Please, let's save a lot of discussion here and now, and just read the
> 2016 thread: it is extremely comprehensive.
>
>
> --
> Steve
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Dictionary destructing and unpacking.
On Wed, Jun 07, 2017 at 06:14:08PM +, Nick Humrich wrote:
> It would be cool to have a syntax that would unpack the dictionary to
> values based on the names of the variables. Something perhaps like:
>
> a, b, c = **mydict
This was discussed (briefly, to very little interest) in March/April
2008:
https://mail.python.org/pipermail/python-ideas/2008-March/001511.html
https://mail.python.org/pipermail/python-ideas/2008-April/001513.html
and then again in 2016, when it spawned a very large thread starting
here:
https://mail.python.org/pipermail/python-ideas/2016-May/040430.html
I know there's a lot of messages, but I STRONGLY encourage anyone,
whether you are for or against this idea, to read the previous
discussion before continuing it here.
Guido was luke-warm about the **mapping syntax:
https://mail.python.org/pipermail/python-ideas/2016-May/040466.html
Nathan Schneider proposed making dict.values() take optional key names:
https://mail.python.org/pipermail/python-ideas/2016-May/040517.html
Guido suggested that this should be a different method:
https://mail.python.org/pipermail/python-ideas/2016-May/040518.html
My recollection is that the discussion evertually petered out with a
more-or-less consensus that having a dict method (perhaps "getvalues"?)
plus regular item unpacking is sufficient for the common use-case of
unpacking a subset of keys:
prefs = {'width': 80, 'height': 200, 'verbose': False, 'mode': PLAIN,
'name': 'Fnord', 'flags': spam|eggs|cheese, ... }
# dict includes many more items
width, height, size = prefs.getvalues(
'width', 'height', 'papersize',
)
This trivially supports the cases where keys are not strings or valid
identifiers:
class_, spam, eggs = mapping.getvalues('class', 42, '~')
It easily supports assignment targets which aren't simple variable
names:
obj.attribute[index], spam().attr = mapping.getvalues('foo', 'bar')
An optional (defaults to False) "pop" keyword argument supports
extracting and removing values from the dict in one call, which is
commonly needed inside __init__ methods with **kwargs:
class K(parent):
def __init__(self, a, b, c, **kwargs):
self.spam = kwargs.pop('spam')
self.eggs = kwargs.pop('eggs')
self.cheese = kwargs.pop('cheese')
super().__init__(a, b, c, **kwargs)
becomes:
self.spam, self.eggs, self.cheese = kwargs.getvalues(
'spam eggs cheese'.split(), pop=True
)
I don't recall this being proposed at the time, but we could support
keyword arguments for missing or default values:
DEFAULTS = {'height': 100, 'width': 50}
prefs = get_prefs() # returns a dict
height, width, size = prefs.getvalues(
'height', 'width', 'papersize',
defaults=DEFAULTS,
missing=None
)
A basic implementation might be:
# Untested.
def getvalues(self, *keys, pop=False, defaults=None, missing=SENTINEL):
values = []
for key in keys:
try:
x = self[key]
except KeyError:
if defaults is not None:
x = defaults.get(key, SENTINEL)
if x is SENTINEL:
x = missing
if x is SENTINEL:
raise KeyError('missing key %r' % key)
if pop:
del self[key]
values.append(x)
return tuple(values)
It's a bit repetitive for the common case where keys are the same as the
assignment targets, but that's a hard problem to solve, and besides,
"explicit is better than implicit".
It also doesn't really work well for the case where you want to blindly create
new assignment targets for
*every* key, but:
- my recollection is that nobody really came up with a convincing
use-case for this (apologies if I missed any);
- and if you really need this, you can do:
locals().update(mapping)
inside a class body or at the top-level of the module (but not inside a
function).
Please, let's save a lot of discussion here and now, and just read the
2016 thread: it is extremely comprehensive.
--
Steve
___
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] Dictionary destructing and unpacking.
On Jun 7, 2017 5:54 PM, "Erik" wrote: On 07/06/17 23:42, C Anthony Risinger wrote: > Neither of these are really comparable to destructuring. > No, but they are comparable to the OP's suggested new built-in method (without requiring each mapping type - not just dicts - to implement it). That was what _I_ was responding to. No worries, I only meant to emphasize that destructuring is much much more powerful and less verbose/duplicative than anything based on functions. It could readily apply/fallback against any object's __dict__ because maps underpin the entire Python object system. -- C Anthony [mobile] ___ 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] Dictionary destructing and unpacking.
On Jun 7, 2017 5:42 PM, "C Anthony Risinger" wrote:
On Jun 7, 2017 5:15 PM, "Matt Gilson" wrote:
On Wed, Jun 7, 2017 at 3:11 PM, Erik wrote:
> On 07/06/17 19:14, Nick Humrich wrote:
>
>> a, b, c = mydict.unpack('a', 'b', 'c')
>>
>
> def retrieve(mapping, *keys):
>return (mapping[key] for key in keys)
>
>
>
Or even:
from operator import itemgetter
retrieve = itemgetter('a', 'b', 'c')
a, b, c = retrieve(dictionary)
Neither of these are really comparable to destructuring. If you take a look
at how Erlang and Elixir do it, and any related code, you'll find it used
constantly, all over the place. Recent ECMAScript is very similar, allowing
both destructuring into vars matching the key names, or arbitrary var
names. They both allow destructuring in the function header (IIRC python
can do this with at least tuples). Erlang/Elixir goes beyond this by using
the pattern matching to select the appropriate function clause within a
function definition, but that's less relevant to Python.
This feature has been requested before. It's easily one of the most, if not
the top, feature I personally wish Python had. Incredibly useful and
intuitive, and for me again, way more generally applicable than iterable
unpacking. Maps are ubiquitous.
Also in the Erlang/Elixir (not sure about ECMAScript) the destructuring is
about both matching *and* assignment. So something like this (in Python):
payload = {"id": 123, "data": {...}}
{"id": None, "data": data} = payload
Would raise a MatchError or similar. It's a nice way to assert some values
and bind others in one shot. Those languages often use atoms for keys
though, which typically don't require quoting (and ECMAScript is more lax),
so that extended format is less useful and pretty if the Python variant
expected quotes all over the place.
--
C Anthony [mobile]
___
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] Dictionary destructing and unpacking.
* locals().update(mydict) 2017-06-08 0:59 GMT+02:00 Antoine Rozo : > I think you want something similar to locals.update(mydict)? > > 2017-06-08 0:54 GMT+02:00 Erik : > >> On 07/06/17 23:42, C Anthony Risinger wrote: >> >>> Neither of these are really comparable to destructuring. >>> >> >> No, but they are comparable to the OP's suggested new built-in method >> (without requiring each mapping type - not just dicts - to implement it). >> That was what _I_ was responding to. >> >> >> E. >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > > -- > Antoine Rozo > -- Antoine Rozo ___ 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] Dictionary destructing and unpacking.
I think you want something similar to locals.update(mydict)? 2017-06-08 0:54 GMT+02:00 Erik : > On 07/06/17 23:42, C Anthony Risinger wrote: > >> Neither of these are really comparable to destructuring. >> > > No, but they are comparable to the OP's suggested new built-in method > (without requiring each mapping type - not just dicts - to implement it). > That was what _I_ was responding to. > > > E. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ 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] Dictionary destructing and unpacking.
On 07/06/17 23:42, C Anthony Risinger wrote: Neither of these are really comparable to destructuring. No, but they are comparable to the OP's suggested new built-in method (without requiring each mapping type - not just dicts - to implement it). That was what _I_ was responding to. E. ___ 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] Dictionary destructing and unpacking.
On Jun 7, 2017 5:15 PM, "Matt Gilson" wrote:
On Wed, Jun 7, 2017 at 3:11 PM, Erik wrote:
> On 07/06/17 19:14, Nick Humrich wrote:
>
>> a, b, c = mydict.unpack('a', 'b', 'c')
>>
>
> def retrieve(mapping, *keys):
>return (mapping[key] for key in keys)
>
>
>
Or even:
from operator import itemgetter
retrieve = itemgetter('a', 'b', 'c')
a, b, c = retrieve(dictionary)
Neither of these are really comparable to destructuring. If you take a look
at how Erlang and Elixir do it, and any related code, you'll find it used
constantly, all over the place. Recent ECMAScript is very similar, allowing
both destructuring into vars matching the key names, or arbitrary var
names. They both allow destructuring in the function header (IIRC python
can do this with at least tuples). Erlang/Elixir goes beyond this by using
the pattern matching to select the appropriate function clause within a
function definition, but that's less relevant to Python.
This feature has been requested before. It's easily one of the most, if not
the top, feature I personally wish Python had. Incredibly useful and
intuitive, and for me again, way more generally applicable than iterable
unpacking. Maps are ubiquitous.
--
C Anthony [mobile]
___
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] Dictionary destructing and unpacking.
On Wed, Jun 7, 2017 at 3:11 PM, Erik wrote:
> On 07/06/17 19:14, Nick Humrich wrote:
>
>> a, b, c = mydict.unpack('a', 'b', 'c')
>>
>
> def retrieve(mapping, *keys):
>return (mapping[key] for key in keys)
>
>
>
Or even:
from operator import itemgetter
retrieve = itemgetter('a', 'b', 'c')
a, b, c = retrieve(dictionary)
>
> $ python3
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> def retrieve(mapping, *keys):
> ... return (mapping[key] for key in keys)
> ...
> >>> d = {'a': 1, 'b': None, 100: 'Foo' }
> >>> a, b, c = retrieve(d, 'a', 'b', 100)
> >>> a, b, c
> (1, None, 'Foo')
>
>
> E.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Matt Gilson | Pattern
Software Engineer
getpattern.com
___
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] Dictionary destructing and unpacking.
On 07/06/17 19:14, Nick Humrich wrote:
a, b, c = mydict.unpack('a', 'b', 'c')
def retrieve(mapping, *keys):
return (mapping[key] for key in keys)
$ python3
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def retrieve(mapping, *keys):
... return (mapping[key] for key in keys)
...
>>> d = {'a': 1, 'b': None, 100: 'Foo' }
>>> a, b, c = retrieve(d, 'a', 'b', 100)
>>> a, b, c
(1, None, 'Foo')
E.
___
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] Dictionary destructing and unpacking.
In python, we have beautiful unpacking:
a, b, c = [1,2,3]
and even
a, b, *c = [1,2,3,4,5]
We also have dictionary destructing for purposes of keywords:
myfunc(**mydict)
You can currently unpack a dictionary, but its almost certainly not what
you would intend.
a, b, c = {'a': 1, 'c': 3, 'b': 2}.values()
In python 3.6+ this is better since the dictionary is insertion-ordered,
but is still not really what one would probably want.
It would be cool to have a syntax that would unpack the dictionary to
values based on the names of the variables. Something perhaps like:
a, b, c = **mydict
which would assign the values of the keys 'a', 'b', 'c' to the variables.
The problem with this approach is that it only works if the key is also a
valid variable name. Another syntax could potentially be used to specify
the keys you care about (and the order). Perhaps:
a, b, c = **mydict('a', 'b', 'c')
I dont really like that syntax, but it gives a good idea.
One way to possibly achieve this today without adding syntax support could
be simply adding a builtin method to the dict class:
a, b, c = mydict.unpack('a', 'b', 'c')
The real goal of this is to easily get multiple values from a dictionary.
The current ways of doing this are:
a, b, c, = mydict['a'], mydict['b'], mydict['c']
or
a = mydict['a']
b = mydict['b']
c = mydict['c']
The later seams to be more common. Both are overly verbose in my mind.
One thing to consider however is the getitem vs get behavior. mydict['a']
would raise a KeyError if 'a' wasnt in the dict, whereas mydict.get('a')
would return a "default" (None if not specified). Which behavior is chosen?
Maybe there is no clean solutions, but those are my thoughts. Anyone have
feedback/ideas on this?
Nick
___
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] π = math.pi
On 2017-06-07 02:03, Mikhail V wrote: > Greg Ewing wrote: > >> Steven D'Aprano wrote: >>> There's not much, if any, benefit to writing: >>> >>> ∫(expression, lower_limit, upper_limit, name) > >> More generally, there's a kind of culture clash between mathematical >> notation and programming notation. Mathematical notation tends to >> almost exclusively use single-character names, relying on different >> fonts and alphabets, and superscripts and subscripts, to get a large >> enough set of identifiers. Whereas in programming we use a much >> smaller alphabet and longer names. > > That's probably because mathematicians grown up writing > everything with a chalk on a blackboard. > Hands are tired after hours of writing and blackboards > are limitited, need to erase everything and start over. > Also don't forget that mathematical formalism is *always* accompanied by an explanation of what the symbols mean in the particular situation (either orally by the person doing the writing, or in prose if it's in a paper or book). Valid code, no matter how badly chosen the identifier names, is always self-explanatory (at least to the computer); a mathematical formula almost never is. > I find actually symbols ≤ ≥ (inclusive comparison) > nice. They look ok and have usage in context of writing > code. > But that's merely an exception in world of math symbols. > OTOH I'm strongly against unicode. > > > > Mikhail > ___ > 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] π = math.pi
As already mentioned, Vim can display <= as ≤ using the ' conceal' feature. (And in fact arbitrary substitutions, of course.) Stephan Op 7 jun. 2017 8:48 a.m. schreef "Brice PARENT" : Le 07/06/17 à 07:34, Greg Ewing a écrit : > Yes, there are a few symbols it would be nice to have. > A proper ≠ symbol would have avoided the wars between > <> and !=. :-) > I'm not sure it's worth any change in the language, it's already really easy to read and write as is. But I agree this can be great to have for example for reviewers (Python being what it is, you can have reviewers who are not really pythonistas but just here to check the logic and maths for example). And it's already available by using some fonts that provide a good ligature support, like Fira Code (https://twitter.com/pycharm/status/804786040775045123?lang=fr). I'm not sure about the support in other editors/terminals tho. ___ 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/
