[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Steven D'Aprano]

On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote:

> It impairs readability, because it muddles the return type.
> The function in the example returns a bool.
> The annotation is also misleading as the annotation is on the return 
> type, not on the parameter that is narrowed.
> 
> At a glance, most programmers should be able to work out what
> 
> def is_str_list(val: List[object]) -> bool:
> 
> returns.
> 
> But,
> 
> def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
> 
> is likely to confuse and require careful reading.
> Type hints are for humans as well as type checkers.

This!

Without reading the PEP, how is anyone supposed to know that this 
returns a bool? This is obfuscated code. It looks like it returns an 
object of type `TypeGuard`. Even having read the PEP, it's still 
misleading: instead of a straightforward return type, I have to memorise 
that `TypeGuard[...]` is a magic thing that means

* the return type is actually a bool;

* and the type checker can narrow the type of the first parameter.

Yuck.

Consider:

def is_list_of(val: List[object], T: Type) -> bool:
return all(isinstance(x, T) for x in val)

`if is_list_of(items, str)` should narrow the type of items to 
`List[str]`, but I don't think that there is any way to specify that. In 
fact that seems to be explicitly rejected: the decorator syntax is 
rejected because "it requires runtime evaluation of the type, precluding 
forward references".

But type hints have to deal with forward references in other situations, 
and have had an effective mechanism for forward references since the 
beginning:

https://www.python.org/dev/peps/pep-0484/#forward-references

so I think that's a weak argument for rejection. And the argument that 
overriding the return type with a magic special value is "easier to 
understand" seems wrong to me.

I think that Mark's proposal reads well:

> An alternative, and more explicit, approach would be to use variable 
> annotations.
[...]
> def is_str_list(val: List[object]) -> bool:
> """Determines whether all objects in the list are strings"""
> val: NarrowsTo[List[str]]
> return all(isinstance(x, str) for x in val)
> 
> Although the above lacks flow control and is thus ambiguous without the 
> convention that `NarrowsTo` only applies if the result is True.

But we need that convention for the TypeGuard return value annotation 
too. 

def is_str_list(val: List[object]) -> TypeGuard[List[str]]:

only narrows the type of val if the function returns True. So I think 
that Mark's variable annotation has many benefits:

- doesn't mangle the return annotation;

- which is much more readable to the human reader;

- naive software that doesn't care about type narrowing doesn't need to 
  care about the variable annotation;
 
- explicitly tells you which parameter is being narrowed;

- easy to narrow any parameter, or more than one, without requiring
  special treatment of the first positional argument;

- because the parameter is explicit, there is no need for special 
  handling of self or cls.

The only weakness is that we need the convention that the variable 
annotation will only apply if the function returns True, but that's the 
same convention as the TypeGuard.


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

[Python-Dev] Re: Python standardization

[Benjamin Peterson]

On Fri, Feb 12, 2021, at 12:33, Dan Stromberg wrote:
> 
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
> 
> It seems to have really helped C.

That confuses cause and effect. C was standardized because there sprung up 
hundreds of vaguely compatible implementations—a definite mark of success—not 
the other way around.

> 
> It looks like Java isn't standardized, and it's done OK, though perhaps 
> it was healthier in the past - before Oracle decided API's were ownable.

Hmm? https://docs.oracle.com/javase/specs/jls/se15/html/index.html
___
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/YGEHVIHZAS5NM4OTG6NQCWH5NM4CF4EM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Gregory P. Smith]

My primary reaction seems similar to Mark Shannon's.

When I see this code:

def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
...

I cannot tell what it returns.  There is no readable indication in that
this returns a boolean so the reader cannot immediately see how to use the
function.  In fact my first reaction is to assume it returns some form of
List[str].  Which it most definitely does not do.

Additionally, it seems like restricting this concept of a type guard to
only a function that returns a bool is wrong.
It is also a natural idiom to encounter functions that raise an exception
if their type conditions aren't met.
Those should also narrow types within a non-exception caught codepath after
their return.  Be simple and assume that catching any exception from their
call ends their narrowing?

A narrowing is meta-information about a typing side effect, it isn't a type
itself.  It isn't a value.  So replacing a return type with it seems like
too much.  But if we do wind up going that route, at least make the name
indicate that the return value is a bool.  i.e.: def parse_num(thing: Any)
-> NarrowingBool[float]

The term TypeGuard is too theoretical for anyone reading code.  I don't
care if TypeScript uses it in their language... looking that up at a quick
glance -
https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards
- it doesn't look like they ever use the term TypeGuard in the language
syntax itself? good.

Perhaps this would be better expressed as an annotation on the argument(s)
that the function narrows?

