Re: [Python-ideas] Null coalescing operator

2016-10-28 Thread Barry Warsaw
On Oct 28, 2016, at 03:24 PM, Gustavo Carneiro wrote: >The main drawback of this type of approach is that code checking tools will >hardly ever support checking expressions inside the string like that. >Also, you don't get proper syntax highlighting, code completion, etc. > >You can do anything

Re: [Python-ideas] Leave off "else" in ternary expression

2016-10-28 Thread Sjoerd Job Postmus
On Fri, Oct 28, 2016 at 11:28:16AM -0400, Todd wrote: > The null-coalescing discussion made me think about the current ternary "x = > a if b else c" expression. In normal "if / else" clauses, the "else" is > optional. I propose doing the same thing with ternary expressions > (although I don't

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Mark Dickinson
On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan wrote: > [...] the current practicises of: > > * obj is not None (many different use cases) > * obj is not Ellipsis (in multi-dimensional slicing) Can you elaborate on this one? I don't think I've ever seen an `is not Ellipsis`

Re: [Python-ideas] Leave off "else" in ternary expression

2016-10-28 Thread Todd
That is a good point. Nevermind then. On Fri, Oct 28, 2016 at 12:20 PM, David Mertz wrote: > This seems pretty nonsensical to me. Ternaries are not only used in simple > assignments. > > E.g. 'myfunc(a, b if pred else c, d)' is common and obvious. > > 'myfunc(a, b if pred,

Re: [Python-ideas] Leave off "else" in ternary expression

2016-10-28 Thread David Mertz
This seems pretty nonsensical to me. Ternaries are not only used in simple assignments. E.g. 'myfunc(a, b if pred else c, d)' is common and obvious. 'myfunc(a, b if pred, d)' is strange with no obvious semantics. On Oct 28, 2016 11:29 AM, "Todd" wrote: > The

Re: [Python-ideas] Leave off "else" in ternary expression

2016-10-28 Thread Bernardo Sulzbach
On 10/28/2016 01:28 PM, Todd wrote: The idea would be to allow this syntax: x = a if b Which would be equivalent to: x = a if b else x What if x has not been defined yet? -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogiga...@gmail.com

Re: [Python-ideas] Leave off "else" in ternary expression

2016-10-28 Thread Todd
On Fri, Oct 28, 2016 at 11:36 AM, Bernardo Sulzbach < mafagafogiga...@gmail.com> wrote: > On 10/28/2016 01:28 PM, Todd wrote: > >> >> The idea would be to allow this syntax: >> >> x = a if b >> >> Which would be equivalent to: >> >> x = a if b else x >> >> > What if x has not been defined yet? >

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread David Mertz
On Fri, Oct 28, 2016 at 11:17 AM, Paul Moore wrote: > On 28 October 2016 at 15:40, Nick Coghlan wrote: > > I also don't think the idea is sufficiently general to be worthy of > > dedicated syntax if it's limited specifically to "is not None" checks > > -

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

2016-10-28 Thread MRAB
On 2016-08-26 13:47, Steven D'Aprano wrote: Ken has made what I consider a very reasonable suggestion, to introduce SI prefixes to Python syntax for numbers. For example, typing 1K will be equivalent to 1000. Just for the record, this is what you can now do in C++: User-Defined Literals

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Sven R. Kunze
Hi Nick, thanks for writing all of this down and composing a PEP. On 28.10.2016 10:30, Nick Coghlan wrote: 1. Do we collectively agree that "existence checking" is a useful general concept that exists in software development and is distinct from the concept of "truth checking"? Right to your

Re: [Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)

2016-10-28 Thread Sven R. Kunze
Hi Michel, hi Paul, sorry for hijacking this thread somewhat. I would like to extend this proposal a bit in order make it useful for a broader audience and to provide a real-word use-case. So, this post is just to gather general acceptance and utility of it. Michel, you specifically

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

2016-10-28 Thread Sven R. Kunze
On 28.10.2016 22:06, MRAB wrote: On 2016-08-26 13:47, Steven D'Aprano wrote: Ken has made what I consider a very reasonable suggestion, to introduce SI prefixes to Python syntax for numbers. For example, typing 1K will be equivalent to 1000. Just for the record, this is what you can now do in

Re: [Python-ideas] Showing qualified names when a function call fails

2016-10-28 Thread Sven R. Kunze
Great idea! Another issue I encounter regularly are things like: >>> func(mylist[i], mylist2[j]) IndexError: list index out of range So, which are the list and index that cause the error? On 25.10.2016 00:07, Ryan Gonzalez wrote: I personally find it kind of annoying when you have code

[Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Nick Coghlan
Hi folks, After the recent discussions of PEP 505's null-coalescing operator (and the significant confusion around why anyone would ever want a feature like that), I was inspired to put together a competing proposal that focuses more on defining a new "existence checking" protocol that

Re: [Python-ideas] Null coalescing operator

2016-10-28 Thread Barry Warsaw
On Oct 27, 2016, at 07:37 PM, Nick Badger wrote: >The problem with doing that is that it's ambiguous. There's no way of >telling which attribute is allowed to coalesce. You could of course support exactly the same syntax being proposed as a language change, e.g. from operator import

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Paul Moore
On 28 October 2016 at 15:40, Nick Coghlan wrote: > I also don't think the idea is sufficiently general to be worthy of > dedicated syntax if it's limited specifically to "is not None" checks > - None's definitely special, but it's not *that* special. Unifying > None, NaN,

Re: [Python-ideas] Showing qualified names when a function call fails

2016-10-28 Thread Chris Angelico
On Sat, Oct 29, 2016 at 8:36 AM, Sven R. Kunze wrote: > Another issue I encounter regularly are things like: > func(mylist[i], mylist2[j]) > > IndexError: list index out of range > > > So, which are the list and index that cause the error? +1. Showing the list's contents

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Nick Coghlan
On 29 October 2016 at 01:46, Ryan Gonzalez wrote: > On Oct 28, 2016 3:30 AM, "Nick Coghlan" wrote: >> *snip* >> 4. Do we collectively agree that "?then" and "?else" would be >> reasonable spellings for such operators? > > Personally, I find that kind of

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

2016-10-28 Thread Ryan Birmingham
I'd certainly be interested in hearing about how this has worked with C++, but this would certainly make scientific code less easy to misuse due to unclear units. -Ryan Birmingham On 28 October 2016 at 16:45, Sven R. Kunze wrote: > On 28.10.2016 22:06, MRAB wrote: > >> On

Re: [Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)

2016-10-28 Thread David Mertz
Yes, -1. I feel like we should add a header to all messages on this list: WARNING: PYTHON IS NOT PERL, NOR APL! I know I'm being snarky, but too many of the recent ideas feel like code golf for uncommon user cases. Or at least not common enough to warrant the cognitive burden of more syntax.

Re: [Python-ideas] PEP 531: Existence checking operators

2016-10-28 Thread Nick Coghlan
On 28 October 2016 at 23:35, Ryan Birmingham wrote: > I certainly like the concept, but I worry that use of __exists__() could > generalize it a bit beyond what you're intending in practice. It seems like > this should only check if an object exists, and that adding the

Re: [Python-ideas] Null coalescing operator

2016-10-28 Thread Eric Snow
On Fri, Oct 28, 2016 at 7:13 AM, Barry Warsaw wrote: > You could of course support exactly the same syntax being proposed as a > language change, e.g. > > from operator import attrgetter > r = attrgetter('b?.x?.z') > > and then you wouldn't even need the `coalesce`

Re: [Python-ideas] Null coalescing operator

2016-10-28 Thread Gustavo Carneiro
On 28 October 2016 at 14:13, Barry Warsaw wrote: > On Oct 27, 2016, at 07:37 PM, Nick Badger wrote: > > >The problem with doing that is that it's ambiguous. There's no way of > >telling which attribute is allowed to coalesce. > > You could of course support exactly the same

Re: [Python-ideas] More user-friendly version for string.translate()

2016-10-28 Thread Terry Reedy
On 10/26/2016 6:17 PM, Chris Barker wrote: I"ve lost track of what (If anything) is actually being proposed here... so I"m going to try a quick summary: 1) an easy way to spell "remove all the characters other than these" In other words, 'only keep these'. We already have easy ways to create

Re: [Python-ideas] More user-friendly version for string.translate()

2016-10-28 Thread Chris Angelico
On Sat, Oct 29, 2016 at 1:28 AM, Terry Reedy wrote: > If one has a translation dictionary d, use that in twice in the genexp. > d = {'a': '1', 'b': '3x', 'c': 'fum'} ''.join(d[c] for c in s if c in d.keys()) > 'fum11fumfumfum1' Trivial change: >>> ''.join(d[c] for c

Re: [Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)

2016-10-28 Thread Stephen J. Turnbull
Sven R. Kunze writes: > So, instead providing this kind of syntax for dicts only, why not also > providing them for kwargs? Basically marking arguments as keyword arguments: > > my_func(:param1, :param2) Please don't. I need to write Lisp, where that syntax has a completely different

Re: [Python-ideas] Null coalescing operator

2016-10-28 Thread Stephen J. Turnbull
Mark E. Haase writes: > In terms of "bunch of longer examples", what did you have in mind? > I could take some popular library and rewrite a section of it with > the proposed operators, but that would depend on the response to > the previous paragraph. I gather you think you have a deadlock