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

[Baptiste Carvello]

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 true as a general rule: the PEP 505 examples with
`dict.get()` do catch too much.

Also, if `None` is not special, you are free to make up your own
`NoValue` sentinel object, which can raise specific exceptions on
attribute access, item access, etc:

class NoValueError(Exception):
  pass

class NoValueAttributeError(AttributeError, NoValueError):
  pass

and so on…

So this particular point seems solvable.

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/J4R3QHH7GNMJAP6VPP2LVXMAAO2YAKU2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 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.
> 
> I agree that this is a nice way forward, and a useful function in its 
> own right.

On further thought, I no longer agree. Or at least, I think we need to 
think a lot harder about the API before adding any sort of chained 
attribute getter into the stdlib. If we get it wrong, we'll be stuck 
with it until Python 5000.

The problem is that any sort of code equivalent to:

try:
return obj.chain.of.attribute.lookups
except AttributeError:
return None

risks silently hiding genuine coding errors. This seems to be an 
anti-pattern, or at least a foot-gun. And it is certainly not equivalent 
to, or a replacement for, PEP 505.

Same applies to variants similar to attrgetter.



-- 
Steve
___
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/IRO7Z2IEV3I7X5EZZRNWCLDMJRCWALGS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 trap.
> 
> This is not true as a general rule: the PEP 505 examples with
> `dict.get()` do catch too much.

The problem there is not the None-aware operators, but the use of 
dict.get. That's a good reason to re-think None-aware subscripting.

dict?['key']

will still raise if you mistype the key, while dict.get does not.

Even if we limit ourselves to dict.get:

return obj?.get('spam')?.get('eggs')

doesn't protect against mispellings of the keys, *due to dict.get*, but 
it does protect against mispelling "get" (unlikely). More importantly it 
also protects against type errors:

obj['spam'] = {'eggs', value}  # oops, a set, not a dict

