[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 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.
Possibly. But in *my* case, I'm not arguing from the position of a
large system builder, but from that of a script writer (albeit an
experienced one) and code maintainer (usually of my own code).
I find y = config?.get("handler")?.get("parameters")?.get("y")
unreadable and confusing, and I'd probably advise strongly against it
if someone ever showed me code containing it. I see y =
get_config(config, "handler", "parameters", "y") as *far* more
readable and expressing the intent more directly.
Yes, I find Steve's arguments persuasive, but they are not the ones
I'd be concerned with when advising a newcomer. Rather I'd be saying
"do you see how using a named function expresses your intent better?"
and "do you see how writing a small function hides the messiness of
checking for None so that your main code is cleaner?"
*Shrug* I guess I just don't understand how people can look at a
string of ?.get() and see it as readable and obvious :-(
Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/QOWSJXN3WE7WLUYB22HZNOZJ6GGGRWVF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 API, whereas I was talking more
about using existing solutions.
The provided example was based on common situations encountered when
writing the code in Django. It may be that I'm using this tool not to its
full potential, but it seems like many of your points were about bad API
design, not the actual maybe-dot operator.
Such operator would make it much easier to work with those frameworks that
do not allow for more readable/well thought-out solutions. I'm thinking
about it as a syntactic sugar that can speed things up (and even make it
more readable) in a situation where there is no time and/or budget to come
up with a better architecture (like e.g. the one you have provided). The
reality is that usually from the business perspective nobody wants a well
designed system, only the functioning one.
It may be that I misunderstood your response and didn't provide a valid
answer - please let me know in that case.
Best regards
On Tue, Oct 19, 2021 at 1:29 AM 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 :)
>
> 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 lo
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 18/10/2021 18:50, Senthil Kumaran wrote: 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. ... I tried to build this on ubuntu 18.04, but got the _ssl problem; it definitely has openssl 1.1.1 installed. On updated Arch linux no issue. during configure I see that compiling and linking against openssl works. with the simplest ./configure --prefix=$HOME/LOCAL/3.10.0 I find _ssl is not importable (_socket is). If I try setting --with-openssl-rpath I get _ssl importable, but it fails because _socket is not importable. It's not a big deal as I can install python 3.10.0 using deadsnakes-ubuntu-ppa-bionic ppa. I think the problem here is that I don't seem to have a single openssl root /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/include/openssl/ This all used to work in Python 3.9.x, but I suppose some improvement(s) have been made. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MWMMTAE734FGARKPERO732YYRHUJ6BOE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 19/10/2021 11.57, Robin Becker wrote: On 18/10/2021 18:50, Senthil Kumaran wrote: 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. ... I tried to build this on ubuntu 18.04, but got the _ssl problem; it definitely has openssl 1.1.1 installed. On updated Arch linux no issue. during configure I see that compiling and linking against openssl works. with the simplest ./configure --prefix=$HOME/LOCAL/3.10.0 I find _ssl is not importable (_socket is). If I try setting --with-openssl-rpath I get _ssl importable, but it fails because _socket is not importable. It's not a big deal as I can install python 3.10.0 using deadsnakes-ubuntu-ppa-bionic ppa. I think the problem here is that I don't seem to have a single openssl root /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/include/openssl/ This all used to work in Python 3.9.x, but I suppose some improvement(s) have been made. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions. They have been tested on Debian-like and Fedora-like platforms: https://docs.python.org/3/using/unix.html?highlight=openssl#custom-openssl ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NHTDMNB2W76J43E2JV77RQ37DXWHIGPH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 19/10/2021 11:21, Christian Heimes wrote: On 19/10/2021 11.57, Robin Becker wrote: .. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions. They have been tested on Debian-like and Fedora-like platforms: https://docs.python.org/3/using/unix.html?highlight=openssl#custom-openssl Unfortunately I don't have a custom openssl installation although it may not appear/behave as the python configuration wants. I am using the officially approved installed version of openssl so far as I know. I'm aware that Ubuntu 18.04 is now somewhat out of date, but I would expect a simple configure & make dance to succeed. I'm working with linux for dummies(self) and need to install/update/upgrade openssl, libssl-dev. After that _ssl _hashlib are compiled and importable. I suppose the configure 'compiling with openssl' test is a bit naive. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PIYZS5WFZ4RRATOGSLSSMOS2LR47LKTB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 19/10/2021 17.26, Robin Becker wrote: On 19/10/2021 11:21, Christian Heimes wrote: On 19/10/2021 11.57, Robin Becker wrote: .. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions. They have been tested on Debian-like and Fedora-like platforms: https://docs.python.org/3/using/unix.html?highlight=openssl#custom-openssl Unfortunately I don't have a custom openssl installation although it may not appear/behave as the python configuration wants. I am using the officially approved installed version of openssl so far as I know. I'm aware that Ubuntu 18.04 is now somewhat out of date, but I would expect a simple configure & make dance to succeed. I'm working with linux for dummies(self) and need to install/update/upgrade openssl, libssl-dev. After that _ssl _hashlib are compiled and importable. I suppose the configure 'compiling with openssl' test is a bit naive. We use the standard AX_CHECK_OPENSSL() m4 macro from autoconf-archive to detect OpenSSL. The macro uses pkg-config to detect OpenSSL. It doesn't check for specific version, though. We don't want to prevent people with outdated OpenSSL or LibreSSL from building Python without ssl support. Christian ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ARM25SOTLX7TU6TMCWLUBQZ5HDQHJQVU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 can be written as
>
> y = config?.get("handler")?.get("parameters")?.get("y")
Sure, but the EAFP version is not that bad:
try:
y = config["handler"]["parameters"]["y"]
except KeyError:
y = None
which could be further simplified with an exception-catching expression
(caveat: keyword usage is pure improvisation, it sounds good, but is
probably broken :-) :
y = config["handler"]["parameters"]["y"] with KeyError as None
The PEP authors would probably reject this as "hiding errors in code",
which is true, but none-aware operators also hide errors…
Cheers,
Baptiste
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/JWZ2ZG7AIXXWDGNPUZDVLORDFMMEP3XV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 parameters is not None:
> > y = parameters.get("y")
> >
> > […]
> > Using ?. this can be written as
> >
> > y = config?.get("handler")?.get("parameters")?.get("y")
>
> Sure, but the EAFP version is not that bad:
>
> try:
> y = config["handler"]["parameters"]["y"]
> except KeyError:
> y = None
>
> which could be further simplified with an exception-catching expression
> (caveat: keyword usage is pure improvisation, it sounds good, but is
> probably broken :-) :
>
> y = config["handler"]["parameters"]["y"] with KeyError as None
>
> The PEP authors would probably reject this as "hiding errors in code",
> which is true, but none-aware operators also hide errors…
PEP 463 would like to say hi :)
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/M5XHRRAE3CIQACYHU4Q3TBMFXIUYYI3N/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 there are times when a comprehensive model is good, and that if the DB schema is automatically generated, it should look something like this. But this is long enough that I would be unhappy if it were what I had to read to understand the database in the first place. (Yes, I know Java beans are pretty widely tolerated, but ... that doesn't make longer code desirable.) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OFZZ4PYT4EWTXHZ2PGRO3FBFRPCV4NZC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 is read, so attempting to access `book?.publisher?.onwer?.name` will still fail with `AttributeError`. Type checkers would also continue being able to check such navigation. Doug ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V4PK74K7W74EJ5XMXPEB6FLAZCDJ6SCN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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 not None:
> > > parameters = handler.get("parameters")
> > > if parameters is not None:
> > > y = parameters.get("y")
> > >
> > > […]
> > > Using ?. this can be written as
> > >
> > > y = config?.get("handler")?.get("parameters")?.get("y")
> >
> > Sure, but the EAFP version is not that bad:
> >
> > try:
> > y = config["handler"]["parameters"]["y"]
> > except KeyError:
> > y = None
> >
> > which could be further simplified with an exception-catching expression
> > (caveat: keyword usage is pure improvisation, it sounds good, but is
> > probably broken :-) :
> >
> > y = config["handler"]["parameters"]["y"] with KeyError as None
> >
> > The PEP authors would probably reject this as "hiding errors in code",
> > which is true, but none-aware operators also hide errors…
>
> PEP 463 would like to say hi :)
>
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.
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? The languages SAS and R
support at least 27 varieties of NA, allowing un-tagged, and tagged with
the letters A-Z to help someone create distinctions between different kinds
of nothingness. IEEE-754 allows about 16 million possible NaNs, which I
believe was intended to allow floating point instructions to pass error
messages along.
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 argument to `attrgetter`, and it's a lighter touch than
implementing a new operator. If use becomes widespread, that gives more
weight to PEP 505.
def attrgetter(*attrs, none_aware=False)
https://docs.python.org/3/library/operator.html#operator.attrgetter
Apologies if attrgetter has already been discussed. I didn't see mention of
it in PEP 505.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/R5NO5H5BCEIGEUCLPRE7WW5AEG5MRX3Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 670: Convert macros to functions in the Python C API
Hi,
Erlend and me wrote a PEP to move away from macros in the Python C
API. We are now waiting for feedback :-) Read the PEP online:
https://www.python.org/dev/peps/pep-0670/
There is a copy of the PEP below for inline replies.
Victor
---
PEP: 670
Title: Convert macros to functions in the Python C API
Author: Erlend Egeberg Aasland ,
Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Oct-2021
Python-Version: 3.11
Abstract
Convert macros to static inline functions or regular functions.
Remove the return value of macros having a return value, whereas they
should not, to aid detecting bugs in C extensions when the C API is
misused.
Some function arguments are still cast to ``PyObject*`` to prevent
emitting new compiler warnings.
Rationale
=
The use of macros may have unintended adverse effects that are hard to
avoid, even for experienced C developers. Some issues have been known
for years, while others have been discovered recently in Python.
Working around macro pitfalls makes the macro coder harder to read and
to maintain.
Converting macros to functions has multiple advantages:
* By design, functions don't have macro pitfalls.
* Arguments type and return type are well defined.
* Debuggers and profilers can retrieve the name of inlined functions.
* Debuggers can put breakpoints on inlined functions.
* Variables have a well defined scope.
* Code is usually easier to read and to maintain than similar macro
code. Functions don't need the following workarounds for macro
pitfalls:
* Add parentheses around arguments.
* Use line continuation characters if the function is written on
multiple lines.
* Add commas to execute multiple expressions.
* Use ``do { ... } while (0)`` to write multiple statements.
Converting macros and static inline functions to regular functions makes
these regular functions accessible to projects which use Python but
cannot use macros and static inline functions.
Macro Pitfalls
==
The `GCC documentation
`_ lists several
common macro pitfalls:
- Misnesting
- Operator precedence problems
- Swallowing the semicolon
- Duplication of side effects
- Self-referential macros
- Argument prescan
- Newlines in arguments
Performance and inlining
Static inline functions is a feature added to the C99 standard. Modern C
compilers have efficient heuristics to decide if a function should be
inlined or not.
When a C compiler decides to not inline, there is likely a good reason.
For example, inlining would reuse a register which require to
save/restore the register value on the stack and so increase the stack
memory usage or be less efficient.
Debug build
---
When Python is built in debug mode, most compiler optimizations are
disabled. For example, Visual Studio disables inlining. Benchmarks must
not be run on a Python debug build, only on release build: using LTO and
PGO is recommended for reliable benchmarks. PGO helps the compiler to
decide if function should be inlined or not.
Force inlining
--
The ``Py_ALWAYS_INLINE`` macro can be used to force inlining. This macro
uses ``__attribute__((always_inline))`` with GCC and Clang, and
``__forceinline`` with MSC.
So far, previous attempts to use ``Py_ALWAYS_INLINE`` didn't show any
benefit and were abandoned. See for example: `bpo-45094
`_: "Consider using
``__forceinline`` and ``__attribute__((always_inline))`` on static
inline functions (``Py_INCREF``, ``Py_TYPE``) for debug build".
When the ``Py_INCREF()`` macro was converted to a static inline
functions in 2018 (`commit
`__),
it was decided not to force inlining. The machine code was analyzed with
multiple C compilers and compiler options: ``Py_INCREF()`` was always
inlined without having to force inlining. The only case where it was not
inlined was the debug build. See discussion in the `bpo-35059
`_: "Convert ``Py_INCREF()`` and
``PyObject_INIT()`` to inlined functions".
Disable inlining
On the other side, the ``Py_NO_INLINE`` macro can be used to disable
inlining. It is useful to reduce the stack memory usage. It is
especially useful on a LTO+PGO build which is more aggressive to inline
code: see `bpo-33720 `_. The
``Py_NO_INLINE`` macro uses ``__attribute__ ((noinline))`` with GCC and
Clang, and ``__declspec(noinline)`` with MSC.
Specification
=
Convert macros to static inline functions
-
Most macros should be converted to static inline functions to prevent
`macro pitfalls`_.
The following macros should not be converted:
* Empty macros. Example: ``#define Py_HAVE_CONDVAR``.
* Macros only defining a number, even if a c
[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API
Extra info that I didn't put in the PEP to keep the PEP short. Since Python 3.8, multiple macros have already been converted, including Py_INCREF() and Py_TYPE() which are very commonly used and so matter for Python performance. Macros converted to static inline functions: * Py_INCREF(), Py_DECREF(), Py_XINCREF(), Py_XDECREF(): Python 3.8 * PyObject_INIT(), PyObject_INIT_VAR(): Python 3.8 * Private functions: _PyObject_GC_TRACK(), _PyObject_GC_UNTRACK(), _Py_Dealloc(): Python 3.8 * Py_REFCNT(): Python 3.10 * Py_TYPE(), Py_SIZE(): Python 3.11 Macros converted to regular functions in Python 3.9: * PyIndex_Check() * PyObject_CheckBuffer() * PyObject_GET_WEAKREFS_LISTPTR() * PyObject_IS_GC() * PyObject_NEW(): alias to PyObject_New() * PyObject_NEW_VAR(): alias to PyObjectVar_New() To keep best performances on Python built without LTO, fast private variants were added as static inline functions to the internal C API: * _PyIndex_Check() * _PyObject_IS_GC() * _PyType_HasFeature() * _PyType_IS_GC() -- Many of these changes have been made to prepare the C API to make these structure opaque: * PyObject: https://bugs.python.org/issue39573 * PyTypeObject: https://bugs.python.org/issue40170 Don't access structure members at the ABI level, but abstract them through a function call. Some functions are still static inline functions (and so still access structure members at the ABI level), since the performance impact of converting them to regular functions was not measured yet. Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U7TKPCJ5FQJHEIUXZIZRYZL4ZWU5WSE6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API
One of my motivation to write this PEP was decide how to solve the issue: "[C API] Disallow using PyFloat_AS_DOUBLE() as l-value" https://bugs.python.org/issue45476 I proposed two fixes: * Convert macros to static inline functions: https://github.com/python/cpython/pull/28961 * Fix the macro, add _Py_RVALUE(): https://github.com/python/cpython/pull/28976 I would prefer to static inline functions ;-) Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HSLZAOEJLSBS4F2YRHJEXYQHCTDNKLU6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
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, the whole discussion reminds me of wg21.link/p0798, which is about adding something quite similar to C++ (was accepted into C++23), and contains a decent overview of how other languages solve the same thing. Even though the approach there is probably not applicable (as all python types are implicitly `Optional` in the sense of "can be None", i.e. that API would have to be added all the way down to `object`), it's still ironic that C++'s `and_then` looks more pythonic than what's proposed here. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6JD5VGTVE2TVHUMU7OWIYT7QJEKAGRI7/ Code of Conduct: http://python.org/psf/codeofconduct/