def is_str_list(val: Constrains[List[object]:List[str]) -> bool:
...

I'm using Constrains as an alternative to Narrows here... still open to
suggestions.  But I do not think we should get hung up on TypeScript and
assume that TypeGuard is somehow a good name.  This particular proposed
example uses : slice notation rather than a comma as a proposal that may be
more readable.  I'd also consider using the 'as' keyword instead of , or :
but that wouldn't even parse today.  *Really* what might be nice for this
is our -> arrow.

def assert_str_list(var:  Narrows[List[object] -> List[str]]) -> None:
...

as the arrow carries the implication of something effective "after" the
call. I suspect adding new parsing syntax isn't what anyone had in mind for
now though.  : seems like a viable stopgap, whether syntax happens or not.
(i'm intentionally avoiding the comma as an exploration in readability)

The key point I'm trying to represent is that declaring it per argument
allows for more expressive functions and doesn't interfere with their
return value (if they even return anything). Clearly there's a use case
that _does_ want to make the narrowing conditional on the return value
boolness.  I still suggest expressing that on the arguments themselves.
More specific flavors of the guarding parameter such as ConstrainsWhenTrue
or NarrowsWhenFalse perhaps.


def is_set_of(val: Constrains[Set[Any]:Set[_T]], type: Type[_T]) -> bool:
   ...

which might also be written more concisely as:

def is_set_of(val: Set[Constrains[Any:_T]], type: Type[_T]) -> bool:

If we allow the full concept.

hopefully food for thought,  i'm -1 right now.
-gps


On Fri, Feb 12, 2021 at 2:34 AM Mark Shannon  wrote:

> Hi,
>
> First of all, sorry for not commenting on this earlier.
> I only became aware of this PEP yesterday.
>
>
> I like the general idea of adding a marker to show that a boolean
> function narrows the type of one (or more?) of its arguments.
> However, the suggested approach seems clunky and impairs readability.
>
> It impairs readability, because it muddles the return type.
> The function in the example returns a bool.
> The annotation is also misleading as the annotation is on the return
> type, not on the parameter that is narrowed.
>
> At a glance, most programmers should be able to work out what
>
> def is_str_list(val: List[object]) -> bool:
>
> returns.
>
> But,
>
> def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
>
> is likely to confuse and require careful reading.
> Type hints are for humans as well as type checkers.
>
>
>
> Technical review.
> -
>
> For an annotation of this kind to be useful to a checker, that checker
> must perform both flow-sensitive and call-graph analysis. Therefore it
> is theoretically possible to remove the annotation altogether, using the
> following approach:
>
> 1. Scan the code looking for functions that return boolean and
> potentially narrow the type of their arguments.
> 2. Inline those functions in the analysis
> 3. Rely on pre-existing flow-senstive analysis to determine the correct
> types.
>
> However, explicit is better and implicit. So some sort of annotation
> seems sensible.
>
> I would contend that the minimal:
>
> @narrows
> def is_str_list(val: List[object]) -> bool:
>
> is sufficient for a checker, as the checker can inline anything marked
> @narrows.
> Plus, it does not mislead th

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Jim J. Jewett]

In the documentation (not sure whether it should be the documentation
for "open" or for encoding), include at least a link to instructions
on how to (try to) verify that your codebase is using the encoding
parameter properly.  Those instructions would say something like "Add
the following lines to end of Lib\site.py:
_origopen=open
def open(...):
if ...
warnings.warn(...)
_origopen(...)
"

-jJ

On Fri, Feb 12, 2021 at 6:28 PM Inada Naoki  wrote:
>
> On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett  wrote:
> >
> > Offering encoding="locale" (or open.locale or ... ) instead of a long 
> > function call using False (locale.getpreferredencoding(False)) seems like a 
> > win for Explicit is Better Than Implicit.  It would then be possible to say 
> > "yeah, locale really is what I meant".
> >
> > Err... unless the charset determination is so tricky that it ends up just 
> > adding another not-quite-right near-but-not-exact-synonym.
> >
> > Adding a new Warning subclass, and maybe a new warning type, and maybe a 
> > new environment variable, and maybe a new launch flag ... these all seem to 
> > risk just making things more complicated without sufficient gain.
> >
> > Would a recipe for site-packages be sufficient, or does this need to run 
> > too early in the bootstrapping process?
> >
> > -jJ
>
> What does "a recipe for site-packages" mean?
>
> --
> Inada Naoki  
___
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/MSK5HN4IGUMBRF4PM7IZYMI7OJGD4KJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

But this message seems to say "Argue with me!"
___
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/SST7KKKTJAEHU73TMWS7GIIR3GNELZA6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Emily Bowman]

A call for standardization is typically done when multiple competing
de-facto standards competing for space, especially if it's relatively
immature, as a way to bring stakeholders together and reduce fragmentation.
You don't just go through the standards process for its own sake, unless
it's a requirement for some specific kind of government contract or
whatever. C and C++ ended up standardized because they blew up and were
implemented in dozens of often-incompatible ways. Python's had a much more
constrained development process, for better or worse, in which there's
traditionally been very little divergence regarding important language
functionality or standard library support in alternate implementations.
Because the language, not just CPython, is allowed to evolve in every minor
version, as well, standardization would just hamstring that.

There's no reason it couldn't be done if the interest was there, but
there's just no really powerful impetus to actually do it. Python the
language isn't splintering. (2 vs 3 is long past us all, and it's not like
2 evolved in implementations that didn't pick up 3.)

-Em

