[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Steve Dower 
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 None as an 
exception-less error result and also throughout data structures. My 
understanding is that his current preference is to focus on functional 
composition and styles of programming that disallow the use of None.


As additional context, C# and the .NET Framework have just gone through 
the exercise of making (and propagating) non-nullable reference types 
(and their "null" is far more like our None than C's NULL). Our type 
checkers are also pushing in this direction by requiring Optional[]. The 
argument in all cases is that it allows for simpler code that can safely 
ignore non-values because they cannot be passed.


Adding ??, ?. and ?[, particularly in their short-circuiting evaluation 
form, encourages more complex code by adding value-based branching 
within an expression. And it encourages it on the "outside" of the API, 
not within it. Which means API designers can more easily justify 
returning None because their caller can use None-aware operators to 
basically ignore it. (I would argue that the API designer should work 
harder to create an API that doesn't ever have to return None.)


To be clear, I'm thinking very much in terms of "impact on what people 
will consider to be Pythonic API design over the next 10 years", that 
is, what people think they *should* do with this, rather than simply 
what they *could*. So it's all very hypothetical and I have no data for 
it, much like when it was decided that Optional[] would be mandatory on 
types where None is permitted.


And with that, I'm bowing out of the fresh discussion (unless the SC 
wants to discuss it directly with me). I'll continue advocating for 
tools/features that help people create better APIs, but I'm not going to 
spend a lot of time arguing against those that I believe will not.


Cheers,
Steve

On 10/15/2021 3:08 AM, Doug Swarin wrote:

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 to use

None, but I've never seen it called a *fundamental* flaw.
I know that the null pointer has been called a billion-dollar mistake,
but Python's None is not a null pointer.


I apologize that I may have spoken too strongly here. When I emailed Mr. Dower, 
he mentioned that he now believes the implementation of these operators would 
lead people to a style of coding which would lead to the proliferation of None 
as an exception-less error result and also throughout data structures. My 
understanding is that his current preference is to focus on functional 
composition and styles of programming that disallow the use of None.

I certainly don't mean to speak for him and I hope he will weigh in with a more 
detailed explanation of his thoughts and objections, but I personally disagree 
as a matter of pure practicality. It's just plain useful to be able to easily 
take non-values and safely deal with them without having to constantly check 
for None or to catch and inspect exceptions to see if it's a case that can be 
ignored.

I did indeed think about connecting None to the 'billion dollar mistake' but 
decided against it since as you say None is not a null pointer, and I should 
have chosen my words a little more carefully when revising my initial post 
(likely by removing the word 'fundamental').

Doug

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] compiled python3.10 is unable to find _ssl

2021-10-18 Thread Sandeep Gupta 
I  am having compilation issues again with python3.10 with ssl .

The ./configure was invoked with ssl options and ssl modules seems to
be build successfully.

"""
The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc  _hashlib  _ssl
pwd   time
"""

However, when I do import ssl from python, I get the  error:
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/shared/Builds/Python-3.10.0/lib/python3.10/ssl.py", line
98, in 
import _ssl # if we can't import it, let the error propagate
ModuleNotFoundError: No module named '_ssl'

I can't find _ssl.so in build or install directory.

Thanks
-S
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IIFABHN7DOTCXMRQ72SLJSU4VDWRM2HB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

2021-10-18 Thread Mohamed Koubaa 
I love everything about this - but I expect some hesitancy due to this 
"Multithreaded programs are prone to concurrency bugs.".

If there is significant pushback, I have one suggestion:

Would it be helpful to think of the python concurrency mode as a property of 
interpreters?
`interp = interpreters.create(concurrency_mode=interpreters.GIL)`
or 
`interp = interpreters.create(concurrency_mode=interpreters.NOGIL)`

and subsequently python _environments_ can make different choices about what to 
use for the 0th interpreter, via some kind of configuration.
Python modules can declare which concurrency modes they supports.  Future 
concurrency modes that address specific use cases could be added.

This would allow python environments who would rather not audit their code for 
concurrency isuses to opt out, and allow incremental adoption.  I can't intuit 
whether this indirection would cause a performance problem in the C 
implementation or if there is some clever way to have different variants of 
relevant objects at compile time and switch between them based on the 
interpreter concurrency mode.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZUEWHEOW34MNHKOY2TLTFI4LHYJX4YDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

2021-10-18 Thread Paul Bryan 
The way I see it, the concurrency model to be used is selected by
developers. They can choose between multi-threading, multi-process, or
asyncio, or even a hybrid. If developers select multithreading, then
they carry the burden of ensuring mutual exclusion and avoiding race
conditions, dead locks, live locks, etc.


On Mon, 2021-10-18 at 13:17 +, Mohamed Koubaa wrote:
> I love everything about this - but I expect some hesitancy due to
> this "Multithreaded programs are prone to concurrency bugs.".
> 
> If there is significant pushback, I have one suggestion:
> 
> Would it be helpful to think of the python concurrency mode as a
> property of interpreters?
> `interp = interpreters.create(concurrency_mode=interpreters.GIL)`
> or 
> `interp = interpreters.create(concurrency_mode=interpreters.NOGIL)`
> 
> and subsequently python _environments_ can make different choices
> about what to use for the 0th interpreter, via some kind of
> configuration.
> Python modules can declare which concurrency modes they supports. 
> Future concurrency modes that address specific use cases could be
> added.
> 
> This would allow python environments who would rather not audit their
> code for concurrency isuses to opt out, and allow incremental
> adoption.  I can't intuit whether this indirection would cause a
> performance problem in the C implementation or if there is some
> clever way to have different variants of relevant objects at compile
> time and switch between them based on the interpreter concurrency
> mode.
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/ZUEWHEOW34MNHKOY2TLTFI4LHYJX4YDW/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/36ENPZV6W3NXIUS3TPU4MQ235B2IF5XF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Paul Bryan 
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, 2021-10-18 at 14:13 +0100, Steve Dower wrote:
> 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 None as an exception-less error result and also throughout data
> > structures. My understanding is that his current preference is to
> > focus on functional composition and styles of programming that
> > disallow the use of None.
> 
> As additional context, C# and the .NET Framework have just gone
> through 
> the exercise of making (and propagating) non-nullable reference types
> (and their "null" is far more like our None than C's NULL). Our type 
> checkers are also pushing in this direction by requiring Optional[].
> The 
> argument in all cases is that it allows for simpler code that can
> safely 
> ignore non-values because they cannot be passed.
> 
> Adding ??, ?. and ?[, particularly in their short-circuiting
> evaluation 
> form, encourages more complex code by adding value-based branching 
> within an expression. And it encourages it on the "outside" of the
> API, 
> not within it. Which means API designers can more easily justify 
> returning None because their caller can use None-aware operators to 
> basically ignore it. (I would argue that the API designer should work
> harder to create an API that doesn't ever have to return None.)
> 
> To be clear, I'm thinking very much in terms of "impact on what
> people 
> will consider to be Pythonic API design over the next 10 years", that
> is, what people think they *should* do with this, rather than simply 
> what they *could*. So it's all very hypothetical and I have no data
> for 
> it, much like when it was decided that Optional[] would be mandatory
> on 
> types where None is permitted.
> 
> And with that, I'm bowing out of the fresh discussion (unless the SC 
> wants to discuss it directly with me). I'll continue advocating for 
> tools/features that help people create better APIs, but I'm not going
> to 
> spend a lot of time arguing against those that I believe will not.
> 
> Cheers,
> Steve
> 
> On 10/15/2021 3:08 AM, Doug Swarin wrote:
> > 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 to use
> > > None, but I've never seen it called a *fundamental* flaw.
> > > I know that the null pointer has been called a billion-dollar
> > > mistake,
> > > but Python's None is not a null pointer.
> > 
> > I apologize that I may have spoken too strongly here. When I
> > emailed Mr. Dower, he mentioned that he now believes the
> > implementation of these operators would lead people to a style of
> > coding which would lead to the proliferation of None as an
> > exception-less error result and also throughout data structures. My
> > understanding is that his current preference is to focus on
> > functional composition and styles of programming that disallow the
> > use of None.
> > 
> > I certainly don't mean to speak for him and I hope he will weigh in
> > with a more detailed explanation of his thoughts and objections,
> > but I personally disagree as a matter of pure practicality. It's
> > just plain useful to be able to easily take non-values and safely
> > deal with them without having to constantly check for None or to
> > catch and inspect exceptions to see if it's a case that can be
> > ignored.
> > 
> > I did indeed think about connecting None to the 'billion dollar
> > mistake' but decided against it since as you say None is not a null
> > pointer, and I should have chosen my words a little more carefully
> > when revising my initial post (likely by removing the word
> > 'fundamental').
> > 
> > Doug
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message ar

[Python-Dev] Re: Python multithreading without the GIL

2021-10-18 Thread Skip Montanaro 
Mohamed> I love everything about this - but I expect some hesitancy
due to this "Multithreaded programs are prone to concurrency bugs.".

Paul> The way I see it, the concurrency model to be used is selected
by developers. They can choose between ...

I think the real intent of the statement Mohamed quoted is that just
because your program works in a version of Python with the GIL doesn't
mean it will work unchanged in a GIL-free world. As we all know, the
GIL can hide a multitude of sins. I could be paraphrasing Tim Peters
here without realizing it explicitly. It kinda sounds like something
he might say.

Skip
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4OWK2DQKQOZZDPNWA7KC3NAUTWOBFOND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

2021-10-18 Thread Senthil Kumaran 
Your configure script did pick up openssl as the support version was not
found.

What is your operating system? Make sure you have supported version of
ssl. Python requires openssl 1.1.1 or higher.

On Mac, I had to use brew to install it and --with-openssl flag.

On some linux machines, I have had to download openssl, compile it, and
point my the configure script to (location I compiled openssl).
CFLAGS="-I$HOME/openssl/include" LDFLAGS="-L$HOME/openssl/lib"

Thank you,
Senthil

On Mon, Oct 18, 2021 at 08:16:01PM +0530, Sandeep Gupta wrote:
> I  am having compilation issues again with python3.10 with ssl .
> 
> The ./configure was invoked with ssl options and ssl modules seems to
> be build successfully.
> 
> """
> The following modules found by detect_modules() in setup.py, have been
> built by the Makefile instead, as configured by the Setup files:
> _abc  _hashlib  _ssl
> pwd   time
> """
> 
> However, when I do import ssl from python, I get the  error:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/shared/Builds/Python-3.10.0/lib/python3.10/ssl.py", line
> 98, in 
> import _ssl # if we can't import it, let the error propagate
> ModuleNotFoundError: No module named '_ssl'
> 
> I can't find _ssl.so in build or install directory.
> 
> Thanks
> -S
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/IIFABHN7DOTCXMRQ72SLJSU4VDWRM2HB/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JN6FB7675WTRB23HXD5CGBF4NUCZKSOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Guido van Rossum 
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 basis of this thread is; what am I missing?
>

To me the thread isn't about type checking. It is about APIs that are built
into the language that special-case None, in particular dict.get(). In
certain cases, encountered commonly in certain styles of coding (data
science? web programming?), users encounter data that is structured as
dicts nested multiple levels. This is often out of the user's control, as
the dict is returned by reading a JSON value whose structure is controlled
by some other framework (often not specific to Python).

For example, if we have a config structure like this:

config = {
  "timeout": 0.1,
  "handler: {
"timeout-override": 0.4,
"method-name": "plot",
"parameters": {
  "x": 10,
  "y": "auto",
}
  }
}

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 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")

This kind of pattern (and all the various other ways of writing it, e.g.
using the walrus or passing {} as the second argument to dict.get()) can be
*very* common if that's the kind of data you're given and that's the kind
of app you have to write, and you can't control the format of the data.

Using ?. this can be written as

y = config?.get("handler")?.get("parameters")?.get("y")

More examples are in PEP 505 itself, see
https://www.python.org/dev/peps/pep-0505/#examples

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GKOYEMS7RFHTRPDJ23RAHBBNTFDXKGFJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Paul Moore 
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 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")
>
> This kind of pattern (and all the various other ways of writing it, e.g. 
> using the walrus or passing {} as the second argument to dict.get()) can be 
> *very* common if that's the kind of data you're given and that's the kind of 
> app you have to write, and you can't control the format of the data.
>
> Using ?. this can be written as
>
> y = config?.get("handler")?.get("parameters")?.get("y")
>
> More examples are in PEP 505 itself, see 
> https://www.python.org/dev/peps/pep-0505/#examples

For this particular usage, I'd much rather have a functional API, like

y = get_config(config, "handler", "parameters", "y")

I understand that writing many helpers like that nested_get is a
chore, and having language support for the operation avoids that chore
- but I'm with Steve in not wanting to see the ?.get() pattern become
"idiomatic Python" as it encourages people *not* to design APIs like
nested_get that allow the user to not even be aware of all that
behind-the-scenes complexity. Sure, you could argue that the ?.
operator makes it easier to write something like get_config, but it's
not *that* hard:

def get_config(config, *keys):
value = config
for key in keys:
if value is None:
break
value = value.get(key)
return value

And the problem with the ?.get style is that it doesn't hide anything
- what if you want/need to change your config data structure (because
the JSON you're reading changes its layout, say)? Without
encapsulation, you can't. And if it's *that* common, adding a stdlib
function or a new dict method is also an option, which doesn't need a
language feature and demonstrates good (IMO) API design for people to
copy.

Anyway, much like Steve, I don't expect to spend a lot of time
fighting this proposal. But I will be sad if it gets accepted, and
even more so if ?. becomes idiomatic in user code.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/55SOK3J6YRIOEBX47INLLTAVUZRMD57Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread David Mertz, Ph.D. 
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 is not None:
> >   y = parameters.get("y")
>
> For this particular usage, I'd much rather have a functional API, like
> y = get_config(config, "handler", "parameters", "y")
>

I agree with Paul here... and am pretty sure I did the last time this went
around.  Whenever the issue comes up, it's about JSON.  Or *maybe* about
something very similar that goes by another name or format details.

And there already exists a pretty good, pretty standard, approach called
JSONPath that deals with exactly this kind of thing.  This, in turn, is
largely the same as XPath which serves the same role for XML documents.

I don't think it necessarily needs to be in the standard library, but the
mini-language for extracting data from trees with frequently missing
branches can very well simply be a mini-language.  It'll wind up a lot like
XPath/JSONPath, but something a little bit different could be good too.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/S5Q4OVZIJUQ5AG4HNIRGN4NALCNJGWOW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Piotr Waszkiewicz 
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 User(DBModel):
>phone: str | None
>
> class Publisher(DBModel):
>   owner: ForeignKey[User] | None
>
> class Book(DBModel)
> publisher: ForeignKey[Publisher] | None


Imagine wanting to get the phone number of the person that published a
certain book from the database.
In this situation, with maybe-dot operator I can write:

> phone_number = book.publisher?.owner?.phone

Getting None value could mean that the book has not been published yet (no
publisher relation), owner does not exist or does not have a phone number
associated with it.
Either way it doesn't matter because the only thing that we wanted to
retrieve is the phone number and not the whole context of why it has a
certain value and not the other.

Personally I find this syntax much more readable than other, "more
explicit" expressions like:
> phone_number = book.publisher.owner.phone if (book.publisher is not None
and book.publisher.owner is not None) else None

Best regards,

On Thu, Oct 14, 2021 at 7:37 PM Doug Swarin  wrote:

> Hello,
>
> I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/)
> since it was first proposed for Python 3.8. It's been deferred for some
> time and I'm interested in seeing it in Python 3.11, but I know there were
> also a number of objections which resulted in it being deferred (including
> by one of the original authors, Mr. Dower). I did email both Mr. Dower and
> Mr. Haase and they graciously gave me their permission to bring it up on
> this list for discussion and hopefully final pronouncement one way or the
> other.
>
> I personally believe that the PEP will result in a significant reduction
> in boilerplate code, and it is substantially similar to the same operators
> now found in a number of other languages, especially C# and JavaScript (
> https://wikipedia.org/wiki/Null_coalescing_operator and
> https://wikipedia.org/wiki/Safe_navigation_operator).
>
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding (and that adding
> additional support for it to the language will increase the use of None in
> this way), but I also believe there are many use cases in programming where
> it is by far the simplest way to express various semantics, and the fact
> exists that None is already used extensively in large quantities of code,
> and further that there is already a great deal of code written to
> constantly test against None and break out of a statement without throwing
> an error.
>
> I also understand the argument that especially the maybe-dot (?.) and
> maybe-subscript (?[) operators can decrease readability of code and also
> believe these are valid arguments against it. While I believe the existence
> and use of these operators in other languages definitely helps the case
> that these can be used and understood successfully, I think it is entirely
> valid to either consider other syntax (though I prefer the chosen syntax of
> PEP 505), or even to reduce PEP 505 to having only the coalesce operator
> (??) and the maybe-assign operator (??=).
>
> Separately, I have implemented a pure-Python solution for PEP505 (which is
> definitely rather beta) which might help test the waters for a final
> implementation in CPython (though the CPython implementation would of
> course be much more efficient). It can be found at
> https://pypi.org/project/pep505/
>
> Thanks,
> Doug
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/XP6V7TKZJYHYUIGH7QWMD6TX3XUBKWEW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Steve Dower 
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
 >
 > class Book(DBModel)
 >     publisher: ForeignKey[Publisher] | None


Imagine wanting to get the phone number of the person that published a 
certain book from the database.

In this situation, with maybe-dot operator I can write:

 > phone_number = book.publisher?.owner?.phone


Consider today, you wrote this as "book.publisher.owner.phone". You 
would potentially get AttributeError, from any one of the elements - no 
way to tell which, and no way to react.


Generally, AttributeError indicates that you've provided a value to an 
API which doesn't fit its pattern. In other words, it's an error about 
the *type* rather than the value.


But in this case, the (semantic, not implementation) *type* is known and 
correct - it's a publisher! It just happens that the API designed it 
such that when the *value* is unknown, the *type* no longer matches.


This is PRECISELY the kind of (IMHO, bad) API design that None-aware 
operators will encourage.



Consider an alternative:

class ForeignKey:
...
def __bool__(self):
return not self.is_dbnull

def value(self):
if self.is_dbnull:
return self.Type.empty() # that is, DBModel.empty()
return self._value


class DBModel:
@classmethod
def empty(cls):
return cls(__secret_is_empty_flag=True)

def __bool__(self):
return not self._is_empty

def __getattr__(self, key):
if not self:
t = self._get_model_type(key)
return t.empty() if isinstance(t, DBModel) else None
...

class User(DBModel):
phone: str | None

class Publisher(DBModel):
owner: ForeignKey[User]

class Book(DBModel)
publisher: ForeignKey[Publisher]


Okay, so as the API implementer, I've had to do a tonne more work. 
That's fine - *that's my job*. The user hasn't had to stick "| None" 
everywhere (and when we eventually get around to allowing named 
arguments in indexing then they could use "ForeignKey[User, 
non_nullable=True]", but I guess for now that would be some subclass of 
ForeignKey).


But now here's the example again:

> book.publisher.owner.phone

If there is no publisher, it'll return None. If there is no owner, it'll 
return None. If the owner has no phone number, it'll return None.


BUT, if you misspell "owner", it will raise AttributeError, because you 
referenced something that is not part of the *type*. And that error will 
be raised EVERY time, not just in the cases where 'publisher' is 
non-null. It takes away the random value-based errors we've come to love 
from poorly coded web sites and makes them reliably based on the value's 
type (and doesn't even require a type checker ;) ).


Additionally, if you want to explicitly check whether a FK is null, you 
can do everything with regular checks:


if book.publisher.owner:
# we know the owner!
else:
# we don't know

# Get all owner names - including where the name is None - but only if
# Mrs. None actually published a book (and not just because we don't
# know a book's publisher or a publisher's owner)
owners = {book.id: book.publisher.owner.name
  for book in all_books
  if book.publisher.owner}

# Update a null FK with a lazy lookup
book.publisher = book.publisher or publishers.get(...)


You can't do anything useful with a native None here besides test for 
it, and there are better ways to do that test. So None is not a useful 
value compared to a rich DBModel subclass that *knows* it is empty.


---

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 than 
coming up with good ones.


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BRTRKGY6RLTHZJQ2US4LO7DYLSGXQ5GM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

2021-10-18 Thread Guido van Rossum 
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
Python users, but not of Python core devs). I worry that the experienced
folks may perhaps be a little too eager to protect newbies from shooting
themselves in the foot.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/T2COU25XL36VTCSJVMN45SZNPSFZH2GD/
Code of Conduct: http://python.org/psf/codeofconduct/