On 3 November 2016 at 23:06, Steven D'Aprano wrote:
> On Thu, Nov 03, 2016 at 12:35:07PM -0700, Chris Barker wrote:
> > On Thu, Nov 3, 2016 at 12:00 PM, MRAB
> wrote:
> >
> > > self.an_arg = the_default if an_arg is None else an_arg
> >
> > > No, ?? is a bit like 'or', except that only None is f
On Thu, Nov 3, 2016 at 4:06 PM, Steven D'Aprano wrote:
> > > No, ?? is a bit like 'or', except that only None is falsey, so it
> would be:
> > >
> > > self.an_arg = an_arg ?? the_default
> >
> >
> > thanks! and actually, that reads much better to me.
>
> That suggests a possible different col
On Thu, Nov 03, 2016 at 12:35:07PM -0700, Chris Barker wrote:
> On Thu, Nov 3, 2016 at 12:00 PM, MRAB wrote:
>
> > self.an_arg = the_default if an_arg is None else an_arg
>
> > No, ?? is a bit like 'or', except that only None is falsey, so it would be:
> >
> > self.an_arg = an_arg ?? the_def
On Thu, Nov 3, 2016 at 12:00 PM, MRAB wrote:
> self.an_arg = the_default if an_arg is None else an_arg
>
>
> No, ?? is a bit like 'or', except that only None is falsey, so it would be:
>>
>
> self.an_arg = an_arg ?? the_default
thanks! and actually, that reads much better to me.
-CHB
--
On 2016-11-03 18:36, Chris Barker wrote:
Thanks Steven, this is great!
so -- when all this started, I think one of the use cases was to clean
up this really common idiom:
self.an_arg = the_default if an_arg is None else an_arg
so would that be:
self.an_arg = the_default ?? an_arg
That would
Thanks Steven, this is great!
so -- when all this started, I think one of the use cases was to clean up
this really common idiom:
self.an_arg = the_default if an_arg is None else an_arg
so would that be:
self.an_arg = the_default ?? an_arg
That would be nice.
Though the fact that I'm still no
On 03.11.2016 02:06, MRAB wrote:
On 2016-11-02 21:57, Greg Ewing wrote:
MRAB wrote:
target = expr1 || expr2 || expr3
target = expr1 && expr2 && expr3
except that only None would be considered falsey?
Or would that be confusing?
Yes, I think that borrowing an operator from C but givi
On 3 November 2016 at 11:38, Steven D'Aprano wrote:
> Looking at those examples of code, I don't think it is likely that the
> majority (or even a large minority) are the result of getattr.
>
> But even if they are, what difference does it make?
It may have mattered, if a getattr(obj, attr, coale
On Wed, Nov 02, 2016 at 10:22:56PM -0400, Kyle Lahnakoski wrote:
>
> On 11/2/2016 2:30 PM, Zero Piraeus wrote:
> >
> >If I write something like obj.attr, the failure mode I care about is that
> >obj has no attribute attr, rather than that obj is specifically None (or
> >one of a defined group of s
Steven D'Aprano wrote:
Or even the subject line of this email thread???
Sorry, crossed over discussions.
But I think it's also true that the null-coalescing
idea is for cases where it's not an error for something
to be None.
--
Greg
___
Python-ideas
On 11/2/2016 2:30 PM, Zero Piraeus wrote:
If I write something like obj.attr, the failure mode I care about is that
obj has no attribute attr, rather than that obj is specifically None (or
one of a defined group of somewhat Nonelike objects).
I agree with this understanding. The problem wit
On Thu, Nov 03, 2016 at 11:22:45AM +1300, Greg Ewing wrote:
> The proposed .? syntax is designed for cases where it's *not*
> an error for the object to be missing the attribute,
No it is not. That is absolutely not what the syntax means.
I'm sorry to single you out Greg, but have you read the
On 2016-11-02 21:57, Greg Ewing wrote:
MRAB wrote:
target = expr1 || expr2 || expr3
target = expr1 && expr2 && expr3
except that only None would be considered falsey?
Or would that be confusing?
Yes, I think that borrowing an operator from C but giving
it subtly different semantics w
On Thu, Nov 03, 2016 at 02:17:14AM +1000, Nick Coghlan wrote:
> Yeah, and so far the protocol based alternative I'm working on hasn't
> been any less headache-inducing (Mark has been reviewing some early
> iterations and had to draw a diagram to try to follow the proposed
> control flow).
Even if
On 2 November 2016 at 21:50, David Mertz wrote:
> Even though I really don't want new null-coalescing operators, I really
> appreciate the ternary operator in Python (or in C).
>
> On Wed, Nov 2, 2016 at 12:38 PM, Mikhail V wrote:
>>
>> result = a > b ? x : y
>>
>> is IMHO a syntactical herecy. S
On Wed, Nov 02, 2016 at 08:46:54AM -0700, Guido van Rossum wrote:
> But first we need to agree on what even the right definition
> of ?. is. It's been frighteningly difficult to explain this even on this
> list, even though I have a very clear view in my head,
This is Python-Ideas and with respe
MRAB wrote:
target = expr1 || expr2 || expr3
target = expr1 && expr2 && expr3
except that only None would be considered falsey?
Or would that be confusing?
Yes, I think that borrowing an operator from C but giving
it subtly different semantics would be *very* confusing,
especially to
On 10/31/16, Guido van Rossum wrote:
> For "everything to the right" it would seem we have some freedom: e.g. if
> we have "foo.bar?.baz(bletch)" is the call included? The answer is yes --
> the concept we're after here is named "trailer" in the Grammar file in the
> source code (
> https://githu
I actually think that Zero's point here is quite valid... At some earlier
point in the thread, I believe that Nick Coughlin was saying that we should
be asking ourselves _why_ we want to do something like this and the result
of that discussion was because there is pain when working with
"pseudo-str
On 10/15/16, Nick Coghlan wrote:
> * None-coalescing operator: x ?or y
> * None-severing operator: x ?and y
> * None-coalescing augmented assignment: x ?= y
> * None-severing attribute access: x?.attr
> * None-severing subscript lookup: x?[expr]
Please don't be too harsh to me for my next words!
Zero Piraeus writes:
If I write something like obj.attr, the failure mode I care about is
that
obj has no attribute attr, rather than that obj is specifically None (or
one of a defined group of somewhat Nonelike objects).
Clearly, in such a circumstance, obj is not what I ex
Even though I really don't want new null-coalescing operators, I really
appreciate the ternary operator in Python (or in C).
On Wed, Nov 2, 2016 at 12:38 PM, Mikhail V wrote:
> result = a > b ? x : y
>
> is IMHO a syntactical herecy. Such things disgust me from programming.
> Why on earth one ca
Zero Piraeus writes:
> If I write something like obj.attr, the failure mode I care about is that
> obj has no attribute attr, rather than that obj is specifically None (or
> one of a defined group of somewhat Nonelike objects).
>
> Clearly, in such a circumstance, obj is not what I expected it to
On 11/02/2016 12:32 PM, Nikolaus Rath wrote:
On Nov 02 2016, Zero Piraeus
wrote:
On Wed, 2016-11-02 at 08:46 -0700, Guido van Rossum wrote:
[...] we need to agree on what even the right definition of ?. is. It's
been frighteningly difficult to explain this even on this list, even
though I hav
On Nov 02 2016, Zero Piraeus
wrote:
> On Wed, 2016-11-02 at 08:46 -0700, Guido van Rossum wrote:
>> [...] we need to agree on what even the right definition of ?. is. It's
>> been frighteningly difficult to explain this even on this list, even
>> though I have a very clear view in my head, and PE
On 2 November 2016 at 19:34, MRAB wrote:
> How about borrowing from C:
>
> target = expr1 || expr2 || expr3
> target = expr1 && expr2 && expr3
>
> except that only None would be considered falsey?
>
> Or would that be confusing?
Sorry for intruding into discussion and off-topic again,
Su
On 2016-11-02 16:17, Nick Coghlan wrote:
[snip]
Yeah, and so far the protocol based alternative I'm working on hasn't
been any less headache-inducing (Mark has been reviewing some early
iterations and had to draw a diagram to try to follow the proposed
control flow).
I think I have a way to simp
:
Disclaimer: I haven't followed all of this discussion, so some or all of
the following may already have been expressed better (and perhaps refuted
better still).
On Wed, 2016-11-02 at 08:46 -0700, Guido van Rossum wrote:
> [...] we need to agree on what even the right definition of ?. is. It's
On 02.11.2016 17:17, Nick Coghlan wrote:
The gist is that rather than writing the bare:
target = expr1 ?? expr2 ?? expr3
You'd instead write None-coalescing as:
target = exists(expr1) ?? exists(expr2) ?? expr3
and None-propagating as:
target = missing(expr1) ?? missing(expr2) ??
On 3 November 2016 at 01:46, Guido van Rossum wrote:
> But I also recall learning CoffeeScript via cargo-culting a large existing
> codebase and having not the foggiest ideas when it made sense to use ?. and
> when plain . was enough. So I think this feature is not very
> new-user-friendly and I s
But I also recall learning CoffeeScript via cargo-culting a large existing
codebase and having not the foggiest ideas when it made sense to use ?. and
when plain . was enough. So I think this feature is not very
new-user-friendly and I still expect that in the end we'll have two
rejected PEPs. But
On 2 November 2016 at 00:46, Guido van Rossum wrote:
> I personally find the ?keyword pattern has less appeal than ?, ?? or ?. .
Good to know :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing
On Wed, Nov 2, 2016 at 9:18 PM, Steven D'Aprano wrote:
> On Wed, Nov 02, 2016 at 02:09:24PM +1100, Chris Angelico wrote:
>> We already expect "to the left" and "to the right" to end based on
>> operator precedence rules. Parentheses are used to control operator
>> precedence. It would surprise peo
On Wed, Nov 02, 2016 at 02:09:24PM +1100, Chris Angelico wrote:
> We already expect "to the left" and "to the right" to end based on
> operator precedence rules. Parentheses are used to control operator
> precedence. It would surprise people *greatly* if they didn't bound
> the effect of the questi
Geez.
--Guido (mobile)
On Nov 1, 2016 8:10 PM, "Chris Angelico" wrote:
> On Wed, Nov 2, 2016 at 11:09 AM, Steven D'Aprano
> wrote:
> > I don't know when I would ever want to actually do this in practice, but
> > allowing the ?. operator to magically effect code outside of the
> > parentheses d
On Wed, Nov 2, 2016 at 11:09 AM, Steven D'Aprano wrote:
> I don't know when I would ever want to actually do this in practice, but
> allowing the ?. operator to magically effect code outside of the
> parentheses definitely counts as "spooky action at a distance". Guido's
> rule of "everything to t
On Mon, Oct 31, 2016 at 05:44:07PM -0400, Random832 wrote:
> Right now, foo.bar.baz(bletch) is Call(Attribute(Attribute(Name('foo'),
> 'bar'), 'baz'), [Name('bletch')])), which is identical to
> (foo.bar).baz(bletch) or (foo.bar.baz)(bletch). These are treated,
> essentially, as postfix operators,
I personally find the ?keyword pattern has less appeal than ?, ?? or ?. .
On Tue, Nov 1, 2016 at 4:02 AM, Nick Coghlan wrote:
> On 1 November 2016 at 20:28, Paul Moore wrote:
> > On 1 November 2016 at 10:11, Nick Coghlan wrote:
> >>
> >> I do think it would be worth covering the symbol+keyword
On 1 November 2016 at 20:28, Paul Moore wrote:
> On 1 November 2016 at 10:11, Nick Coghlan wrote:
>>
>> I do think it would be worth covering the symbol+keyword option
>> discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.",
>> and "?[")
>
> FWIW, I'm not keen on it.
>
> As a tech
On 1 November 2016 at 10:11, Nick Coghlan wrote:
>
> I do think it would be worth covering the symbol+keyword option
> discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.",
> and "?[")
FWIW, I'm not keen on it.
As a technical question, would it be treated in the syntax as a
keywo
On 1 November 2016 at 01:51, Mark E. Haase wrote:
> Stephen J. Turnbull wrote:
>>
>> I gather you think you have a deadlock here. The way to break it is
>> to just do it. Pick a syntax and do the rewriting. My memory of some
>> past instances is that many of the senior devs (especially Guido) w
Obviously the AST needs to be changed. How? I dunno. Sounds like you have
some ideas. :-)
On Mon, Oct 31, 2016 at 2:44 PM, Random832 wrote:
> On Mon, Oct 31, 2016, at 13:16, Guido van Rossum wrote:
> > For "everything to the right" it would seem we have some freedom: e.g.
> > if we have "foo.bar
On Mon, Oct 31, 2016, at 13:16, Guido van Rossum wrote:
> For "everything to the right" it would seem we have some freedom: e.g.
> if we have "foo.bar?.baz(bletch)" is the call included? The answer is
> yes -- the concept we're after here is named "trailer" in the Grammar
> file in the source code
On 2016-10-31 19:14, Paul Moore wrote:
On 31 October 2016 at 18:11, MRAB wrote:
> With this feature it could be:
>
> if x in stop_on or end_if?(x):
I don't think "null-aware function call" is in the current version of the PEP.
That might be because it's not clear how useful it would be in p
On 31 October 2016 at 18:11, MRAB wrote:
> With this feature it could be:
>
> if x in stop_on or end_if?(x):
I don't think "null-aware function call" is in the current version of the PEP.
Paul
___
Python-ideas mailing list
Python-ideas@python.org
ht
On 2016-10-31 17:16, Guido van Rossum wrote:
I think we should try to improve our intutition about these operators.
Many things that are intuitively clear still require long turgid
paragraphs in reference documentation to state the behavior
unambiguously -- but that doesn't stop us from intuitive
On 31 October 2016 at 17:16, Guido van Rossum wrote:
> I think we should try to improve our intutition about these operators. Many
> things that are intuitively clear still require long turgid paragraphs in
> reference documentation to state the behavior unambiguously -- but that
> doesn't stop us
I think we should try to improve our intutition about these operators. Many
things that are intuitively clear still require long turgid paragraphs in
reference documentation to state the behavior unambiguously -- but that
doesn't stop us from intuitively grasping concepts like a+b (when does
b.__ra
The PEP combines ideas from several different languages. For example:
* Both Dart and C# have "x ?? y" and "x?.y".
* Dart has "x ??= y" and C# does not.
* C# has short circuit semantics for "?." and Dart does not.
* PHP has "??" but does not have "?."
* Etc.
Wikipedia lists a lot of other languag
On 31 October 2016 at 15:51, Mark E. Haase wrote:
> Therefore, I have updated the PEP with the punctuation mentioned above, and
> at this point the PEP can't go any farther. If the best spelling for this
> new operator is unacceptable, then there's no getting around that. This PEP
> should be reje
Stephen J. Turnbull wrote:
> I gather you think you have a deadlock here. The way to break it is
> to just do it. Pick a syntax and do the rewriting. My memory of some
> past instances is that many of the senior devs (especially Guido) will
> "see through the syntax" to evaluate the benefits of
On 29 October 2016 at 18:19, Stephen J. Turnbull
wrote:
>> For better or worse, it may be emoji that drive that change ;-)
>>
>> I suspect that the 100 million or so Chinese, Japanese, Korean, and
>> Indian programmers who have had systems that have no trouble
>> whatsoever handling non-ASCII for
On 29 October 2016 at 18:19, Stephen J. Turnbull
wrote:
>> For better or worse, it may be emoji that drive that change ;-)
>
> I suspect that the 100 million or so Chinese, Japanese, Korean, and
> Indian programmers who have had systems that have no trouble
> whatsoever handling non-ASCII for as l
Steven d'Aprano writes:
> I think you mean WHITE SQUARE? At least, I can not see any "OPEN
> SQUARE" code point in Unicode, and the character you use below □
> is called WHITE SQUARE.
You're right, I just used a common Japanese name for it. I even
checked the table to make sure it was BMP but
On 29 October 2016 at 07:30, Steven D'Aprano wrote:
> So even though I *want* to use non-ASCI operators, I have to admit that
> I *can't* realistically use non-ASCII operators. Not yet.
Personally, I'm not even sure I want non-ASCII operators until
non-ASCII characters are common, and used withou
On Sat, Oct 29, 2016 at 11:02:36AM +0900, Stephen J. Turnbull wrote:
> Unfortunately here the most plausible syntax is one
> that Guido has said he definitely doesn't like: using '?'. The
> alternatives are pretty horrible (a Haskell-like 'maybe' keyword, or
> the OPEN SQUARE character used by so
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
On Fri, Oct 14, 2016 at 11:36 PM, Guido van Rossum wrote:
> I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> a bunch of longer examples would help all of us see the advantages of
> the proposals.
I understand. You said the next phase should be to pick the best operator
fo
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 yo
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 syntax being proposed
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` argument.
+1
-eric
___
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 attrgett
The problem with doing that is that it's ambiguous. There's no way of
telling which attribute is allowed to coalesce.
I think one of the best arguments for a coalescing operator in Python is
that it allows you to be more explicit, without the hassle of nested try:
except AttributeError blocks. You
On Oct 27, 2016, at 06:27 PM, Joonas Liik wrote:
>perhaps just having a utility function can get us some of the way there..
>
>#may error
>r = a.b.x.z
>
># will default to None
>r = a?.b?.x?.z
>r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
>implemented today.
You could probably
On Thu, Oct 27, 2016, at 11:27, Joonas Liik wrote:
> perhaps just having a utility function can get us some of the way there..
>
> #may error
> r = a.b.x.z
>
> # will default to None
> r = a?.b?.x?.z
If a.b can't or shouldn't be None, this should be a?.b.x.z
I'm not certain how your utility fun
perhaps just having a utility function can get us some of the way there..
#may error
r = a.b.x.z
# will default to None
r = a?.b?.x?.z
r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
implemented today.
___
Python-ideas mailing list
Pytho
Am Freitag, 14. Oktober 2016 23:11:48 UTC-7 schrieb Nick Coghlan:
>
>
> Regarding the spelling details, my current preferences are as follows:
>
> * None-coalescing operator: x ?or y
> * None-severing operator: x ?and y
> * None-coalescing augmented assignment: x ?= y
> * None-severing attribut
On Oct 15, 2016, at 04:10 PM, Nick Coghlan wrote:
>Having been previously somewhere between -1 and -0, I've been doing a
>lot more data mining and analysis work lately, which has been enough
>to shift me to at least +0 and potentially even higher when it comes
>to the utility of adding these opera
On 15.10.2016 08:10, Nick Coghlan wrote:
However, it's also the case that where we *do* have a well understood
and nicely constrained problem, it's still better to complain loudly
when data is unexpectedly missing, rather than subjecting ourselves to
the pain of having to deal with detecting prob
15 Жов 2016 08:11 "Nick Coghlan" пише:
>
> On 15 October 2016 at 13:36, Guido van Rossum wrote:
> > I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> > a bunch of longer examples would help all of us see the advantages of
> > the proposals.
>
> Having been previously somewhe
On 15 October 2016 at 13:36, Guido van Rossum wrote:
> I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> a bunch of longer examples would help all of us see the advantages of
> the proposals.
Having been previously somewhere between -1 and -0, I've been doing a
lot more data
I'm not usually swayed by surveys -- Python is not a democracy. Maybe
a bunch of longer examples would help all of us see the advantages of
the proposals.
On Fri, Oct 14, 2016 at 8:09 PM, Mark E. Haase wrote:
> On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum wrote:
>>
>> I propose that the ne
On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum wrote:
> I propose that the next phase of the process should be to pick the
> best operator for each sub-proposal. Then we can decide which of the
> sub-proposals we actually want in the language, based on a combination
> of how important the fun
For what it's worth, I like the C# syntax with question marks.
It is probably more risky (breaks more code) to introduce a new keyword
than a new symbol as operator.
If we have to pick a symbol, it's less confusing if we pick something
another language already uses. There is no shame in copying
I actually think the spelling is the main stumbling block. The
intrinsic value of the behavior is clear, it's finding an acceptable
spelling that hold back the proposal.
I propose that the next phase of the process should be to pick the
best operator for each sub-proposal. Then we can decide which
(Replying to multiple posts in this thread)
Guido van Rossum:
> Another problem is PEP 505 -- it
> is full of discussion but its specification is unreadable due to the
> author's idea to defer the actual choice of operators and use a
> strange sequence of unicode characters instead.
Hi, I wrote
On Sat, Sep 10, 2016 at 4:27 PM, Chris Angelico wrote:
> On Sun, Sep 11, 2016 at 9:10 AM, Guido van Rossum wrote:
>> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
>> `x?.bar`... Color me unconvinced.
>
> As a syntactic form? Not interested. But what if it's the underlying
>
On Sun, Sep 11, 2016 at 9:10 AM, Guido van Rossum wrote:
> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
> `x?.bar`... Color me unconvinced.
As a syntactic form? Not interested. But what if it's the underlying
implementation? We have "yield from X" as a tidy syntax for roug
So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
`x?.bar`... Color me unconvinced.
On Sat, Sep 10, 2016 at 4:06 PM, David Mertz wrote:
> Actually, I guess the example I liked was from the year ago discussion. And
> it didn't do *exactly* what I think a wrapper should. What I
Actually, I guess the example I liked was from the year ago discussion.
And it didn't do *exactly* what I think a wrapper should. What I'd want
would be like this:
class NoneCoalesce(object):
"Standard operations on object for 'is not None'"
def __init__(self, obj):
self.obj = obj
https://github.com/kirbyfan64/_frozensafemockobjectimplementation
In all seriousness, though, I really feel like that would be the ultimate
bug magnet, since it'd be easy to forget to un-wrap the object afterwards.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
progr
I find the '?.' syntax very ugly, much more so in the examples of chained
attributes.
A much better way to handle the use case is to wrap objects in a class that
gives this "propagating None" behavior with plain attribute access. A nice
implementation was presented in this thread.
On Sep 10, 2016
On Sat, Sep 10, 2016, at 13:26, Guido van Rossum wrote:
> The way I recall it, we arrived at the perfect syntax (using ?) and
> semantics. The issue was purely strong hesitation about whether
> sprinkling ? all over your code is too ugly for Python
I think that if there's "strong hesitation" about
On Sat, Sep 10, 2016 at 4:56 PM, Guido van Rossum wrote:
> Another issue already discussed in PEP 505 is a conflict with IPython
> (Jupyter Notebook), which uses ? and ?? as custom syntax to request
> help. But maybe it can be taught to only recognize those when they're
> the last character(s) on
On Sat, Sep 10, 2016 at 11:09 AM, MRAB wrote:
> On 2016-09-10 18:44, Paul Moore wrote:
>>
>> On 10 September 2016 at 18:26, Guido van Rossum wrote:
>>>
>>> IMO the key syntax is
>>> simply one for accessing attributes returning None instead of raising
>>> AttributeError, so that e.g. `foo?.bar?.b
On 2016-09-10 18:44, Paul Moore wrote:
On 10 September 2016 at 18:26, Guido van Rossum wrote:
IMO the key syntax is
simply one for accessing attributes returning None instead of raising
AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
`foo.bar.baz if (foo is not None and fo
On 10 September 2016 at 18:26, Guido van Rossum wrote:
> IMO the key syntax is
> simply one for accessing attributes returning None instead of raising
> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
> e
On 10.09.2016 19:14, Random832 wrote:
As I remember the discussion, I thought he'd more or less conceded on
the use of ? but there was disagreement on how to implement it that
never got resolved. Concerns like, you can't have a?.b return None
because then a?.b() isn't callable, unless you want to
The way I recall it, we arrived at the perfect syntax (using ?) and
semantics. The issue was purely strong hesitation about whether
sprinkling ? all over your code is too ugly for Python, and in the end
we couldn't get agreement on *that*. Another problem is PEP 505 -- it
is full of discussion but
On Sat, Sep 10, 2016, at 12:48, Stephen J. Turnbull wrote:
> I forget if Guido was very sympathetic to null-coalescing operators,
> given somebody came up with a good syntax.
As I remember the discussion, I thought he'd more or less conceded on
the use of ? but there was disagreement on how to imp
Steven D'Aprano writes:
> As Zach and MRAB mention, this was discussed last year. If I recall
> correctly, the discussion fizzled out without a solid conclusion. I
> think there's a PEP -- if not, there should be.
The problem, as I recall, was that there was a conclusion that
'maybe_None if ma
It is PEP 505.
I agree we should resume the discussion on this PEP though (for 3.7), I'm
not completely sure why it stalled.
Ralph
On Sat, 10 Sep 2016, 02:50 Steven D'Aprano, wrote:
> On Fri, Sep 09, 2016 at 10:01:44PM +0200, Arek Bulski wrote:
> > Sometimes I find myself in need of this nice o
On Fri, Sep 09, 2016 at 10:01:44PM +0200, Arek Bulski wrote:
> Sometimes I find myself in need of this nice operator that I used back in
> the days when I was programming in .NET, essentially an expression
>
> >>> expr ?? instead
>
> should return expr when it `is not None` and `instead` otherwis
On 2016-09-09 21:01, Arek Bulski wrote:
Sometimes I find myself in need of this nice operator that I used back
in the days when I was programming in .NET, essentially an expression
expr ?? instead
should return expr when it `is not None` and `instead` otherwise.
A piece of code that I just w
I'd note you can also save 4 characters by writing:
instead if expr is None else expr
On Fri, Sep 9, 2016 at 1:10 PM, David Mertz wrote:
> This idea has come up before. While I can see the use of it, to me at
> least that use doesn't feel nearly common enough to warrant dedicated
> syntax.
>
This idea has come up before. While I can see the use of it, to me at
least that use doesn't feel nearly common enough to warrant dedicated
syntax.
In many cases, it is a "truthy" value you are looking for rather than `is
not None` specifically. That has a convenient spelling:
expr or instead
On Fri, Sep 9, 2016 at 3:01 PM, Arek Bulski wrote:
> Sometimes I find myself in need of this nice operator that I used back in
> the days when I was programming in .NET, essentially an expression
>
expr ?? instead
>
> should return expr when it `is not None` and `instead` otherwise.
>
> A pie
On Sat, Sep 10, 2016 at 6:01 AM, Arek Bulski wrote:
> Sometimes I find myself in need of this nice operator that I used back in
> the days when I was programming in .NET, essentially an expression
>
expr ?? instead
>
> should return expr when it `is not None` and `instead` otherwise.
You can
Sometimes I find myself in need of this nice operator that I used back in
the days when I was programming in .NET, essentially an expression
>>> expr ?? instead
should return expr when it `is not None` and `instead` otherwise.
A piece of code that I just wrote, you can see a use case:
def _
99 matches
Mail list logo