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] Overriding stdlib http package
On 2015-01-24 7:17 AM, Donald Stufft wrote: It’s not just power users that it’s good for, it makes it harder for even beginners to use things like backports of modules. What about cases where new module versions are put in as dependencies of other packages and they stomp standard library packages unbeknownst to the user installing the higher level package? For example, let's say packageB overrides stdlib's packageA. packageC requires packageB, which stomps packageA at import time. Now, author of packageD requires packageC but is unaware of the fact that packageB overrides packageA, but heavily uses packageA directly and expects the stdlib behavior, not the modified behavior in packageB. (Hope I got the hierarchy right in that description ;)) This would likely cause unexpected behavior and I can only assume that it would likely be quite difficult to track down, even for a power user. The same logic applies to unrelated stdlib modules that depend on the stdlib behavior of packageA as Brett pointed out. As someone who's recently faced the problem, while making it easier would have been immediately beneficial to me as the module author, I can understand the reasoning behind making this a difficult thing to do. I /do/ think that it might be worthwhile to invest some time in making it easier to do while still satisfying the safety of other packages, but I would venture to say it would definitely be non-trivial. 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 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] Pydoc Replacement for Python's help()?
Looking at pydoc.py, it looks like the Tk is purely optional...and isn't called from the interpreter. (I'm not a core dev, though, so take that with a grain of salt.) However, can't you just strip out the gui function and the one place in the file where it's called? Again, not a main Python developer, so don't take this too seriously! On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton chasel...@gmail.com wrote: Hello, I've finally managed to build a (somewhat) working Python port for the Android tablet I'm using. Unfortunately, as I quickly found out, Python's built-in help function requires tkinter, which requires tcl/tk. I did download the sources for tcl/tk and built tcl, but found out that tk requires XWindows libraries and includes. Long story short: Is there an alternative documentation system (i.e. epydoc) that does not have tkinter dependencies? If so, is there a parameter or env variable that would allow me to use it instead of pydoc? Thanks in advance, Cyd ___ 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/rymg19%40gmail.com -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated. Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ ___ 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] is a new buildbot gps-debian-profile-opt possible?
Of course. I hadn't had time to answer your private e-mail but will do so soon :-) Regards Antoine. On Mon, 26 Jan 2015 17:24:31 + Gregory P. Smith g...@krypto.org wrote: I want this buildbot to run make profile-opt instead of make all and it'd be best if it could _not_ have --with-pydebug on the ./configure command line. I've got a small VM at the moment with one CPU and 600mb ram so just give it a make -j2 at most to start with. If that is possible, please assign the new buildbot name and password for me and i'll get it up and running. motivation for such a buildbot: https://bugs.python.org/issue22904 and any potential similar issues. fwiw, the major linux distros ship with profile-opt interpreter builds as they are significantly faster. thanks, -gps ___ 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] Python bug tracker Roundup
Do we have our own mailing list for Roundup? I'm trying to fix the Activity Date search bug (only returns issues where the *last* activity was on a date, not *any* activity on a date). -- ~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 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
[Python-Dev] Pydoc Replacement for Python's help()?
Hello, I've finally managed to build a (somewhat) working Python port for the Android tablet I'm using. Unfortunately, as I quickly found out, Python's built-in help function requires tkinter, which requires tcl/tk. I did download the sources for tcl/tk and built tcl, but found out that tk requires XWindows libraries and includes. Long story short: Is there an alternative documentation system (i.e. epydoc) that does not have tkinter dependencies? If so, is there a parameter or env variable that would allow me to use it instead of pydoc? Thanks in advance, Cyd ___ 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] Pydoc Replacement for Python's help()?
On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton chasel...@gmail.com wrote: Unfortunately, as I quickly found out, Python's built-in help function requires tkinter, which requires tcl/tk. I'm a little confused. Are you using some sort of freeze system which is deciding Tkinter is required? I use help() all the time from the interpreter prompt and never get a GUI. IMO you should be able to strip out the gui() function (or even just comment out the Tkinter import). 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 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
[Python-Dev] is a new buildbot gps-debian-profile-opt possible?
I want this buildbot to run make profile-opt instead of make all and it'd be best if it could _not_ have --with-pydebug on the ./configure command line. I've got a small VM at the moment with one CPU and 600mb ram so just give it a make -j2 at most to start with. If that is possible, please assign the new buildbot name and password for me and i'll get it up and running. motivation for such a buildbot: https://bugs.python.org/issue22904 and any potential similar issues. fwiw, the major linux distros ship with profile-opt interpreter builds as they are significantly faster. thanks, -gps ___ 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] Pydoc Replacement for Python's help()?
On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton chasel...@gmail.com wrote: Hello, I've finally managed to build a (somewhat) working Python port for the Android tablet I'm using. Unfortunately, as I quickly found out, Python's built-in help function requires tkinter, which requires tcl/tk. What version of Python are you building, and how did you call help that it seems to want to use tkinter? The pydoc GUI was removed from the 3.x series long ago, and should only be activated in 2.7 if you call it as 'pydoc -g ...' from the command line (or use pydoc.gui() directly). -- Zach ___ 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] Python bug tracker Roundup
On 01/26/2015 09:25 PM, Ethan Furman wrote: Do we have our own mailing list for Roundup? I'm trying to fix the Activity Date search bug (only returns issues where the *last* activity was on a date, not *any* activity on a date). That would be tracker-discuss. 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] Python bug tracker Roundup
On Mon, Jan 26, 2015 at 10:25 PM, Ethan Furman et...@stoneleaf.us wrote: Do we have our own mailing list for Roundup? Hi, Yes: https://mail.python.org/mailman/listinfo/tracker-discuss There is also a tracker for bugs.p.o: http://psf.upfronthosting.co.za/roundup/meta/ --Berker ___ 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