On Fri, Feb 12, 2021 at 10:35 AM Dan Stromberg  wrote:

>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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/MVDATOACGGA2HNHLSVG4BBD7T4IBDKOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Guido van Rossum]

>From talking to people who at various times have participated in a language
standardization process, I've learned that it's not a panacea, it's an
enormous amount of work, it doesn't guarantee a good outcome, and plenty of
languages do just fine without it. Also, it costs real money. A lot. I have
no interest in going that route, and I don't think any other core devs are
interested either.

Dan: If you have a beef with something in the way change to Python is
managed, please say what's bothering you. There's likely more reason to the
madness than you think. Requesting that our volunteer-driven organization
switches to an expensive new process seems rather premature, don't you
think?

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

[Python-Dev] Re: Python standardization

[Chris Angelico]

On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg  wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico  wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  wrote:
>> > I believe Python needs to become more independent of CPython, for Python's 
>> > long term health.
>> >
>>
>> Since 1997, Python has been defined independently of CPython.
>
> Really?  It sounds like I missed something important then.  More 
> specifically, what changed in 1997?

Jython launched. I may have the year wrong, but it was about then, and
that's what Wikipedia says. The significance may have happened +/- a
year of that, I'm not sure, but the point is that that's when effort
started to be made to separate CPython from Python - allowing Jython
to know the language semantics.

>> There
>> are numerous documents that define the language semantics for the
>> benefit of other implementations.
>
> References please?  I'd love to find out this has already been done.

Mostly, the reference documentation. Anything that says how to use
something is also the definition of how to implement it.

>> Multiple implementations have
>> somehow managed to exist without any sort of ISO standard.
>
> Yes, the existence of a small number of other implementations (modulo web 
> implementations) is why I say Python has done pretty well despite the 
> existence of a reference implementation,
>
>> Can you explain what would be improved by having a formalized
>> standard?
>
> It's mostly about avoiding creeping featurism and painting other 
> implementations into corners.  Or - and this is equally important - leaving 
> other implementations in the dust.
>

Other implementations can still be left in the dust even if there's a
standard - just look at various other languages, standards and all,
and the difficulties of using standardized features across compilers.
(I'm not naming names, here, but cross-platform C code is harder than
it needs to be.)

> Consider how far back Jython and IronPython are.  If the "bureaucracy" (I see 
> it as measured progress) of a standard would allow them to catch up, without 
> having to study the CPython source code, the standard will have done its job.
>

Is studying the CPython source code what's keeping them back? Do you
have any evidence to support that?

> In all candor, I do not think that frequent releases with significant new 
> features in each are good for a language. I'll remind you that the complexity 
> of a language varies with the square of its feature count.
>
> There's probably been a rush to add features in the wake of the 2.x-to-3.x 
> transition, but hopefully we won't be continuing at that pace.
>

I, on the other hand, am very happy to have new features in the
language. Each year, Python grows better. If you don't like that,
you're welcome to continue to use Python 3.5 and define that as your
standard; I believe that, for instance, MicroPython has chosen a fixed
standard to aim for.

> And again: a good language has a small core but is extensible, enabling 
> extensive /libraries/.  Python is indeed nicely extensible.
>

Sure, and I've worked with languages that aren't easily extensible.
But there are language features too. Hamstringing the language is not
helping anyone.

>> So far this thread has just been vague ideas that a
>> bureaucratic procedure will somehow help things, without showing a
>> problem.
>
> I've outlined some, but you seem more than ready to dismiss them.

You've shown what MIGHT be a problem, but you haven't actually shown
any real problems.

> The things that got me thinking about this were:
> 1) The caution my comparative languages professor in school delivered about 
> reference implementations and how bad they can be for a language's maturation.
> 2) A comment on python-list about languages without standards not being grown 
> up, that I really couldn't disagree with.
> 3) The common confusion between "Python" and "CPython".  Many people still 
> think they're the same thing.

Please elaborate on the first two. The third one won't change even
with a standard. If reference implementations are bad, why do so many
things - not just languages - have them? There are reference
implementations for crypto algorithms, for example. Do they hurt those
algorithms?

The comment on python-list is, just like your post, lacking in
substantiation. In fact, I would call it nothing but FUD.

> Of course, Java is grown up and it has no formal standard.  But there's 
> always Perl's scary example lurking in the background.  And even Java really 
> doesn't appear to have that many competing implementations.  I'm aware of the 
> IBM JDK, OpenJDK, and gcj.  But for all Java's success, there probably should 
> be (have been) more.
>
> And having a comprehensive test suite can help a lot too - it sounds like 
> we're pretty close there?  ISTR hearing that Pypy was able to reuse much of 
> CPython's test suite.  Having a generic test suite that isn't tied to a 
> specific implementation would b

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico  wrote:

> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  wrote:
> > I believe Python needs to become more independent of CPython, for
> Python's long term health.
> >
>
> Since 1997, Python has been defined independently of CPython.

Really?  It sounds like I missed something important then.  More
specifically, what changed in 1997?

There
> are numerous documents that define the language semantics for the
> benefit of other implementations.

