Re: [Python-Dev] Any grammar experts?
On Tue, 27 Jan 2015 00:07:08 +0100, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 16:28:24 -0500 > "R. David Murray" 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 2015-01-26 19:39, Petr Viktorin wrote: On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman 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 "", line 1, in TypeError: foo() got multiple values for keyword argument 'a' and on the other hand we have: >>> foo(a=12, a=13) File "", 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 Mon, 26 Jan 2015 16:28:24 -0500 "R. David Murray" 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 Mon, 26 Jan 2015 22:05:44 +0100, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 12:22:20 -0800 > Ethan Furman wrote: > > On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > > > On Mon, 26 Jan 2015 12:06:26 -0800 > > > Ethan Furman 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 12:22:20 -0800 Ethan Furman wrote: > On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > > On Mon, 26 Jan 2015 12:06:26 -0800 > > Ethan Furman 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 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 25.01.15 17:08, Antoine Pitrou wrote: On Sat, 24 Jan 2015 21:10:51 -0500 Neil Girdhar 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 01/26/2015 07:25 PM, Skip Montanaro wrote: > On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou 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 01/26/2015 12:09 PM, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 12:06:26 -0800 > Ethan Furman 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?
-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 Design"http://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 Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman 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:39 AM, Petr Viktorin wrote: > On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman 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?
On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman 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 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 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 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 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 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 26 January 2015 at 18:12, Antoine Pitrou 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 Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou 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 Mon, 26 Jan 2015 10:46:02 -0500 "R. David Murray" wrote: > On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw 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, 26 Jan 2015 09:43:26 -0500, Barry Warsaw 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 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 01:21:24 +0100, Antoine Pitrou wrote: > On Sun, 25 Jan 2015 14:59:42 -0800 > Guido van Rossum wrote: > > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > > > > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > > > On Sat, 24 Jan 2015 21:10:51 -0500 > > > > Neil Girdhar 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?
On Sun, 25 Jan 2015 14:59:42 -0800 Guido van Rossum wrote: > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > > On Sat, 24 Jan 2015 21:10:51 -0500 > > > Neil Girdhar 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 Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > On Sat, 24 Jan 2015 21:10:51 -0500 > > Neil Girdhar 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 01/25/2015 04:08 PM, Antoine Pitrou wrote: > On Sat, 24 Jan 2015 21:10:51 -0500 > Neil Girdhar 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 Sat, 24 Jan 2015 21:10:51 -0500 Neil Girdhar 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?
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 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 > 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?
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 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
[Python-Dev] Any grammar experts?
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/archive%40mail-archive.com