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
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
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`
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,
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
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
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?
>
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
> > -
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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`
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
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
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
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
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
27 matches
Mail list logo