References please?  I'd love to find out this has already been done.

Multiple implementations have
> somehow managed to exist without any sort of ISO standard.
>
Yes, the existence of a small number of other implementations (modulo web
implementations) is why I say Python has done pretty well despite the
existence of a reference implementation,

Can you explain what would be improved by having a formalized
> standard?

It's mostly about avoiding creeping featurism and painting other
implementations into corners.  Or - and this is equally important - leaving
other implementations in the dust.

Consider how far back Jython and IronPython are.  If the "bureaucracy" (I
see it as measured progress) of a standard would allow them to catch up,
without having to study the CPython source code, the standard will have
done its job.

In all candor, I do not think that frequent releases with significant new
features in each are good for a language. I'll remind you that the
complexity of a language varies with the square of its feature count.

There's probably been a rush to add features in the wake of the 2.x-to-3.x
transition, but hopefully we won't be continuing at that pace.

And again: a good language has a small core but is extensible, enabling
extensive /libraries/.  Python is indeed nicely extensible.

So far this thread has just been vague ideas that a
> bureaucratic procedure will somehow help things, without showing a
> problem.
>
I've outlined some, but you seem more than ready to dismiss them.

The things that got me thinking about this were:
1) The caution my comparative languages professor in school delivered about
reference implementations and how bad they can be for a language's
maturation.
2) A comment on python-list about languages without standards not being
grown up, that I really couldn't disagree with.
3) The common confusion between "Python" and "CPython".  Many people still
think they're the same thing.

Of course, Java is grown up and it has no formal standard.  But there's
always Perl's scary example lurking in the background.  And even Java
really doesn't appear to have that many competing implementations.  I'm
aware of the IBM JDK, OpenJDK, and gcj.  But for all Java's success, there
probably should be (have been) more.

And having a comprehensive test suite can help a lot too - it sounds like
we're pretty close there?  ISTR hearing that Pypy was able to reuse much of
CPython's test suite.  Having a generic test suite that isn't tied to a
specific implementation would be fantastic.  One could argue this is what
has given rise to the alternative implementations of Python we have.
Unless you count the ones that run in a web browser - there were at least
32 at my last count, with frequently-superficial compatibility.

But we really should encourage more compatible implementations.  That's
what I'm trying to get at.  That's probably the main "problem" you seem to
want me to highlight, even though I'd rather not be very critical.
___
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/COZK5QPWEAAVOAAILD7GKIYMJMORX6NG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Inada Naoki]

On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett  wrote:
>
> Offering encoding="locale" (or open.locale or ... ) instead of a long 
> function call using False (locale.getpreferredencoding(False)) seems like a 
> win for Explicit is Better Than Implicit.  It would then be possible to say 
> "yeah, locale really is what I meant".
>
> Err... unless the charset determination is so tricky that it ends up just 
> adding another not-quite-right near-but-not-exact-synonym.
>
> Adding a new Warning subclass, and maybe a new warning type, and maybe a new 
> environment variable, and maybe a new launch flag ... these all seem to risk 
> just making things more complicated without sufficient gain.
>
> Would a recipe for site-packages be sufficient, or does this need to run too 
> early in the bootstrapping process?
>
> -jJ

What does "a recipe for site-packages" mean?

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

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 2:01 PM Greg Ewing 
wrote:

> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
>
> We have the Language Reference and Library Reference. Do they
> not count as specifications?
>
It's been a long time since I looked at these, but aren't they more
targeted at people developing in Python than people developing a Python
implementation?  The two have some overlap of course, but they aren't
really the same thing.
___
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/QXIAEFI2T7H32QIY6QNCZZVFULMSX7GL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Paul Bryan]

I definitely think they could. As a developer using Python, they're
fully sufficient for my purposes.

I honestly don't know enough about non-CPython implementations and
their challenges to know what gaps (if any) would need to be filled to
fully implement a compatible version.


On Sat, 2021-02-13 at 10:58 +1300, Greg Ewing wrote:
> On 13/02/21 9:03 am, Paul Bryan wrote:
> > What if PSF were to undertake codifying a language specification?
> 
> We have the Language Reference and Library Reference. Do they
> not count as specifications?
> 

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

[Python-Dev] Re: Python standardization

[Chris Angelico]

On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg  wrote:
> I believe Python needs to become more independent of CPython, for Python's 
> long term health.
>

Since 1997, Python has been defined independently of CPython. There
are numerous documents that define the language semantics for the
benefit of other implementations. Multiple implementations have
somehow managed to exist without any sort of ISO standard.

Can you explain what would be improved by having a formalized
standard? So far this thread has just been vague ideas that a
bureaucratic procedure will somehow help things, without showing a
problem.

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

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Guido van Rossum]

On Fri, Feb 12, 2021 at 12:14 PM Jim J. Jewett  wrote:

> Current PEP 647 draft says:
>
> "Some built-in type guards provide narrowing for both positive and
> negative tests (in both the if and else clauses)"
>
> Should there be a separate (sub-?) type for those TypeGuards that *do*
> allow narrowing even on a False?  Leaving it as an implementation detail
> available only to (some) built-in types seems to confuse the issue in both
> directions.
>

