Hi Steven!
On 21.09.22 13:17, Steven D'Aprano wrote:
The distinction you make between user-defined and non-user-defined
classes doesn't hold water. If you allow that (say) `int|None` **might**
be acceptable, then why would `Integer|None` **necessarily** be lazy and
bad just because int is
On Sun, Sep 18, 2022 at 09:43:26PM +0200, Philipp Burch wrote:
> However, I then read the mentioned post of Steve Dower, with the final
> summary:
>
> > So to summarise my core concern - allowing an API designer to "just
> use None" is a cop out, and it lets people write lazy/bad APIs rather
Hi Philipp,
That's a really good idea, and I'd really want to see it being implemented.
Having said that, I wonder how many people would actually use this concept
of "none-representing" objects. In my 10+ years of programming experience
I've never seen anybody eager to use more complex structures
On 20. 09. 22 10:59, Petr Viktorin wrote:
On 19. 09. 22 17:58, Guido van Rossum wrote:
Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no
different than the "Maybe X" pattern that functional programmers are
so
On 19. 09. 22 17:58, Guido van Rossum wrote:
Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no
different than the "Maybe X" pattern that functional programmers are so
fond of.
I must disagree here. With
Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no different
than the "Maybe X" pattern that functional programmers are so fond of.
On Mon, Sep 19, 2022 at 8:02 AM Philipp Burch wrote:
> Hi all,
>
> I've only
Hi all,
I've only here found out that there is a discussion going on about those
none-aware operators and my first thought was "great, finally!". FWIW,
I'd be happy with the syntax suggestion in the PEP, since '?' looks
rather intuitive to me to mean something like "maybe".
However, I then
Hi Maarten,
I'm sorry for the confusion - it was bad wording on my part.
What I really meant was that the problem with the None-aware operator, and
the reason why PEP505 has not been accepted for such a long time, is that
there's no consensus regarding the need for it (and not necessarily the
Hi Piotr,
doesn't Doug's reply of 8:03 address this point? As he says, the none-aware
operator never gives you None when you ask for a missing attribute (these cases
always raise an exception). If we look at these two alternatives
phone1 = book.publisher?.owner.phone
phone2 =
Hi Maarten,
I like the suggestion but I'm not sure if the real problem with the PEP505
is the symbol/operator used.
Reading through the whole discussion I'm under the impression that the idea
of the None value being treated as an indicator of the missing attribute is
what prevents this PEP from
Hi, I wanted to propose replacing ? with -> in the none aware syntax. This
makes the expression look like a chain, and I think that most people
intuitively can understand how the chain might get broken (and what would
happen in that case). For example:
zipcode = person->.address->['zipcode']
On Sun, Oct 24, 2021 at 12:35 AM Marc Mueller wrote:
>
> > Bear in mind that these last ones are exactly equivalent to the "or"
> > operator, as they'll use the default if you have any falsy value.
> > variable = some_function(...) or []
>
> Isn't that in itself a good argument in favor of (??) ?
Marc Mueller writes:
> True, but from my experience 'None' is just by far the most common
> default. Why not improve how we handle it?
The question is whether this is an improvement in the long run. When
some falsies are expected, in-range values, "if arg is None: ..." or
"x = default if arg
> Bear in mind that these last ones are exactly equivalent to the "or"
> operator, as they'll use the default if you have any falsy value.
> variable = some_function(...) or []
Isn't that in itself a good argument in favor of (??) ? By missing to add 'is
None', I would have already added a
On Sat, Oct 23, 2021 at 6:20 AM Marc Mueller wrote:
>
> Most of the discussion so far has been focused on (?.). Tbh though, I'm more
> interested in (??) and (??=). Just reading through code, I constantly notice
> boilerplate like this which could easily be substituted.
>
> variable =
Most of the discussion so far has been focused on (?.). Tbh though, I'm more
interested in (??) and (??=). Just reading through code, I constantly notice
boilerplate like this which could easily be substituted.
variable = some_function(...)
if variable is None:
variable = [] # some default
On Thu, Oct 21, 2021 at 10:49:35AM +0200, Baptiste Carvello wrote:
> > Versions of this that rely on catching AttributeError are simply wrong
> > and are an anti-pattern. They catch too much and silently turn
> > errors into silent wrong behaviour.
> >
> > PEP 505 does not fall into that
On Thu, Oct 21, 2021 at 01:46:27PM +1100, Steven D'Aprano wrote:
> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> > If the motivation for this operator is chained lookups, how about adding a
> > feature to the operator module, first? It seems natural to add a
> > keyword-only
Hello,
Le 21/10/2021 à 07:59, Steven D'Aprano a écrit :
>
> Versions of this that rely on catching AttributeError are simply wrong
> and are an anti-pattern. They catch too much and silently turn
> errors into silent wrong behaviour.
>
> PEP 505 does not fall into that trap.
This is not
On Wed, Oct 20, 2021 at 06:17:59PM +0200, Piotr Waszkiewicz wrote:
> Do you think about something along those lines?
> ```
> phone = book.publisher.owner.phone except AttributeError: None
> ```
This is not equivalent to PEP 505's None-aware operators. The semantics
are very different, and it is
On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
> None and its ilk often conflate too many qualities. For example, is it
> missing because it doesn't exist, it never existed, or because we never
> received a value, despite knowing it must exist?
Does it matter if different
On Wed, Oct 20, 2021 at 9:39 PM Michael Selik wrote:
>
>
> On Wed, Oct 20, 2021 at 9:18 AM Piotr Waszkiewicz
> wrote:
>
>> Do you think about something along those lines?
>> ```
>> phone = book.publisher.owner.phone except AttributeError: None
>> ```
>>
>
> Yes, that seems reasonable.
>
Nice,
On Wed, Oct 20, 2021 at 9:18 AM Piotr Waszkiewicz
wrote:
> Do you think about something along those lines?
> ```
> phone = book.publisher.owner.phone except AttributeError: None
> ```
>
Yes, that seems reasonable.
> I don't mind this syntax but it would have to be supported by static type
>
Hi,
On Wed, Oct 20, 2021 at 5:44 PM Michael Selik wrote:
> On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz
> wrote:
>
>> On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote:
>>
>>> In case it saves anyone a couple clicks:
>>> https://www.python.org/dev/peps/pep-0463/
>>> I also prefer more
On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz
wrote:
> On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote:
>
>> In case it saves anyone a couple clicks:
>> https://www.python.org/dev/peps/pep-0463/
>> I also prefer more syntactic help with exceptions, rather than more
>> syntax emphasizing
Hi,
On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote:
> In case it saves anyone a couple clicks:
> https://www.python.org/dev/peps/pep-0463/
>
> I also prefer more syntactic help with exceptions, rather than more syntax
> emphasizing None's uniqueness.
>
Me too, but could you provide me an
Data point: I find all the examples in PEP 505 less readable using the
proposed new operators.
Trying to explain why: The syntax feels *too* compact (Perl-like?) -
when reading it, every time you see a None-aware operator (*if* you
notice it), you have to jerk to a halt and say, "Whoa! What's
This is very reminiscent of the (rejected) PEP 463, Exception-catching
expressions (which I still hope will be resurrected some day). It would
allow you to write
y = (config["handler"]["parameters"]["y"] except KeyError: None)
(possibly the parentheses might not be required) which IMO is
Baptiste Carvello wrote:
> y = config["handler"]["parameters"]["y"] with KeyError as None
I love the look of this! While it doesn't address everything that PEP505 does,
that's IMO a good thing, because - as other people mentioned already - None
does too many things already.
On another note,
On Tue, Oct 19, 2021 at 9:39 AM Chris Angelico wrote:
> On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello
> wrote:
> >
> > Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> > >
> > > y = None # Default
> > > if config is not None:
> > > handler = config.get("handler")
> > > if handler is
I will also say that I don't believe the safe-navigation operators necessarily
compromise type safety. PEP 505 explicitly rejects having them catch
`AttributeError` or `KeyError` (and I agree with this rejection). It's not the
default behavior of objects to return None when an unknown attribute
Steve Dower wrote:
> Okay, I'll let myself get sucked into responding ONE TIME, but only
> because you gave me such a nice API to work with :)
This actually pushed me hard towards adding the null-aware operators. I agree
that the named-function approach Paul suggests is better. I admit that
On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello
wrote:
>
> Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> >
> > y = None # Default
> > if config is not None:
> > handler = config.get("handler")
> > if handler is not None:
> > parameters = handler.get("parameters")
> > if
Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
>
> y = None # Default
> if config is not None:
> handler = config.get("handler")
> if handler is not None:
> parameters = handler.get("parameters")
> if parameters is not None:
> y = parameters.get("y")
>
> […]
> Using ?. this
Thank you very much for this exhaustive explanation and example. I really
like it and agree with you that the implementation provided by your example
is much more well designed.
The problem I have with it is that I feel like it assumes that I have a way
to introduce such changes when writing the
On Tue, 19 Oct 2021 at 00:55, Guido van Rossum wrote:
>
> I should have added that I also don't feel I want to go at bat to fight for
> this PEP. I do observe that it looks like the folks used to building large
> systems (in Python or other languages) don't seem to like it, while it seems
> to
I should have added that I also don't feel I want to go at bat to fight for
this PEP. I do observe that it looks like the folks used to building large
systems (in Python or other languages) don't seem to like it, while it
seems to appeal to folks writing simpler code (the abundant majority of
Okay, I'll let myself get sucked into responding ONE TIME, but only
because you gave me such a nice API to work with :)
On 10/18/2021 9:11 PM, Piotr Waszkiewicz wrote:
> class User(DBModel):
> phone: str | None
>
> class Publisher(DBModel):
> owner: ForeignKey[User] | None
>
>
Big +1 from me. I've been looking forward to having None-aware operators in
Python as I find them a very neat language addition.
For me personally the main advantage of having maybe-dot (?.) operator is
the ability to express certain logic in a much clearer way, for example:
> class
On Mon, Oct 18, 2021 at 6:49 PM Paul Moore wrote:
> On Mon, 18 Oct 2021 at 19:29, Guido van Rossum wrote:
> > y = None # Default
> > if config is not None:
> > handler = config.get("handler")
> > if handler is not None:
> > parameters = handler.get("parameters")
> > if parameters
On Mon, 18 Oct 2021 at 19:29, Guido van Rossum wrote:
> where the convention is that keys at any level may be omitted altogether and
> config itself may be NOne, then to safely access the value of
> config["handler"]["parameters"]["y"] we would have to write
>
> y = None # Default
> if config
On Mon, Oct 18, 2021 at 9:35 AM Paul Bryan wrote:
> NoneType is just another type, and in type checking scenarios should be
> expressed with `Optional[type]` or more preferably in the future `type |
> None`; `None` is not a non-value. Assuming what I just wrote is true, I
> don't get what the
NoneType is just another type, and in type checking scenarios should be
expressed with `Optional[type]` or more preferably in the future `type
| None`; `None` is not a non-value. Assuming what I just wrote is true,
I don't get what the basis of this thread is; what am I missing?
On Mon,
Thanks for allowing me to speak for myself, as I said I would when
contacted off list :)
But as it happens, you've summarised my position very accurately:
he now believes the implementation of these operators would lead people to a
style of coding which would lead to the proliferation of
On Fri, 15 Oct 2021 12:36:15 +1100
Steven D'Aprano wrote:
> Hello Doug,
>
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
>
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
>
> Can you elaborate on
Steven D'Aprano wrote:
> Hello Doug,
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
> > Can you elaborate on that? Obviously it is not always appropriate
Hello Doug,
On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding
Can you elaborate on that? Obviously it is not always appropriate to use
None, but I've never
I tried to implement this in CPython by modifying a downloaded source code, but
I can't seem to fix the problem of the "maybe" operators segfaulting when being
used with literal immutables. The maybe-assign/coalesce operators were
implemented successfully though.
Thanks -- this is the kind of work that helps a PEP get accepted. I am
personally in favor of accepting PEP 505, and I hope that your work and the
discussion that will undoubtedly follow here will help convince the
Steering Council to accept it.
--Guido
On Thu, Oct 14, 2021 at 10:38 AM Doug
49 matches
Mail list logo
