Re: [Python-Dev] Any grammar experts?
On Jan 25, 2015, at 09:31 PM, R. David Murray wrote:
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension :)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
I find all this unreadable and difficult to understand.
I did too, before reading the PEP.
After reading the PEP, it makes perfect sense to me. Nor is the PEP
complicated...it's just a matter of wrapping your head around the
generalization[*] of what are currently special cases that is going on
here.
It does make sense after reading the PEP but it also reduces the readability
and instant understanding of any such code. This is head-scratcher code that
I'm sure I'd get asked about from folks who aren't steeped in all the dark
corners of Python. I don't know if that's an argument not to adopt the PEP,
but it I think it would be a good reason to recommend against using such
obscure syntax, unless there's a good reason (and good comments!).
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw ba...@python.org wrote:
On Jan 25, 2015, at 09:31 PM, R. David Murray wrote:
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension
:)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
I find all this unreadable and difficult to understand.
I did too, before reading the PEP.
After reading the PEP, it makes perfect sense to me. Nor is the PEP
complicated...it's just a matter of wrapping your head around the
generalization[*] of what are currently special cases that is going on
here.
It does make sense after reading the PEP but it also reduces the readability
and instant understanding of any such code. This is head-scratcher code that
I'm sure I'd get asked about from folks who aren't steeped in all the dark
corners of Python. I don't know if that's an argument not to adopt the PEP,
but it I think it would be a good reason to recommend against using such
obscure syntax, unless there's a good reason (and good comments!).
But it is only obscure because we are not used to it yet. It is a
logical extension of Python's existing conventions once you think about
it. It will become obvious quickly, IMO.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman et...@stoneleaf.us wrote: It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that the same key could be in more than one of the dictionaries then you still have to do the dict.update(another_dict) So what? Is the situation where chaining is desirable common enough? Not every new feature warrants a syntax addition - especially when it raises eyebrows as here, and ends up being as obscure as Perl code. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 11:24 AM, Barry Warsaw wrote:
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/ from_env.
So which is it?
In the face of ambiguity, refuse the temptation to guess.
Lots of things are ambiguous until one learns the rules. ;)
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/26/2015 11:24 AM, Barry Warsaw wrote:
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/
from_env.
So which is it?
In the face of ambiguity, refuse the temptation to guess.
Lots of things are ambiguous until one learns the rules. ;)
I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent
to `f(a=12, **{'a':13})` – iow, raise TypeError.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 10:40 AM, Paul Moore wrote:
There *are* some nastily non-intuitive corner cases (for example, if
from_env={'a':12} and from_config={'a':13}, I don't have any sort of
intuition as to what a would be in f(**from_env, **from_config). I'd
go with 12 because the PEP links multiple **-unpackings with
collections.ChainMap, but I wouldn't dare rely on that guess).
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/ from_env.
So which is it?
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 10:55 AM, Ethan Furman wrote:
On 01/26/2015 10:40 AM, Paul Moore wrote:
There *are* some nastily non-intuitive corner cases (for example, if
from_env={'a':12} and from_config={'a':13}, I don't have any sort of
intuition as to what a would be in f(**from_env, **from_config). I'd
go with 12 because the PEP links multiple **-unpackings with
collections.ChainMap, but I wouldn't dare rely on that guess).
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/ from_env.
So which is it?
Going to the PEP:
kwargs = dict(kw_arguments)
kwargs.update(more_arguments)
function(**kwargs)
or, if you know to do so:
from collections import ChainMap
function(**ChainMap(more_arguments, arguments))
I see the arguments to ChainMap are reversed (more_arguments is first), so in
Paul's example 'a' would be 13.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, Jan 26, 2015 at 12:55 PM, Ethan Furman et...@stoneleaf.us wrote: So which is it? Precisely... S ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/ from_env.
So which is it?
In the face of ambiguity, refuse the temptation to guess.
Cheers,
-Barry
pgpQ9ie65GEHm.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 11:39 AM, Petr Viktorin wrote:
On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/26/2015 11:24 AM, Barry Warsaw wrote:
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/
from_env.
So which is it?
In the face of ambiguity, refuse the temptation to guess.
Lots of things are ambiguous until one learns the rules. ;)
I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent
to `f(a=12, **{'a':13})` – iow, raise TypeError.
It destroy's the chaining value and pretty much makes the improvement not an
improvement. If there's a possibility that
the same key could be in more than one of the dictionaries then you still have
to do the
dict.update(another_dict)
dance.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2015 09:43 AM, Barry Warsaw wrote: This is head-scratcher code that I'm sure I'd get asked about from folks who aren't steeped in all the dark corners of Python. I don't know if that's an argument not to adopt the PEP, but it I think it would be a good reason to recommend against using such obscure syntax, unless there's a good reason Heh, 2003 called, and they want their list incomprehension debate back. ;) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlTGoNcACgkQ+gerLs4ltQ4AWQCfQ/zjosbaC6YcPItzmxZer/oW f/cAoLwXzzfHV2LhT4AZD/KS31TkKJyI =Oxqm -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 12:09 PM, Antoine Pitrou wrote: On Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman et...@stoneleaf.us wrote: It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that the same key could be in more than one of the dictionaries then you still have to do the dict.update(another_dict) So what? Is the situation where chaining is desirable common enough? Common enough to not break it, yes. Not every new feature warrants a syntax addition - especially when it raises eyebrows as here, and ends up being as obscure as Perl code. Not sure what you mean here -- the new feature is a syntax addition (or more appropriately a generalization of existing syntax). -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 10:46:02 -0500
R. David Murray rdmur...@bitdance.com wrote:
On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw ba...@python.org wrote:
On Jan 25, 2015, at 09:31 PM, R. David Murray wrote:
{*x for x in it}
which is a set comprehension, while the other is a dict
comprehension :)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
I find all this unreadable and difficult to understand.
I did too, before reading the PEP.
After reading the PEP, it makes perfect sense to me. Nor is the PEP
complicated...it's just a matter of wrapping your head around the
generalization[*] of what are currently special cases that is going on
here.
It does make sense after reading the PEP but it also reduces the readability
and instant understanding of any such code. This is head-scratcher code
that
I'm sure I'd get asked about from folks who aren't steeped in all the dark
corners of Python. I don't know if that's an argument not to adopt the PEP,
but it I think it would be a good reason to recommend against using such
obscure syntax, unless there's a good reason (and good comments!).
But it is only obscure because we are not used to it yet. It is a
logical extension of Python's existing conventions once you think about
it. It will become obvious quickly, IMO.
I have to agree with Barry. While the following is obvious even without
having ever used it:
a, b, *c = range(5)
the following makes me scratch my head and I can't seem to guess what
the *intent* is - which is very problematic when e.g. reviewing code:
[*x for x in it]
{**x for x in it}
(and other similar things)
I also think the multiple-starargs function calls are completely
overboard:
f(**someargs, **someotherargs)
(I might add I've never felt any need for those)
These generalizations look to me like a case of consistency taken too
far. When some construct needs commenting to be understandable, then
probably that construct shouldn't exist at all.
(yes, I should have reacted earlier. I hadn't realized the PEP
went that far. It seemed short and simple so I didn't look
carefully :-))
By the way, when reading https://www.python.org/dev/peps/pep-0448/, I
can't find a reference to the final pronouncement.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou solip...@pitrou.net wrote: I also think the multiple-starargs function calls are completely overboard: f(**someargs, **someotherargs) (I might add I've never felt any need for those) This makes sense to me, but I wonder how you resolve the case of overlapping keys. I will note that pylint complains about any use of *args or **kwds (calling it magic), which seems a bit overboard to me. There's nothing magic in the current implementation as far as I can see. I wonder if it makes sense for pylint to allow simple use (basically, the status quo) to fly by silently, but start to chirp when people use the facility in all its baroque glory as enabled by the PEP. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 26 January 2015 at 18:12, Antoine Pitrou solip...@pitrou.net wrote:
I have to agree with Barry. While the following is obvious even without
having ever used it:
a, b, *c = range(5)
the following makes me scratch my head and I can't seem to guess what
the *intent* is - which is very problematic when e.g. reviewing code:
[*x for x in it]
{**x for x in it}
(and other similar things)
I also think the multiple-starargs function calls are completely
overboard:
f(**someargs, **someotherargs)
(I might add I've never felt any need for those)
These cases made little sense to me when I first saw them here, but a
quick read of the PEP made them feel reasonably straightforward - *x
is essentially splicing in a list, and a sequence of **x is a sort of
if you don't find it here, look here fallback mechanism. Also, real
examples would presumably have clearer variable names, and maybe even
an explanatory comment. And if they don't, they should do (and a code
review that said this is confusing, add a comment would seem
entirely appropriate to me).
There *are* some nastily non-intuitive corner cases (for example, if
from_env={'a':12} and from_config={'a':13}, I don't have any sort of
intuition as to what a would be in f(**from_env, **from_config). I'd
go with 12 because the PEP links multiple **-unpackings with
collections.ChainMap, but I wouldn't dare rely on that guess).
My feeling is that the PEP is essentially fine, but the
Disadvantages section needs expansion to note (in a reasonable
amount of detail) that it's possible to write very obfuscated code
with these constructs. It should also call out the corner cases and
note that the behaviour, although following from the rules, isn't
obvious. Personally, I don't think the resulting disadvantages are so
bad that the PEP needs to be rejected, it's just a matter of being
open about the potential for unclear code.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/26/2015 07:25 PM, Skip Montanaro wrote: On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou solip...@pitrou.net wrote: I also think the multiple-starargs function calls are completely overboard: f(**someargs, **someotherargs) (I might add I've never felt any need for those) This makes sense to me, but I wonder how you resolve the case of overlapping keys. I will note that pylint complains about any use of *args or **kwds (calling it magic), which seems a bit overboard to me. There's nothing magic in the current implementation as far as I can see. Yeah, that's one of the sillier on-by-default warnings that I always disable immediately. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 25.01.15 17:08, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
I would understand this as
{k: v for x in it for k, v in x.items()}
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 12:22:20 -0800 Ethan Furman et...@stoneleaf.us wrote: On 01/26/2015 12:09 PM, Antoine Pitrou wrote: On Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman et...@stoneleaf.us wrote: It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that the same key could be in more than one of the dictionaries then you still have to do the dict.update(another_dict) So what? Is the situation where chaining is desirable common enough? Common enough to not break it, yes. Really? What are the use cases? Not every new feature warrants a syntax addition - especially when it raises eyebrows as here, and ends up being as obscure as Perl code. Not sure what you mean here -- the new feature is a syntax addition That's what I said. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 22:05:44 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 26 Jan 2015 12:22:20 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/26/2015 12:09 PM, Antoine Pitrou wrote:
On Mon, 26 Jan 2015 12:06:26 -0800
Ethan Furman et...@stoneleaf.us wrote:
It destroy's the chaining value and pretty much makes the improvement
not an improvement. If there's a possibility that
the same key could be in more than one of the dictionaries then you
still have to do the
dict.update(another_dict)
So what? Is the situation where chaining is desirable common enough?
Common enough to not break it, yes.
Really? What are the use cases?
My use case is a configuration method that takes keyword parameters.
In tests I want to specify a bunch of default values for the
configuration, but I want individual test methods to be able
to override those values. So I have a bunch of code that does
the equivalent of:
from test.support import default_config
[...]
def _prep(self, config_overrides):
config = default.config.copy()
config.update(config_overrides)
my_config_object.load(**config)
With the current proposal I could instead do:
def _prep(self, config_overrides):
my_config_object.load(**default_config, **config_overrides)
I suspect I have run into situations like this elsewhere as well, but
this is the one from one of my current projects.
That said, I must admit to being a bit ambivalent about this, since
we otherwise are careful to disallow duplicate argument names.
So, instead we could write:
my_config_object.load(**{**default_config, **config_overrides})
since dict literals *do* allow duplicate keys.
--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 16:28:24 -0500 R. David Murray rdmur...@bitdance.com wrote: My use case is a configuration method that takes keyword parameters. In tests I want to specify a bunch of default values for the configuration, but I want individual test methods to be able to override those values. So I have a bunch of code that does the equivalent of: from test.support import default_config [...] def _prep(self, config_overrides): config = default.config.copy() config.update(config_overrides) my_config_object.load(**config) With the current proposal I could instead do: def _prep(self, config_overrides): my_config_object.load(**default_config, **config_overrides) It sounds like the _prep() method exists once in your code base, this isn't an idiom you are duplicating everywhere. The incentive for a syntactic shortcut looks pretty thin. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 2015-01-26 19:39, Petr Viktorin wrote:
On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/26/2015 11:24 AM, Barry Warsaw wrote:
On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote:
In the your example
from_env = {'a': 12}
from_config = {'a': 13}
f(**from_env, **from_config)
I would think 'a' should be 13, as from_config is processed /after/ from_env.
So which is it?
In the face of ambiguity, refuse the temptation to guess.
Lots of things are ambiguous until one learns the rules. ;)
I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent
to `f(a=12, **{'a':13})` – iow, raise TypeError.
One the one hand we have:
foo(a=12, **{'a': 13})
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: foo() got multiple values for keyword argument 'a'
and on the other hand we have:
foo(a=12, a=13)
File stdin, line 1
SyntaxError: keyword argument repeated
(Should this be a SyntaxError?)
But we also have:
{'a': 12, 'a': 13}
{'a': 13}
So, what should:
f(**from_env, **from_config)
do if there are common keys?
Raise an exception? Behave like dict.update? Behave like ChainMap?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Tue, 27 Jan 2015 00:07:08 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 26 Jan 2015 16:28:24 -0500 R. David Murray rdmur...@bitdance.com wrote: My use case is a configuration method that takes keyword parameters. In tests I want to specify a bunch of default values for the configuration, but I want individual test methods to be able to override those values. So I have a bunch of code that does the equivalent of: from test.support import default_config [...] def _prep(self, config_overrides): config = default.config.copy() config.update(config_overrides) my_config_object.load(**config) With the current proposal I could instead do: def _prep(self, config_overrides): my_config_object.load(**default_config, **config_overrides) It sounds like the _prep() method exists once in your code base, this isn't an idiom you are duplicating everywhere. The incentive for a syntactic shortcut looks pretty thin. Something similar exists between five and ten times (I didn't go in and count) in my current code base, in various specific forms for different test classes. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 26.01.15 00:59, Guido van Rossum wrote:
Interestingly, the non-dict versions can all be written today using a
double-nested comprehension, e.g. {**x for x in it} can be written as:
{x for x in xs for xs in it}
{x for xs in it for x in xs}
But it's not so straightforward for dict comprehensions -- you'd have to
switch to calling dict():
dict(x for x in xs for xs in it)
{k: v for xs in it for k, v in xs.items()}
So actually this is just a syntax sugar.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
It appears to go a bit far. Especially since you also would have to allow
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension :)
Georg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl g.bra...@gmx.net wrote:
On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
It appears to go a bit far. Especially since you also would have to allow
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension :)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
so the original is a flattening of `it`: [*it[0], *it[1], ...]. (The type
of `it` is wider than list of lists -- it could be an iterable of
iterables. But the thing is still a flattening.)
The set flattening follows from a direct analogy. And `it` doesn't have to
be a set of sets, it still just needs to be an iterable of iterables --
it's only the flattened result that's turned into a set.
The dict comprehension follows from there -- the input must be an iterable
of iterables of (key, value) pairs.
I like the example from the PEP, a dict combining globals() and locals():
{**dictionary for dictionary in (globals(), locals())}
This could be written as
{**globals(), **locals()}
but the general case (a variable number of dicts to combine) requires the
comprehension.
The PEP also supports generator expressions that are flattenings, and again
that follows directly from analogy.
Interestingly, the non-dict versions can all be written today using a
double-nested comprehension, e.g. {**x for x in it} can be written as:
{x for x in xs for xs in it}
But it's not so straightforward for dict comprehensions -- you'd have to
switch to calling dict():
dict(x for x in xs for xs in it)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Sun, 25 Jan 2015 14:59:42 -0800
Guido van Rossum gu...@python.org wrote:
On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl g.bra...@gmx.net wrote:
On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
It appears to go a bit far. Especially since you also would have to allow
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension :)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
I find all this unreadable and difficult to understand.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
On Mon, 26 Jan 2015 01:21:24 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 25 Jan 2015 14:59:42 -0800
Guido van Rossum gu...@python.org wrote:
On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl g.bra...@gmx.net wrote:
On 01/25/2015 04:08 PM, Antoine Pitrou wrote:
On Sat, 24 Jan 2015 21:10:51 -0500
Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
Is this seriously allowed by the PEP? What does it mean exactly?
It appears to go a bit far. Especially since you also would have to allow
{*x for x in it}
which is a set comprehension, while the other is a dict comprehension :)
That distinction doesn't bother me -- you might as well claim it's
confusing that f(*x) passes positional args from x while f(**x) passes
keyword args.
And the varargs set comprehension is similar to the varargs list
comprehension:
[*x for x in it]
If `it` were a list of three items, this would be the same as
[*it[0], *it[1], *it[2]]
I find all this unreadable and difficult to understand.
I did too, before reading the PEP.
After reading the PEP, it makes perfect sense to me. Nor is the PEP
complicated...it's just a matter of wrapping your head around the
generalization[*] of what are currently special cases that is going on
here.
--David
[*] The *further* generalization...we've already had, for example,
the generalization that allows:
a, *b = (1, 3, 4)
to work, and that seems very clear to usnow.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
Have you tried it yet?
I think you have to inline dictpopulator, because dictpopulator can start
with the same tokens as test, and the parser doesn't backtrack. So it
wouldn't know how to decide whether to take the dictpopulator branch or the
set branch. If you inline it, the parser will know, because it does
something clever within the rule.
As-is, I get a lot of errors from pgen about ambiguity. This one seems to
work (but you still have to adjust the code generator of course):
dictorsetmaker: ( ((test ':' test | '**' test) (comp_for | (',' (test ':'
test | '**' test))* [','])) |
(test (comp_for | (',' test)* [','])) )
Also I presume you want a similar treatment for the set branch (replace
both tests with (test | '*' test).
Good luck! There's plenty of code to crib from for the code generation.
--Guido
On Sat, Jan 24, 2015 at 6:10 PM, Neil Girdhar mistersh...@gmail.com wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
and
{1:2, 3:4, **a}
It's been a long time since I've looked at grammars and I could really use
the advice of an expert. I'm considering replacing:
dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [','])) |
(test (comp_for | (',' test)* [','])) )
with:
dictpopulator: test ':' test | '**' test
dictorsetmaker: ( (dictpopulator (comp_for | (',' dictpopulator)* [','])) |
(test (comp_for | (',' test)* [','])) )
Am I headed in the right direction? Of course I will need to edit
parsermodule.c and ast.c.
Best,
Neil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any grammar experts?
Thanks, I had tried it and got the ambiguities, but I wasn't sure if those
would disappear with editing some peripheral file.
Yes, you're right about the set branch.
Thank you,
Neil
On Sat, Jan 24, 2015 at 10:29 PM, Guido van Rossum gu...@python.org wrote:
Have you tried it yet?
I think you have to inline dictpopulator, because dictpopulator can start
with the same tokens as test, and the parser doesn't backtrack. So it
wouldn't know how to decide whether to take the dictpopulator branch or the
set branch. If you inline it, the parser will know, because it does
something clever within the rule.
As-is, I get a lot of errors from pgen about ambiguity. This one seems to
work (but you still have to adjust the code generator of course):
dictorsetmaker: ( ((test ':' test | '**' test) (comp_for | (',' (test ':'
test | '**' test))* [','])) |
(test (comp_for | (',' test)* [','])) )
Also I presume you want a similar treatment for the set branch (replace
both tests with (test | '*' test).
Good luck! There's plenty of code to crib from for the code generation.
--Guido
On Sat, Jan 24, 2015 at 6:10 PM, Neil Girdhar mistersh...@gmail.com
wrote:
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
and
{1:2, 3:4, **a}
It's been a long time since I've looked at grammars and I could really
use the advice of an expert. I'm considering replacing:
dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' test)* [',']))
|
(test (comp_for | (',' test)* [','])) )
with:
dictpopulator: test ':' test | '**' test
dictorsetmaker: ( (dictpopulator (comp_for | (',' dictpopulator)* [',']))
|
(test (comp_for | (',' test)* [','])) )
Am I headed in the right direction? Of course I will need to edit
parsermodule.c and ast.c.
Best,
Neil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