I think the PEP is using the term in a wider sense here, referring to
things like `isinstance(x, C)` and `x is not None`. Note that mypy (at
least) also recognizes `if x:` as narrowing `Optional[T]` to `T`, but there
in the else clause we *cannot* assume that x is not a T, because it could
be a falsey instance.

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

[Python-Dev] Re: Python standardization

[Greg Ewing]

On 13/02/21 9:03 am, Paul Bryan wrote:

What if PSF were to undertake codifying a language specification?


We have the Language Reference and Library Reference. Do they
not count as specifications?

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

[Python-Dev] Re: Python standardization

[Dan Stromberg]

That could be good.  :)  And sometimes standards are rubber stamped by
other bodies.

On Fri, Feb 12, 2021 at 12:03 PM Paul Bryan  wrote:

> What if PSF were to undertake codifying a language specification?
>
> On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
>
>
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
> How a standard by ANSI, ECMA and/or ISO is any better than a standard by
> the PSF?
>
> I don't think what the PSF is producing is truly a standard.
>
> Is PSF bad at "controlling its growth and avoiding featuritis" in your
> opinion or smth?
>
> It's not the PSF I have an issue with. It's having a reference
> implementation.
>
> I think the PSF has done a pretty good job of keeping in mind what other
> Python implementations can realistically do also - but doing so is an
> uphill battle.
>
> I believe Python needs to become more independent of CPython, for Python's
> long term health.
>
> Think of C.  Where would it be if it had K&R C as a reference
> implementation, long term?  There are dozens, maybe hundreds of
> mostly-compatible implementations of C.  I think this should be Python's
> goal.
>
> Look where not having a standard got Perl.  It is so defined by a single
> implementation that the language is collapsing under its own weight.  Perl
> 6 is so not-perl that it was renamed.  Python is much less guilty of
> exuberant design, that's part of what I like about Python, but like I said,
> having a reference implementation instead of a standard makes that more
> difficult.
>
> On 12.02.2021 21:33, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> 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/36ZVB2LUBRZOLXT4EJ2YCVUYSJ6L4HPB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Jim J. Jewett]

Current PEP 647 draft says: 

"Some built-in type guards provide narrowing for both positive and negative 
tests (in both the if and else clauses)"

Should there be a separate (sub-?) type for those TypeGuards that *do* allow 
narrowing even on a False?  Leaving it as an implementation detail available 
only to (some) built-in types seems to confuse the issue in both directions.

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

[Python-Dev] Re: Python standardization

[Paul Bryan]

What if PSF were to undertake codifying a language specification?

On Fri, 2021-02-12 at 11:57 -0800, Dan Stromberg wrote:
> 
> On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev
>  wrote:
> > How a standard by ANSI, ECMA and/or ISO is any better than a
> > standard by the PSF?
> > 
> 
> I don't think what the PSF is producing is truly a standard.
> > Is PSF bad at "controlling its growth and avoiding featuritis" in
> > your opinion or smth?
> > 
> 
> It's not the PSF I have an issue with. It's having a reference
> implementation.
> 
> I think the PSF has done a pretty good job of keeping in mind what
> other Python implementations can realistically do also - but doing so
> is an uphill battle.
> 
> I believe Python needs to become more independent of CPython, for
> Python's long term health.
> 
> Think of C.  Where would it be if it had K&R C as a reference
> implementation, long term?  There are dozens, maybe hundreds of
> mostly-compatible implementations of C.  I think this should be
> Python's goal.
> 
> Look where not having a standard got Perl.  It is so defined by a
> single implementation that the language is collapsing under its own
> weight.  Perl 6 is so not-perl that it was renamed.  Python is much
> less guilty of exuberant design, that's part of what I like about
> Python, but like I said, having a reference implementation instead of
> a standard makes that more difficult.
> > On 12.02.2021 21:33, Dan Stromberg wrote:
> > 
> > > 
> > > What would it take to create an ANSI, ECMA and/or ISO standard
> > > for Python?
> > > 
> > > It seems to have really helped C.
> > > 
> > > It looks like Java isn't standardized, and it's done OK, though
> > > perhaps it was healthier in the past - before Oracle decided
> > > API's were ownable.
> > > 
> > > I think standardizing Python might be really good for controlling
> > > its growth and avoiding featuritis.
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> > > 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-d
> > e...@python.org/message/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
> > 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/64TBHFOMEK7ECWSTHA6PMF7RGUH7S6TQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 11:02 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> How a standard by ANSI, ECMA and/or ISO is any better than a standard by
> the PSF?
>
I don't think what the PSF is producing is truly a standard.

> Is PSF bad at "controlling its growth and avoiding featuritis" in your
> opinion or smth?
>
It's not the PSF I have an issue with. It's having a reference
implementation.

I think the PSF has done a pretty good job of keeping in mind what other
Python implementations can realistically do also - but doing so is an
uphill battle.

I believe Python needs to become more independent of CPython, for Python's
long term health.