or equivalent. (I don't mean to limit this to just typos.)

Now if we write:

obj?.get('spam')?.get('eggs')

the first attribute lookup will return a set and the second will fail 
because sets don't have a get method.

Where as if we use exceptions:

try:
obj['spam]['eggs']
except (TypeError, KeyError):
return None

the error is silently suppressed and we get None when we should get a 
TypeError.



-- 
Steve
___
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/WYEIZ3IC6P6KN4L2MROV4SBCZ5XOQUV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API

[Victor Stinner]

On Wed, Oct 20, 2021 at 10:58 AM Petr Viktorin  wrote:
> I think this info should be in the PEP.

Ok, we added (and completed) the list to the PEP:
https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8

> If the PEP is rejected, would all these previous changes need to be
> reverted? Or just the ones done in 3.11?

I don't know. I guess that it can be decided once the PEP will be rejected :-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/QHL2ACN7LU6XKUZRW44A43LHHXLUUE3M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API

[Dong-hee Na]

Well, I discussed this issue hundreds of times with Victor Stinner.

I believe that this is what we have to go even if there is a very
little minor performance issue, it will be not a big hurdle.
we can see the benchmark from https://speed.python.org/ and CPython become
faster and faster.
Converting macros to functions will overcome the issue which has been
pointed out as known as implementation detail leak.

Regards,
Dong-hee

2021년 10월 20일 (수) 오전 9:59, Victor Stinner 님이 작성:

> 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
> <
> https://github.com/python/cpython/commit/2aaf0c12041bcaadd7f2cc5a54450eefd7a6ff12
> >`__),
> 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, 

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Larry Hastings]

On 10/21/21 5:01 AM, Henry Fredrick Schreiner wrote:
PEP 649 was about the same as the current performance, but PEP 563 was 
significantly faster, since it doesn’t instantiate or deal with 
objects at all, which both the current default and PEP 563 do.


I don't understand what you're saying about how PEP 563 both does and 
doesn't instantiate objects.


PEP 649, and the current implementation of PEP 563, are definitely both 
faster than stock behavior when you don't examine annotations; both of 
these approaches don't "instantiate or deal with objects" unless you 
examine the annotations.  PEP 649 is roughly the same as stock when you 
do examine annotations.  PEP 563 is faster if you only ever examine the 
annotations as strings, but becomes /enormously/ slower if you examine 
the annotations as actual Python values.


The way I remember it, most of the negative feedback about PEP 649's 
performance concerned its memory consumption.  I've partially addressed 
that by always lazy-creating the function object.  But, again, I suggest 
that performance is a distraction at this stage.  The important thing is 
to figure out what semantics we want for the language.  We have so many 
clever people working on CPython, I'm sure this team will make whatever 
semantics we choose lean and performant.



//arry/

___
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/XRATIM3V543XVD4U22T45UJ43ZPLTUU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 3118 C APIs

[Joannah Nanjekye]

Last year I opened the following issues, to implement
int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject
*obj).

They were meant to be as part of PEP 3118, I wonder if they are worth an
effort now.

https://bugs.python.org/issue39835
https://bugs.python.org/issue39836

Joannah

-- 
Best,
Joannah Nanjekye

*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
___
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/B5L53O5OCOKPP7H44PVPTGF4AIQWK4GQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Semi-proposal: Tagged None

[David Mertz, Ph.D.]

On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano  wrote:

> 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?
>


> 30+ years later, and we cannot easily, reliably or portably use NAN
> payloads. Most people don't care. If we offerred them a dozen or a
> thousand distinct sentinels for all the various kinds of missing data,
> how many people would use them and how many would just stick to plain
> old None?


In data science, I have been frustrated by the sparsity of ways of spelling
"missing value."

Besides the distinction Michael points out, and that Steven did in relation
to NaNs with payloads, I encounter missingness of various other sorts as
well.  Crucially,  an important kind of missing data is data where the
value I received seems unreliable and I have decided to *impute*
missingness rather than accept a value I believe is unreliable.

But there is also something akin to what Michael points out (maybe it's
just an example).  For example, "middle name" is something that some people
simply do not have, other people choose not to provide on a survey, and
others still we just don't know anything beyond "it's not there."

Of course, when I impute missingness, I can do so at various stages of data
cleaning, and for various different reasons or confidences.  None (or NaN)
are sort of OK, but carrying metadata as to the nature of missingness would
be nice.

So my strawman suggestion is tagging None's.  I suppose spellings like
`None[reason]` or `None(reason)` are appealing.

An obvious problem that I recognize is that it's not obvious this can "play
nice" with the common idiom `if mydata is not None: ...`.  None really is a
singleton, and a "tagged singleton" or "annotated singleton" probably
doesn't work well with Python's object model.

My goal, of course, would be to have TaggedNone be a kind of subclass of
None, in the same way that bool is a subclass of int, and hence True is a
kind of 1.  However, I'd want a large number of custom None's, with some
sort of accessible string or numeric code or something to inspect which one
it was.

-- 
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 -- 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/HAGJBRBXVWGGU2HRMVEWRNQSGUD75IYT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Semi-proposal: Tagged None

[Chris Angelico]

On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
 wrote:
>
> On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano  wrote:
>>
>> 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?
>
>
>>
>> 30+ years later, and we cannot easily, reliably or portably use NAN
>> payloads. Most people don't care. If we offerred them a dozen or a
>> thousand distinct sentinels for all the various kinds of missing data,
>> how many people would use them and how many would just stick to plain
>> old None?
>
>
> In data science, I have been frustrated by the sparsity of ways of spelling 
> "missing value."

Might be worth redirecting this to -ideas.

> Besides the distinction Michael points out, and that Steven did in relation 
> to NaNs with payloads, I encounter missingness of various other sorts as 
> well.  Crucially,  an important kind of missing data is data where the value 
> I received seems unreliable and I have decided to *impute* missingness rather 
> than accept a value I believe is unreliable.
>
> But there is also something akin to what Michael points out (maybe it's just 
> an example).  For example, "middle name" is something that some people simply 
> do not have, other people choose not to provide on a survey, and others still 
> we just don't know anything beyond "it's not there."
>

And some people have more than one (I have a brother with two of
them). Not the best example to use, since names have WAY more
complexities than different types of absence, but there are other
cases where that sort of thing comes up. For instance, if someone says
on a survey that s/he is in Australia, and then you ask for a
postcode, then leaving it blank should be recorded as "chose not to
provide"; but if the country is listed as Timor-Leste / East Timor,
then "not applicable" would be appropriate, since the country doesn't
use postal codes.

> Of course, when I impute missingness, I can do so at various stages of data 
> cleaning, and for various different reasons or confidences.  None (or NaN) 
> are sort of OK, but carrying metadata as to the nature of missingness would 
> be nice.
>

Right. Using postcodes as an example again, for someone in Australia,
a postcode of "E3B 0H8" doesn't make sense, as that isn't the format
we use. So you could wipe that out and replace it with "No postal
code, malformed data entered".

> So my strawman suggestion is tagging None's.  I suppose spellings like 
> `None[reason]` or `None(reason)` are appealing.
>
> An obvious problem that I recognize is that it's not obvious this can "play 
> nice" with the common idiom `if mydata is not None: ...`.  None really is a 
> singleton, and a "tagged singleton" or "annotated singleton" probably doesn't 
> work well with Python's object model.
>
> My goal, of course, would be to have TaggedNone be a kind of subclass of 
> None, in the same way that bool is a subclass of int, and hence True is a 
> kind of 1.  However, I'd want a large number of custom None's, with some sort 
> of accessible string or numeric code or something to inspect which one it was.
>

But this is where I start to disagree. None should remain a singleton,
but "no data available" could be its own thing, tied in with the way
that you do your data storage and stats. As such, you wouldn't be
checking it with 'is', so you wouldn't have that problem (the Python
'is' operator will only ever test for actual object identity).

Keep None simple and dependable, and then "Missing Data" can be an
entire class of values if you so desire.

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/6NY5NQCJR3ROFBWWFOVD47HJFBQJC3IZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Damian Shaw]

Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP
649?

I think I've seen others mention this but as the code object isn't executed
until inspected then if you are just using annotations for type hints it
should work fine?

Is the use case wanting to use annotations for type hints and real time
inspection but you also don't want to import the objects at run time?

If that's really such a strong use cause couldn't PEP 649 be modified to
return a repr of the code object when it gets a NameError? Either by
attaching it to the NameError exception or as part of a ForwardRef style
object if that's how PEP 649 ends up getting implemented?

Damian (he/him)

On Thu, Oct 21, 2021, 00:05 Henry Fredrick Schreiner <
henry.fredrick.schrei...@cern.ch> wrote:

> > typing features from future Python versions
>
> I second both of these uses, but especially this (which seems to be
> missing from the original post), it’s been by far the main reason I’ve used
> this mode and I’ve seen this used, and is the main feature to look forward
> to when dropping Python 3.7 support. The new features coming to typing make
> static typing much easier, but no libraries can drop Python 3.7/3.8/3.9
> support; but static typing doesn’t need old versions.
>
> When talking about speed, one of the important things to consider here is
> the difference between the two proposals. PEP 649 was about the same as the
> current performance, but PEP 563 was significantly faster, since it doesn’t
> instantiate or deal with objects at all, which both the current default and
> PEP 563 do. You could even protect imports with TYPE_CHECKING with PEP 563,
> and further reduce the runtime cost of adding types - which could be seen
> as a reason to avoid adding types. To the best of my knowledge, it hasn’t
> been a blocker for packages, but something to include.
>
> Also, one of the original points for static typing is that strings can be
> substituted for objects. “Type” is identical, from a static typing
> perspective, to Type. You can swap one for the other, and for a Python 3.6+
> codebase, using something like “A | B” (with the quotes) is a valid way
> to have static types in 3.6 that pass MyPy (though are not usable at
> runtime, obviously, but that’s often not a requirement). NumPy, for
> example, makes heavy usage of unions and other newer additions in static
> typing.
> ___
> 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/L3IKBO5YZNQ2B5Y6VA7KX352VCOCQEBB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YZYND5RYBZRRCZY7J3HSE5RXP4JTUENC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Semi-proposal: Tagged None

[David Mertz, Ph.D.]

I've moved this to python-ideas where it is more appropriate, as Chris
notes

On Thu, Oct 21, 2021, 8:42 PM Chris Angelico  wrote:

> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
>  wrote:
> >
> > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano 
> wrote:
> >>
> >> 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?
> >
> >
> >>
> >> 30+ years later, and we cannot easily, reliably or portably use NAN
> >> payloads. Most people don't care. If we offerred them a dozen or a
> >> thousand distinct sentinels for all the various kinds of missing data,
> >> how many people would use them and how many would just stick to plain
> >> old None?
> >
> >
> > In data science, I have been frustrated by the sparsity of ways of
> spelling "missing value."
>
> Might be worth redirecting this to -ideas.
>
> > Besides the distinction Michael points out, and that Steven did in
> relation to NaNs with payloads, I encounter missingness of various other
> sorts as well.  Crucially,  an important kind of missing data is data where
> the value I received seems unreliable and I have decided to *impute*
> missingness rather than accept a value I believe is unreliable.
> >
> > But there is also something akin to what Michael points out (maybe it's
> just an example).  For example, "middle name" is something that some people
> simply do not have, other people choose not to provide on a survey, and
> others still we just don't know anything beyond "it's not there."
> >
>
> And some people have more than one (I have a brother with two of
> them). Not the best example to use, since names have WAY more
> complexities than different types of absence, but there are other
> cases where that sort of thing comes up. For instance, if someone says
> on a survey that s/he is in Australia, and then you ask for a
> postcode, then leaving it blank should be recorded as "chose not to
> provide"; but if the country is listed as Timor-Leste / East Timor,
> then "not applicable" would be appropriate, since the country doesn't
> use postal codes.
>
> > Of course, when I impute missingness, I can do so at various stages of
> data cleaning, and for various different reasons or confidences.  None (or
> NaN) are sort of OK, but carrying metadata as to the nature of missingness
> would be nice.
> >
>
> Right. Using postcodes as an example again, for someone in Australia,
> a postcode of "E3B 0H8" doesn't make sense, as that isn't the format
> we use. So you could wipe that out and replace it with "No postal
> code, malformed data entered".
>
> > So my strawman suggestion is tagging None's.  I suppose spellings like
> `None[reason]` or `None(reason)` are appealing.
> >
> > An obvious problem that I recognize is that it's not obvious this can
> "play nice" with the common idiom `if mydata is not None: ...`.  None
> really is a singleton, and a "tagged singleton" or "annotated singleton"
> probably doesn't work well with Python's object model.
> >
> > My goal, of course, would be to have TaggedNone be a kind of subclass of
> None, in the same way that bool is a subclass of int, and hence True is a
> kind of 1.  However, I'd want a large number of custom None's, with some
> sort of accessible string or numeric code or something to inspect which one
> it was.
> >
>
> But this is where I start to disagree. None should remain a singleton,
> but "no data available" could be its own thing, tied in with the way
> that you do your data storage and stats. As such, you wouldn't be
> checking it with 'is', so you wouldn't have that problem (the Python
> 'is' operator will only ever test for actual object identity).
>
> Keep None simple and dependable, and then "Missing Data" can be an
> entire class of values if you so desire.
>
> 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/6NY5NQCJR3ROFBWWFOVD47HJFBQJC3IZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/CFNI2QLBJ5D3YOQZ2TSZHZHQCPXCGAUN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Carl Meyer]

On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
 wrote:
> Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP 
> 649?
>
> I think I've seen others mention this but as the code object isn't executed 
> until inspected then if you are just using annotations for type hints it 
> should work fine?
>
> Is the use case wanting to use annotations for type hints and real time 
> inspection but you also don't want to import the objects at run time?

Yes, you're right. And I don't think PEP 649 and PEP 563 are really
all that different in this regard: if you have an annotation using a
non-imported name, you'll be fine as long as you don't introspect it
at runtime. If you do, you'll get a NameError. And with either PEP you
can work around this if you need to by ensuring you do the imports
first if you're going to need the runtime introspection of the
annotations.

The difference is that PEP 563 makes it easy to introspect the
annotation _as a string_ without triggering NameError, and PEP 649
takes that away, but I haven't seen anyone describe a really
compelling use case for that.

> If that's really such a strong use cause couldn't PEP 649 be modified to 
> return a repr of the code object when it gets a NameError? Either by 
> attaching it to the NameError exception or as part of a ForwardRef style 
> object if that's how PEP 649 ends up getting implemented?

It could, but this makes evaluation of annotations oddly different
from evaluation of any other code, which is something that it's
reasonable to try to avoid if possible.

Carl
___
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/7ZVH5ADSQ7LTBPMZY6FOUGIJUBF33JPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Larry Hastings]

On 10/21/21 5:42 PM, Damian Shaw wrote:
Sorry for the naive question but why doesn't "TYPE_CHECKING" work 
under PEP 649?


I think I've seen others mention this but as the code object isn't 
executed until inspected then if you are just using annotations for 
type hints it should work fine?


Yes, it works fine in that case.


Is the use case wanting to use annotations for type hints and real 
time inspection but you also don't want to import the objects at run time?


If that's really such a strong use cause couldn't PEP 649 be modified 
to return a repr of the code object when it gets a NameError? Either 
by attaching it to the NameError exception or as part of a ForwardRef 
style object if that's how PEP 649 ends up getting implemented?


That's the use case.

Your proposal is one of several suggesting that type annotations are 
special enough to break the rules.  I don't like this idea. But you'll 
be pleased to know there are a lot of folks in the "suppress the 
NameError" faction, including Guido (IIUC).


See also this PR against co_annotations, proposing returning a new 
AnnotationName object when evaluating the annotations raises a NameError.


   https://github.com/larryhastings/co_annotations/pull/3


Cheers,


//arry/

___
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/O75ZCWHRCZEINYRO2QJFKKWXP4GW2WVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Jelle Zijlstra]

El jue, 21 oct 2021 a las 10:31, Carl Meyer () escribió:

> On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
>  wrote:
> > Sorry for the naive question but why doesn't "TYPE_CHECKING" work under
> PEP 649?
> >
> > I think I've seen others mention this but as the code object isn't
> executed until inspected then if you are just using annotations for type
> hints it should work fine?
> >
> > Is the use case wanting to use annotations for type hints and real time
> inspection but you also don't want to import the objects at run time?
>
> Yes, you're right. And I don't think PEP 649 and PEP 563 are really
> all that different in this regard: if you have an annotation using a
> non-imported name, you'll be fine as long as you don't introspect it
> at runtime. If you do, you'll get a NameError. And with either PEP you
> can work around this if you need to by ensuring you do the imports
> first if you're going to need the runtime introspection of the
> annotations.
>
> The difference is that PEP 563 makes it easy to introspect the
> annotation _as a string_ without triggering NameError, and PEP 649
> takes that away, but I haven't seen anyone describe a really
> compelling use case for that.
>
> I would want this for my type checker, pyanalyze. I'd want to get the raw
annotation and turn it into a type. For example, if the annotation is
`List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
least still be able to extract `List[Any]` instead of bailing out
completely. With some extra analysis work on the module I could even get
the real type out of the `if TYPE_CHECKING` block.
___
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/Y2647QWRAOYLL22UWZL37DKAEUK22UIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Carl Meyer]

On Thu, Oct 21, 2021 at 12:06 PM Jelle Zijlstra
 wrote:

> I would want this for my type checker, pyanalyze. I'd want to get the raw 
> annotation and turn it into a type. For example, if the annotation is 
> `List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at 
> least still be able to extract `List[Any]` instead of bailing out completely. 
> With some extra analysis work on the module I could even get the real type 
> out of the `if TYPE_CHECKING` block.

If you're up for the extra analysis on the module, wouldn't it be just
as possible to front-load this analysis instead of doing it after the
fact, and perform the imports in the `if TYPE_CHECKING` block prior to
accessing the annotation data? Or perform a fake version of the
imports that just sets every name imported in `if TYPE_CHECKING` to
`Any`?

Carl
___
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/PEJBJBSFTTA4U3BXQW2N6ABGL5A4V2NF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Semi-proposal: Tagged None

[Jelle Zijlstra]

El jue, 21 oct 2021 a las 10:25, David Mertz, Ph.D. ()
escribió:

> I've moved this to python-ideas where it is more appropriate, as Chris
> notes
>
> On Thu, Oct 21, 2021, 8:42 PM Chris Angelico  wrote:
>
>> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
>>  wrote:
>> >
>> > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano 
>> wrote:
>> >>
>> >> 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?
>> >
>> >
>> >>
>> >> 30+ years later, and we cannot easily, reliably or portably use NAN
>> >> payloads. Most people don't care. If we offerred them a dozen or a
>> >> thousand distinct sentinels for all the various kinds of missing data,
>> >> how many people would use them and how many would just stick to plain
>> >> old None?
>> >
>> >
>> > In data science, I have been frustrated by the sparsity of ways of
>> spelling "missing value."
>>
>> Might be worth redirecting this to -ideas.
>>
>> > Besides the distinction Michael points out, and that Steven did in
>> relation to NaNs with payloads, I encounter missingness of various other
>> sorts as well.  Crucially,  an important kind of missing data is data where
>> the value I received seems unreliable and I have decided to *impute*
>> missingness rather than accept a value I believe is unreliable.
>> >
>> > But there is also something akin to what Michael points out (maybe it's
>> just an example).  For example, "middle name" is something that some people
>> simply do not have, other people choose not to provide on a survey, and
>> others still we just don't know anything beyond "it's not there."
>> >
>>
> This feels like something you should express with an enum for all the
different kinds of missing data:

class MissingReason(enum.Enum):
no_middle_name = 1
not_provided = 2
unknown = 3

middle_name: str | MissingReason

This gives you more structured and precise data than None-plus-string-tag
and avoids breaking the ecosystem by changing the meaning and behavior of
None.
___
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/EOBURF7EFGD5CLZS35GFTCWYZU2M7RDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Guido van Rossum]

On Thu, Oct 21, 2021 at 10:35 AM Larry Hastings  wrote:

> .
>
> Your proposal is one of several suggesting that type annotations are
> special enough to break the rules.  I don't like this idea.  But you'll be
> pleased to know there are a lot of folks in the "suppress the NameError"
> faction, including Guido (IIUC).
>

Yes, I still want this part of your PEP changed. I find your
characterization of my position misleading -- there is no rule to break
here(*), just an API.

(*) The Zen of Python does not have rules.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun 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/D673XEJ2CEFYF2HZ72ADQBRYGRTDAEOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Łukasz Langa]

> On 20 Oct 2021, at 15:18, Thomas Wouters  wrote:
> 
> (For visibility, posted both to python-dev and Discourse.)


Since this got split into Discourse and python-dev, I wrote my take on the 
issue on the blog so that I could post it in both spaces with proper formatting 
and everything:

https://lukasz.langa.pl/61df599c-d9d8-4938-868b-36b67fdb4448/ 



- Ł


signature.asc
Description: Message signed with OpenPGP
___
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/SZF6NSYGGACL7YEYEFUB7F46RSI7HBQW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Larry Hastings]

It's certainly not my goal to be misleading.  Here's my perspective.

In Python, if you evaluate an undefined name, Python raises a 
NameError.  This is so consistent I'm willing to call it a "rule".  
Various folks have proposed an exception to this "rule": evaluating an 
undefined name in an PEP 649 delayed annotation wouldn't raise 
NameError, instead evaluating to some yet-to-be-determined value 
(ForwardRef, AnnotationName, etc).  I don't think annotations are 
special enough to "break the rules" in this way.


Certainly this has the potential to be irritating for code using 
annotations at runtime, e.g. Pydantic.  Instead of catching the 
exception, it'd have to check for this substitute value.   I'm not sure 
if the idea is to substitute for the entire annotation, or for just the 
value that raised NameError; if the latter, Pydantic et al would have to 
iterate over every value in an annotation to look for this special value.


As a consumer of annotations at runtime, I'd definitely prefer that they 
raise NameError rather than silently substitute in this alternative value.



//arry

/

On 10/21/21 8:01 PM, Guido van Rossum wrote:
On Thu, Oct 21, 2021 at 10:35 AM Larry Hastings > wrote:


.

Your proposal is one of several suggesting that type annotations
are special enough to break the rules.  I don't like this idea. 
But you'll be pleased to know there are a lot of folks in the
"suppress the NameError" faction, including Guido (IIUC).


Yes, I still want this part of your PEP changed. I find your 
characterization of my position misleading -- there is no rule to 
break here(*), just an API.


(*) The Zen of Python does not have rules.

--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun 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/T72R3LFOSW4KFHO3GCZW3F2BCTGGAWD4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Add a vendor configuration

[Filipe Laíns]

Hey,

I would like to proposing adding a vendor configuration. You can find the
proposal in the link below.


https://gist.github.com/FFY00/625f65681fbcd7fc039dd4d727bb2c2f

It is essentially bpo-43976 + bpo-44982, and it is partly implemented in
GH-25718.

Cheers,
Filipe Laíns


signature.asc
Description: This is a digitally signed message part
___
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/OWETD7ZHCHX3R4IMGO3YPRC6WABVWGXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] August Steering Council update

[Pablo Galindo Salgado]

I’ve just published the August steering council update, also included below:

https://github.com/python/steering-council/blob/main/updates/2021-08-steering-council-update.md

Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://github.com/python/steering-council

*August 2*

- The Steering Council met with the Developer-in-Residence (Łukasz Langa)
to discuss progress. The group also discussed what the focus should be
going forward and that strategic approaches need to be considered for PRs
instead of individual reviews.
- The Steering Council and Ewa (current PSF Executive Director) discussed
the lack of progress on the GitHub migration project. The contractor will
be meeting with the SC and Ewa next week to discuss progress and a timeline
to wrap up the project by end of October 2021.
- Thomas has several todos that he will take care of this week and he will
also reach out to the [PEP 505](
https://www.python.org/dev/peps/pep-0505/)(None-aware operators) authors to
get a status update.

*August 9*
- The Steering Council had a meeting with the GitHub issues PM (Ezio
Melotti) to learn why there has been a long period of no progress and
advise what needs to be done next. The SC also discussed with Ezio a
deadline of Oct 31 to complete the migration.
- After the call, the SC had a debrief to review how we would proceed
and whether or not we wanted to search for alternative options to complete
the project.
- Ewa drafted an email to Ezio on the next steps for the SC to review. The
email has been sent and Ezio is working on the deliverables. Ewa and Ezio
also had a call with one of our GitHub reps on import tooling.

*August 16*

- The Steering Council met with the Developer-in-Residence, where they gave
an update on their work as well as an update on where the data analytics is
heading. The group also discussed typing annotations and how to approach
the existing PEPs and migration paths.
- The Steering Council decided Thomas would be sending the drafted note to
the author of [PEP 648](
https://www.python.org/dev/peps/pep-0648/)(Extensible customizations of the
interpreter at startup) on Aug 17.
- The group checked in on [PEP 649](
https://www.python.org/dev/peps/pep-0649/)(Deferred Evaluation Of
Annotations Using Descriptors) by Larry Hastings and after some
deliberation decided that a wider discussion is necessary on how these are
handled. Barry suggested a workgroup to analyze things and Pablo reminded
the SC to make sure that all relevant actors that need to be part of that
discussion are present.
- Carol is going to ping Nathaniel and give him until the end of August
to submit a counter-proposal to [PEP 654](
https://www.python.org/dev/peps/pep-0654/)(Exception Groups and except*).

*August 23*

- Ewa scheduled check-in with Ezio for August 30th. SC discussed the code
of conduct situation with M.S. and decided on a one-year ban.
- SC brought up October 2021 sprints. They will be virtual. The group
will continue discussing.

*August 23*

- The Steering Council met with the Developer-in-Residence to discuss
progress and obstacles. They also discussed the CLA workflow and that
Łukasz will communicate with Yury as they were building something similar
for EdgeDB.
- The Steering Council met with Ezio to discuss his progress with the
GitHub migration project. The SC advised Ezio as to what the priority
projects are.

Regards from cloudy London,
Pablo Galindo Salgado
___
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/4WD5IUNGTEWWTMTOAAHLUNYTV4GQRUW3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Steven D'Aprano]

On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:

> In Python, if you evaluate an undefined name, Python raises a 
> NameError.  This is so consistent I'm willing to call it a "rule".  
> Various folks have proposed an exception to this "rule": evaluating an 
> undefined name in an PEP 649 delayed annotation wouldn't raise 
> NameError, instead evaluating to some yet-to-be-determined value 
> (ForwardRef, AnnotationName, etc).  I don't think annotations are 
> special enough to "break the rules" in this way.

Can we have a code snippet illustrating that? I think this is what you 
mean. Please correct me if I have anything wrong.

If I have this:

from typing import Any
def function(arg:Spam) -> Any: ...

then we have four sets of (actual or proposed) behaviour:

1. The original, current and standard behaviour is that Spam raises a 
NameError at function definition time, just as it would in any other 
context where the name Spam is undefined, e.g. `obj = Spam()`.

2. Under PEP 563 (string annotations), there is no NameError, as the 
annotations stay as strings until you attempt to explicitly resolve them 
using eval. Only then would it raise NameError.

3. Under PEP 649 (descriptor annotations), there is no NameError at 
function definition time, as the code that resolves the name Spam (and 
Any for that matter) is buried in a descriptor. It is only on inspecting 
`function.__annotations__` at runtime that the code in the descriptor is 
run and the name Spam will generate a NameError.

4. Guido would(?) like PEP 649 to be revised so that inspecting the 
annotations at runtime would not generate a NameError. Since Spam is 
unresolvable, some sort of proxy or ForwardRef (or maybe just a 
string?) would have to be returned instead of raising.

Am I close?

My initial thought was to agree with Larry about special cases, but 
perhaps we could borrow part of PEP 563 and return a string if the name 
Spam is unresolvable.

Runtime type checkers already have to deal with forward refs that are 
strings, as this is legal, and always will be:

def function(arg:'Spam') -> Any: ...

so we're not putting any extra burden on them. And we had already 
agreed to implicitly use strings for annotations.

So if I have understood the options correctly, I like the idea of a 
hybrid descriptor + stringy annotations solution.

- defer evaluation of the annotations using descriptors (PEP 649);

- on runtime evaluation, if a name does not resolve, stringify it (as 
PEP 563 would have done implicitly);

- anyone who really wants to force a NameError can eval the string.

More practically, folks will more likely delay evaluating the string 
until Spam has been created/imported and will resolve.



-- 
Steve
___
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/F4BZLEQ36MIIBDRUIMNGWCSSE6AMYM5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Larry Hastings]

On 10/21/21 1:17 AM, Steven D'Aprano wrote:

On Thu, Oct 21, 2021 at 04:48:28PM -0400, Larry Hastings wrote:


In Python, if you evaluate an undefined name, Python raises a
NameError.  This is so consistent I'm willing to call it a "rule".
Various folks have proposed an exception to this "rule": evaluating an
undefined name in an PEP 649 delayed annotation wouldn't raise
NameError, instead evaluating to some yet-to-be-determined value
(ForwardRef, AnnotationName, etc).  I don't think annotations are
special enough to "break the rules" in this way.

Can we have a code snippet illustrating that? I think this is what you
mean. Please correct me if I have anything wrong.

If I have this:

 from typing import Any
 def function(arg:Spam) -> Any: ...

then we have four sets of (actual or proposed) behaviour:

1. The original, current and standard behaviour is that Spam raises a
NameError at function definition time, just as it would in any other
context where the name Spam is undefined, e.g. `obj = Spam()`.

2. Under PEP 563 (string annotations), there is no NameError, as the
annotations stay as strings until you attempt to explicitly resolve them
using eval. Only then would it raise NameError.

3. Under PEP 649 (descriptor annotations), there is no NameError at
function definition time, as the code that resolves the name Spam (and
Any for that matter) is buried in a descriptor. It is only on inspecting
`function.__annotations__` at runtime that the code in the descriptor is
run and the name Spam will generate a NameError.

4. Guido would(?) like PEP 649 to be revised so that inspecting the
annotations at runtime would not generate a NameError. Since Spam is
unresolvable, some sort of proxy or ForwardRef (or maybe just a
string?) would have to be returned instead of raising.

Am I close?



Your description of the four behaviors is basically correct.



So if I have understood the options correctly, I like the idea of a
hybrid descriptor + stringy annotations solution.

- defer evaluation of the annotations using descriptors (PEP 649);

- on runtime evaluation, if a name does not resolve, stringify it (as
PEP 563 would have done implicitly);

- anyone who really wants to force a NameError can eval the string.



You might also be interested in my "Great Compromise" proposal from back 
in April:


   
https://mail.python.org/archives/list/python-dev@python.org/thread/WUZGTGE43T7XV3EUGT6AN2N52OD3U7AE/

Naturally I'd prefer PEP 649 as written.  The "compromise" I described 
would have the same scoping limitations as stringized annotations, one 
area where PEP 649 is a definite improvement.



Cheers,


//arry/

___
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/HEAXKK7U2YNGSV6AFVDG7XNIL34DE5TF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Christopher Barker]

On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano  wrote:

> Runtime type checkers already have to deal with forward refs that are
> strings, as this is legal, and always will be:
>
> def function(arg:'Spam') -> Any: ...
>
> so we're not putting any extra burden on them. And we had already
> agreed to implicitly use strings for annotations.
>

I'll take your word for it. However, other runtime uses for annotations may
not already need to support strings as types.

Pydantic is the classic example. I'm not entirely sure how it does its
thing, but I have code built on dataclasses that is likely similar -- it
expects the annotation to be an actual type object -- an actual class, one
that can be instantiated, not even the types that are in the typing module,
and certainly not a string that needs to be evaluated.

So having them sometimes, maybe sometimes be strings would be a big pain in
the @$$

On the other hand, having them be some odd "ForwardReference" type, rather
than a NameError might be OK -- as long as SOME exception was raised as
soon as I tried to use it. Though it would make for far more confusing
error messages :-(

My first choice would be to get a NameError at module load time, like we do
now. Second would be a NameError as soon as it is accessed. Getting a
special value is OK though, now that I'm thinking about it, I could
probably put that special case code in one place, and provide a nice error
message.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/WAE5LTKPBCEEBPR3ZHRGWJEGIEQ6RI6G/
Code of Conduct: http://python.org/psf/codeofconduct/