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
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:
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 = interpret
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,
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
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
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
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 bas
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 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
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)
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
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
Pytho
13 matches
Mail list logo