Think of C.  Where would it be if it had K&R C as a reference
implementation, long term?  There are dozens, maybe hundreds of
mostly-compatible implementations of C.  I think this should be Python's
goal.

Look where not having a standard got Perl.  It is so defined by a single
implementation that the language is collapsing under its own weight.  Perl
6 is so not-perl that it was renamed.  Python is much less guilty of
exuberant design, that's part of what I like about Python, but like I said,
having a reference implementation instead of a standard makes that more
difficult.

> On 12.02.2021 21:33, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> Regards,
> Ivan
>
> ___
> 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/ZBKXMHWFEIWGP7FZJDZPNPV7TEXANMIV/
> 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/7WXKZFTLABA7L63LRWVVCLCEHZ5NDGRO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Jim J. Jewett]

Offering encoding="locale" (or open.locale or ... ) instead of a long function 
call using False (locale.getpreferredencoding(False)) seems like a win for 
Explicit is Better Than Implicit.  It would then be possible to say "yeah, 
locale really is what I meant".  

Err... unless the charset determination is so tricky that it ends up just 
adding another not-quite-right near-but-not-exact-synonym.

Adding a new Warning subclass, and maybe a new warning type, and maybe a new 
environment variable, and maybe a new launch flag ... these all seem to risk 
just making things more complicated without sufficient gain.

Would a recipe for site-packages be sufficient, or does this need to run too 
early in the bootstrapping process?

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

[Python-Dev] Re: Python standardization

[Dan Stromberg]

On Fri, Feb 12, 2021 at 10:51 AM Paul Bryan  wrote:

> From my point of view, the process of standardizing through a formal
> standards body is a tedious, verbose, laborious, bureaucratic and
> often contentious process.
>
I've never participated in such a standardization, but I'm sure it's hard
work.

I'd really like to know quantitatively what the benefits would be of
> running that gauntlet, as I'm not sure they would outweigh the costs.
>
I think it'd be easier to quantify love.

On Fri, 2021-02-12 at 10:33 -0800, Dan Stromberg wrote:
>
>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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/NC5RVQ55OENLR3AFB6SDXL5AMHHHA2MD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Ivan Pozdeev via Python-Dev]

How a standard by ANSI, ECMA and/or ISO is any better than a standard by the 
PSF?

Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion 
or smth?

On 12.02.2021 21:33, Dan Stromberg wrote:


What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it was healthier in the past - before Oracle decided API's were 
ownable.


I think standardizing Python might be really good for controlling its growth 
and avoiding featuritis.



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


--
Regards,
Ivan

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

[Python-Dev] Re: Python standardization

[Paul Bryan]

>From my point of view, the process of standardizing through a formal
standards body is a tedious, verbose, laborious, bureaucratic and
often contentious process.

I'd really like to know quantitatively what the benefits would be of
running that gauntlet, as I'm not sure they would outweigh the costs.

On Fri, 2021-02-12 at 10:33 -0800, Dan Stromberg wrote:
> 
> What would it take to create an ANSI, ECMA and/or ISO standard for
> Python?
> 
> It seems to have really helped C.
> 
> It looks like Java isn't standardized, and it's done OK, though
> perhaps it was healthier in the past - before Oracle decided API's
> were ownable.
> 
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
> 
> ___
> 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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> 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/7PM4C6EW633HF4URYN4JTKS7KTAJEPME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python standardization

[Dan Stromberg]

What would it take to create an ANSI, ECMA and/or ISO standard for Python?

It seems to have really helped C.

It looks like Java isn't standardized, and it's done OK, though perhaps it
was healthier in the past - before Oracle decided API's were ownable.

I think standardizing Python might be really good for controlling its
growth and avoiding featuritis.
___
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/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-02-05 - 2021-02-12)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7415 (+36)
  closed 47529 (+34)
  total  54944 (+70)

Open issues with patches: 2944 


Issues opened (51)
==

#41754: Webbrowser Module Cannot Find xdg-settings on OSX
https://bugs.python.org/issue41754  reopened by serhiy.storchaka

#43139: test_ttk test_compound and test_tk test_type fails with Tk 8.6
https://bugs.python.org/issue43139  opened by felixonmars

#43140: built-in open() doesn't use locale.getpreferredencoding() as t
https://bugs.python.org/issue43140  opened by smallbigcake

#43141: `asdict` fails with frozen dataclass keys; tries to use raw di
https://bugs.python.org/issue43141  opened by enaumov

#43142: Do not add duplicate FDs to list in duplicate_for_child()
https://bugs.python.org/issue43142  opened by sanchit

#43143: Allow multiple assignment (i.e. tuple on LHS) in walrus operat
https://bugs.python.org/issue43143  opened by pfalcon

#43144: test_unicodedata: test_normalization uses network but doesn't 
https://bugs.python.org/issue43144  opened by arekm

#43145: Leak of locks from multiprocessing.Process
https://bugs.python.org/issue43145  opened by bstaletic

#43146: 3.10a5 regression: AttributeError: 'NoneType' object has no at
https://bugs.python.org/issue43146  opened by The Compiler

