Re: [Python-ideas] Why not ['a','b','c'].join(',') ?
On 3/23/2019 7:35 PM, Juancarlo Añez wrote: I know it has been discussed endlessly, So please read any of the endless discussions either on this list or python-list. I myself have answered multiple times. -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Why not ['a','b','c'].join(',') ?
I know it has been discussed endlessly, so just a gentle reminder about the final arguments would be good. I think I remember it was discussed recently, mentioning that join() doesn't convert elements to strings? This came up while reading this speculative article about how programmers migrate from one programming language to the other (I call it speculative because there's no hard data, but the conclusions and comments pretty much match my experience and my observations over decades [I would add an arrow from Python3 to Rust]). https://apenwarr.ca/log/20190318 In that sense, I think it wouldn't hurt to make Python more familiar/friendly to people coming from other languages, even if it breaks "There should be one-- and preferably only one --obvious way to do it." -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 2:43 PM Andre Roberge wrote: > My original message was referring to someone writing ":" instead of "=" by > mistake -- nothing to do with the walrus assignment, but rather using the > same notation to assign a value to a key as they would when defining a dict. > OK, I read your Original Post for this thread, about accidentally writing `d["answer"]: 42` instead of `d["answer"] = 42`. My reaction is that this was a user mistake of the same kind as accidentally writing `x + 1` instead of `x += 1`. That's just going to happen, very occasionally. (Though why? The ':' and '=' keys are not that close together.) Read your code carefully, or in an extreme case step through it in a debugger, and you'll notice the mistake. It's not a reason to pick on that particular syntax, and not much of a reason to try and introduce a mechanism to disable type hints. Sorry. PS. This particular syntax was introduced by PEP 526, and introduced in Python 3.6. -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 6:26 PM Ned Batchelder wrote: > On 3/23/19 1:37 PM, Gregory P. Smith wrote: > > Sure, someone is going to typo and omit the = from a := assignment in > > 3.8 but the walrus is unlikely to be used outside of an conditional or > > loop test context so this seems like a made up problem. > My original message was referring to someone writing ":" instead of "=" by mistake -- nothing to do with the walrus assignment, but rather using the same notation to assign a value to a key as they would when defining a dict. André Roberge > > Walruses aren't allowed as a top-level expression anyway: > > Python 3.8.0a2 (default, Feb 25 2019, 17:15:37) > [Clang 10.0.0 (clang-1000.10.44.4)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> d["answer"] := 42 >File "", line 1 > d["answer"] := 42 > ^ > SyntaxError: invalid syntax > > > --Ned. > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On 3/23/19 1:37 PM, Gregory P. Smith wrote: Sure, someone is going to typo and omit the = from a := assignment in 3.8 but the walrus is unlikely to be used outside of an conditional or loop test context so this seems like a made up problem. Walruses aren't allowed as a top-level expression anyway: Python 3.8.0a2 (default, Feb 25 2019, 17:15:37) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d["answer"] := 42 File "", line 1 d["answer"] := 42 ^ SyntaxError: invalid syntax --Ned. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 12:44:29PM -0700, Gregory P. Smith wrote: > Unfortunately that isn't what PEP 526 said: > https://www.python.org/dev/peps/pep-0526/#annotating-expressions Which part though? I'd understand ... (x): int # Annotates x with int, (x) treated as expression by compiler. ... to mean that the expression is also evaluated if no assignment takes place. Stefan Krah ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 11:00 AM Stefan Krah wrote:
> On Sat, Mar 23, 2019 at 10:37:43AM -0700, Gregory P. Smith wrote:
> > A useless statement like that isn't likely to be typed. I've never seen
> > anyone do that.
>
> Unlikely yes, but ideally type annotations should not alter program
> behavior:
>
> >>> d = {}
> >>> try: d["x"]
> ... except KeyError: print("KeyError")
> ...
> KeyError
> >>>
> >>> d = {}
> >>> try: d["x"] : int
> ... except KeyError: print("KeyError")
> ...
>
Unfortunately that isn't what PEP 526 said:
https://www.python.org/dev/peps/pep-0526/#annotating-expressions
-gps
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 10:37:43AM -0700, Gregory P. Smith wrote:
> A useless statement like that isn't likely to be typed. I've never seen
> anyone do that.
Unlikely yes, but ideally type annotations should not alter program behavior:
>>> d = {}
>>> try: d["x"]
... except KeyError: print("KeyError")
...
KeyError
>>>
>>> d = {}
>>> try: d["x"] : int
... except KeyError: print("KeyError")
...
Stefan Krah
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 7:37 AM Andre Roberge
wrote:
> Consider the following example [1]:
>
> Python 3.7.0 (v3.7.0:1bf9cc5093...
> >>> d = {
> ... "injury": "flesh wound"
> ... }
> >>> d["answer"]: 42
> >>> if "answer" in d:
> ... print("Don't panic!")
> ... else:
> ... print("Sorry, I can't help you.")
> ...
> Sorry, I can't help you.
>
> = =
> No SyntaxError raised (which would have been the case before version 3.5?)
> and yet what could be a very unexpected result occurred.
>
> Of course, the problem is with the line
>
> d["answer"]: 42
>
> which is not an assignment but is an "optional" type hint.
>
A useless statement like that isn't likely to be typed. I've never seen
anyone do that.
Sure, someone is going to typo and omit the = from a := assignment in 3.8
but the walrus is unlikely to be used outside of an conditional or loop
test context so this seems like a made up problem. (if anything, this
possibility encourages people not to use the walrus in unintended places).
Someone might also typo it by meaning to use a ; for multiple statements
but enter : instead. Again, very rare. Because ; is frowned upon.
A linter (running live as part of an editor/ide these days) can flag most
meaningless annotations quite easily.
I think it would be very useful to have a way to turn off completely type
> hinting and flag any use of code like the above as a SyntaxError.
>
> My preference would be if type hinting would be something that is enabled
> per file with a top-level comment pragma, something like
>
> # type: enable
>
> Failing that, having a to-level comment pragma like
>
> # type: disable
>
Too late. Requiring something like that would break existing code.
might be acceptable as it would not require any change to any existing
> file. However, the other option would be more inline with type hinting
> being "optional" and something that should not trip beginners who are not
> aware of its existence.
>
What evidence is there that this frequently trips up beginners?
Enhancing the dev environments beginners use to automatically lint would be
better and would automate some learning, handling cases way beyond this one.
-gps
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)
> > I think that's a good indication that there are uses for a merge > > operator. > > Some, yes. Enough for new syntax? Let’s be clear here — this would not be new syntax — the operator (s) already exist and are commonly used and overloaded already. This would be a minor change to the dictionary class (and maybe the Mapping ABC), not a change to the language. Are > there existing syntax features so sparsely used? I wonder how often + is used with lists in the stdlib... What is the bar for > something that adds no new function, but saves 6 chars and is easier to > understand for at least some? The “height of the bar” depends not just on how it would be used, but by how disruptive it is. As this is not nearly as disruptive as, say :=, I think the bar is pretty low. But others seem to think it would add great confusion, which would raise the bar a lot. By the way, if it isn’t used much, that also means it wouldn’t be very disruptive. :-) I’m coming down on the side of “not worth the argument” -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Enabling / disabling optional type hinting
Consider the following example [1]:
Python 3.7.0 (v3.7.0:1bf9cc5093...
>>> d = {
... "injury": "flesh wound"
... }
>>> d["answer"]: 42
>>> if "answer" in d:
... print("Don't panic!")
... else:
... print("Sorry, I can't help you.")
...
Sorry, I can't help you.
= =
No SyntaxError raised (which would have been the case before version 3.5?)
and yet what could be a very unexpected result occurred.
Of course, the problem is with the line
d["answer"]: 42
which is not an assignment but is an "optional" type hint.
I think it would be very useful to have a way to turn off completely type
hinting and flag any use of code like the above as a SyntaxError.
My preference would be if type hinting would be something that is enabled
per file with a top-level comment pragma, something like
# type: enable
Failing that, having a to-level comment pragma like
# type: disable
might be acceptable as it would not require any change to any existing
file. However, the other option would be more inline with type hinting
being "optional" and something that should not trip beginners who are not
aware of its existence.
André Roberge
[1] This example was inspired by a blog post I read yesterday and which I
cannot find; I apologize to the author of that blog post.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