#43148: Call sys.unraisablehook in the REPL when sys.excepthook is bro
https://bugs.python.org/issue43148  opened by Julian

#43152: warning: unused variable 'code'
https://bugs.python.org/issue43152  opened by corona10

#43153: tempfile seems to treat a file as a directory when processing 
https://bugs.python.org/issue43153  opened by mehwhatever0

#43154: code.InteractiveConsole can crash if sys.excepthook is broken
https://bugs.python.org/issue43154  opened by Carl.Friedrich.Bolz

#43155: PyCMethod_New not defined in python3.lib
https://bugs.python.org/issue43155  opened by barry-scott

#43156: Python windows installer has a confusing name - add setup to i
https://bugs.python.org/issue43156  opened by barry-scott

#43158: uuid won't build when libuuid is installed in a non-standard p
https://bugs.python.org/issue43158  opened by larry

#43159: pathlib with_suffix() should accept suffix not start with dot
https://bugs.python.org/issue43159  opened by elbarkwon

#43160: argparse: add extend_const action
https://bugs.python.org/issue43160  opened by roganartu

#43162: Enum regression: AttributeError when accessing class variables
https://bugs.python.org/issue43162  opened by hroncok

#43164: test_nntplib.NetworkedNNTP_SSLTests fails on "AMD64 RHEL8 FIPS
https://bugs.python.org/issue43164  opened by cstratak

#43165: Support the same files with new param in shutil.copyfile
https://bugs.python.org/issue43165  opened by milanbalazs

#43167: Add a note to the macOS installer welcome window about customi
https://bugs.python.org/issue43167  opened by barry-scott

#43168: macOS python install shares /usr/local with homebrew and can c
https://bugs.python.org/issue43168  opened by barry-scott

#43169: argparse: support options similar to find's -exec
https://bugs.python.org/issue43169  opened by pkkm

#43172: Fix test_readline when compiled using --with-readline=edit
https://bugs.python.org/issue43172  opened by gregory.p.smith

#43175: filecmp is not working for UTF-8 BOM file.
https://bugs.python.org/issue43175  opened by suresh

#43176: Dataclasses derived from empty frozen bases skip immutability 
https://bugs.python.org/issue43176  opened by hbq1

#43177: How to use `long double` as a PyObject?
https://bugs.python.org/issue43177  opened by ganesh3597

#43179: Remove s390 support
https://bugs.python.org/issue43179  opened by christian.heimes

#43181: Python macros don’t shield arguments
https://bugs.python.org/issue43181  opened by numberZero

#43182: TURTLE: Default values for basic Turtle commands
https://bugs.python.org/issue43182  opened by Bruce1979

#43184: Missing docs for LoggerAdapter manager and name property
https://bugs.python.org/issue43184  opened by yoavp10

#43185:  AssertRaises() causes core dump in handling recursi
https://bugs.python.org/issue43185  opened by CharlesFengY

#43186: Recursive call causes core dump in assertRaises
https://bugs.python.org/issue43186  opened by CharlesFengY

#43187: Dict creation in recursive function cause interpreter crashes.
https://bugs.python.org/issue43187  opened by CharlesFengY

#43188:  multiple operations of dict causes core dump of Python 
https://bugs.python.org/issue43188  opened by CharlesFengY

#43189:  decorator function run_with_locale() crashes Py
https://bugs.python.org/issue43189  opened by CharlesFengY

#43190: < test.support > check_free_after_iterating( ) causes core dum
https://bugs.python.org/issue43190  opened by CharlesFengY

#43191: Shared Memory for array of object
https://bugs.pytho

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Mark Shannon]

Hi,

First of all, sorry for not commenting on this earlier.
I only became aware of this PEP yesterday.


I like the general idea of adding a marker to show that a boolean 
function narrows the type of one (or more?) of its arguments.

However, the suggested approach seems clunky and impairs readability.

It impairs readability, because it muddles the return type.
The function in the example returns a bool.
The annotation is also misleading as the annotation is on the return 
type, not on the parameter that is narrowed.


At a glance, most programmers should be able to work out what

def is_str_list(val: List[object]) -> bool:

returns.

But,

def is_str_list(val: List[object]) -> TypeGuard[List[str]]:

is likely to confuse and require careful reading.
Type hints are for humans as well as type checkers.



Technical review.
-

For an annotation of this kind to be useful to a checker, that checker 
must perform both flow-sensitive and call-graph analysis. Therefore it 
is theoretically possible to remove the annotation altogether, using the 
following approach:


1. Scan the code looking for functions that return boolean and 
potentially narrow the type of their arguments.

2. Inline those functions in the analysis
3. Rely on pre-existing flow-senstive analysis to determine the correct 
types.


However, explicit is better and implicit. So some sort of annotation 
seems sensible.


I would contend that the minimal:

@narrows
def is_str_list(val: List[object]) -> bool:

is sufficient for a checker, as the checker can inline anything marked 
@narrows.

Plus, it does not mislead the reader by mangling the return type.


An alternative, and more explicit, approach would be to use variable 
annotations.

So:

def is_str_list(val: List[object]) -> bool:
"""Determines whether all objects in the list are strings"""
return all(isinstance(x, str) for x in val)

might become:


def is_str_list(val: List[object]) -> bool:
"""Determines whether all objects in the list are strings"""
val: NarrowsTo[List[str]]
return all(isinstance(x, str) for x in val)

Although the above lacks flow control and is thus ambiguous without the 
convention that `NarrowsTo` only applies if the result is True.



An alternative formulation would require the annotation to dominate the 
function exit:


def is_str_list(val: List[object]) -> bool:
"""Determines whether all objects in the list are strings"""
if all(isinstance(x, str) for x in val):
val: NarrowsTo[List[str]]
return True
return False

This is unambiguous.


Finally, I would ask for a change of name.

The "Type" part is redundant, since it is a type annotation, and the 
"Guard" part is incorrect. It is only a guard when used, the function 
itself is a predicate that narrows the type of an argument. "Narrows" or 
"NarrowsTo" would be better.



Cheers,
Mark.


On 09/02/2021 4:21 pm, Guido van Rossum wrote:
I think we have reached consensus on PEP 647 in typing-sig. We have 
implementations for mypy and pyright, not sure about the rest. This PEP 
does not affect CPython directly except for the addition of one special 
item (TypeGuard) to typing.py -- it would be nice to get that in the 
3.10 stdlib.


I'm CC'ing python-dev here to see if there are any further comments; if 
not, we can initiate the approval process by creating an issue at 
https://github.com/python/steering-council.


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

[Python-Dev] Re: Security releases of CPython

[Gregory P. Smith]

On Thu, Feb 11, 2021 at 8:29 PM Terry Reedy  wrote:

> On 2/11/2021 3:23 PM, Michał Górny wrote:
> > Hello,
> >
> > I'm the primary maintainer of CPython packages in Gentoo. I would like
> > to discuss possible improvement to the release process in order to
> > accelerate releasing security fixes to users.
> >
> > I feel that vulnerability fixes do not make it to end users fast enough.
>
> When we introduce a bad regression in a release, including a
> severe-enough security vulnerability, and discover it soon enough, we
> have sometimes made immediately releases.
>

Indeed. What Terry said. There is risk in doing that. It means the solution
is more rushed and hasn't been vetted nearly as well. So without a
compelling severe reason we're unlikely to.

I would expect distros shipping their own python runtime packages to track
security issues and their fixes and backport those (generally easy) to
their own packages before an official release is ready anyways. The big
distros definitely do this. How to deal with this is up to the individual
policies of any given OS distro's package owners.

-gps

Beyond that, your proposal to add several releases per Python version,
> perhaps double what we do now, runs up against the limits of volunteer
> time and effort.  As it is now, becoming a release manager is a 7 year
> commitment, with at least one release about every other month for the
> first 4.  There are also the 2 people who produce the Windows and macOS
> installers.  I believe each has done it for at least 7 or 8 years
> already.  Releases are not just a push of a button.  Make the release
> job too onerous, and there might not be any more volunteers.
>
> > For example, according to the current release schedules for 3.9 and 3.8,
> > the bugfix releases are planned two months apart. While the release is
> > expected to happen in the next few days, both versions are known to be
> > vulnerable for almost a month!
> >
> > Ironically, things look even worse for security-supported versions.
> > Please correct me if I'm wrong but both 3.7 and 3.6 seem to be behind
> > schedule (planned for Jan 15th), and they are known to be vulnerable
> > since mid-October.
> >
> > In my opinion, this causes three issues:
> >
> > 1. Users using official releases are exposed to security vulnerabilities
> > for prolonged periods of time.
> >
> > 2. When releases happen, security fixes are often combined with many
> > other changes. This causes problems for distribution maintainers who, on
> > one hand, would like to deploy the security fixes to production versions
> > ASAP, and on the other, would prefer that the new version remained in
> > testing for some time due to the other changes.
> >
> > 3. Effectively, it means that distribution developers need to track
> > and backport security fixes themselves. In the end, this means a lot of
> > duplicate work.
>
> Perhaps people doing duplicate work could get together to eliminate some of
> the duplication.  It should be possible to filter security commits from the
> python-checkins list by looking at the news entries and if need be, the bpo
> issues.
>
> > I think that security fixes are important enough to justify not sticking
> > to a strict release schedule. Therefore, I would like to propose that if
> > vulnerability fixes are committed, new releases are made
> > as frequently as necessary and as soon as possible (i.e. possibly giving
> > some time for testing) rather than according to a strict schedule.
> >
> > Furthermore, I think that at least for branches that are in higher level
> > of maintenance than security, it could make sense to actually make
> > security releases (e.g. 3.9.1.x) that would include only security fixes
> > without other changes.
>
> --
> Terry Jan Reedy
>
> ___
> 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/4S5LOTVJZUA5PQ5TRGQFCWHTGA4BOXBO/
> 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/Y6KYIFEMECIMWM7BYYSCJ7AMW2FVNUWK/
Code of Conduct: http://python.org/psf/codeofconduct/