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

2021-02-13 Thread Paul Sokolovsky 
Hello,

On Sat, 13 Feb 2021 18:08:30 +1100
Steven D'Aprano  wrote:

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

My quick reading of PEP647 shows that it's yet another
patchy/throw-away PEP whose purpose is to work around deficiencies in
the current generation of Python typecheckers. In that regard, I'd take
it easy, and be +1 with it - it's better to support gradual evolution
of Python typecheckers with hacks like that, rather than block it
with proverbial "we can solve all the problems of universe right in
the version 1".


[]


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/OEQUWN3LZOQ5ZTFSKHL343ZQCUTBURIV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-02-13 Thread Paul Moore 
On Sat, 13 Feb 2021 at 07:11, Steven D'Aprano  wrote:
>
> 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?

I have to agree here. I'm not a frequent user of type hints yet, but I
am starting to have to maintain code that has type hints, and from a
maintenance perspective, I have to say that this would be really hard
to deal with. If I saw this for the first time "in the wild", I'd have
no idea what to do with it.

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/43A7TU2VYDIGFP3THLDFFUWJGWSZSIEM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Antoine Pitrou 
On Fri, 12 Feb 2021 21:54:44 +0300
Ivan Pozdeev via Python-Dev  wrote:
> How a standard by ANSI, ECMA and/or ISO is any better than a standard by the 
> PSF?

The PSF has nothing to do with it.  The Python language is controlled
by the core development team.  I wouldn't be surprised if some members
of that team aren't even members of the PSF, and most of them don't
have any responsability at the PSF.

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

Well, it doesn't have any control in any case.  Which isn't necessarily
a bad thing, depending on your view of the PSF.

Whether or not Python is having a case of featuritis obviously depends
on who you ask the question :-)  I personally would answer yes (at
least since PEP 572, and definitely with the pattern matching PEPs),
while others would certainly answer no.

In the end, note that featuritis is not a lethal disease.  C++ is doing
fine. Python won't die because it has pattern matching (it won't be
flourish because of it, either).

Regards

Antoine.

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

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stephen J. Turnbull 
Chris Angelico writes:

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

The Language Reference together with the Library Reference *already*
constitute a formalized standard.  They are at least as precise as
most W3C or IETF standards.

What you and Dan seem to be referring to is a standard sanctioned by a
major, preferably international, umbrella standards organization.  But
in fact a standard is just a sufficiently precise specification that
allows multiple independent implementations to achieve the same
results, and is accepted by more than one implementer.

 > So far this thread has just been vague ideas that a bureaucratic
 > procedure will somehow help things, without showing a problem.

Python *has* a bureaucratic procedure, it's called "the PEP process".
It's true that the standard library accretes a lot of small changes
without PEPs, but usually any conformant implementation can compile
(or whatever) them without change because they're implemented in
(*gasp*!) Standard Python of the same version.  And they must be
documented (ie, made part of the Reference), or the merge request will
not be accepted.  We now even have a full-on bureacracy (the Steering
Council, sorry folks, but that's what you are).

The main difference between the Python PEP process and the
standardization processes of international bodies such as ECMA, ISO,
W3C, and IETF is the Code of Conduct leading to much more civil
discussions, and the lack of interest[1] of corporations in getting
their patented tech sanctioned in it[2].

There's also the procedural facts that (1) Python really produces only
one standard (no need for an umbrella organization to police the
working committees), and (2) there is no formal voting procedure to
permit log-rolling by such special interests.  But I see no need for
one, given the trust the community had in Guido (sorry for the name
check, Guido, but it's true you know) and now in the Steering
Council.[3]  The voting procedures in other bodies are required
because many of the participants mistrust each other.  However, a
standard should be judged by its content, not the formality (or lack
of it) of the standardization process.

Dan Stromberg points to potential issues with a reference
implementation.  But by definition, a *reference* implementation
implements a standard.  This is only a problem if the standard is
sufficiently sloppy that the only way to determine conformance of an
alternative implementation is by comparing behavior to the reference
implementation.  But that's not a problem with reference
implementations, that's a problem with the particular standard.  It's
true that frequently it's (much) more convenient to ask your friendly
neighborhood Python interpreter what some expression does than to try
to figure it out from the reference (David Beazley has made a PyCon
speaking career out of such oddities!), but that's a *benefit* of the
reference implementation, not a problem.

There's another kind of standard, where the "reference" implementation
*is* the standard.[4]  If the docs differ from the implementation, you
change the docs.  That's *not true* (in principle) for Python, except
that fairly often where the docs are ambiguous and it matters, the
standard will be amended in the next version to conform to CPython's
behavior.  However, where the behavior of CPython contradicts the
references, that's considered to be a bug to be fixed.  Amending the
docs in those cases does happen, but it's controversial and needs to
be supported by showing that the implementation behavior is depended
on by applications in the wild.

Also note the characterization of CPython in
https://en.wikipedia.org/wiki/Reference_implementation.  (I didn't
check to see if a Pythonista were the most recent editor tho. ;-)

Steve

Footnotes: 
[1]  Or perhaps their recognition that it's a no-go and not worth
their effort.

[2]  Even there, occasionally powerful core developers have been able
to push through features they wanted for $DAYJOB (async and type
hints, I'm looking at you).  Those would have been major firefights in
the absence of trust.

[3]  Case in point: The pattern-matching PEPs are controversial, but
note that *nobody* has questioned the legitimacy of the SC, only its
judgment, when questioning the approval of that series of PEPs.  And
the general reaction has been "great, now we can move on with it!", as
far as I can tell.

[4]  I'm pretty sure there's a different term for such implementations
but for the life of me I can't remember it.  Or it's possible that
"reference implementation" was the right term for "the implementation
is the standard", and the meaning has changed since nobody does that
any more (or at least nobody with a shred of pride is willing to admit
it).  Anyway, now the accepted meaning of reference implementation is
that it is an implementation that satisfies all requirements of the
(separate) standard.
___
Python

[Python-Dev] Re: Python standardization

2021-02-13 Thread Paul Sokolovsky 
Hello,

On Sat, 13 Feb 2021 23:10:59 +0900
"Stephen J. Turnbull"  wrote:

> Chris Angelico writes:
> 
>  > Can you explain what would be improved by having a formalized
>  > standard?  
> 
> The Language Reference together with the Library Reference *already*
> constitute a formalized standard.  They are at least as precise as
> most W3C or IETF standards.

You must be kidding, right? Library Reference is full of
underspecification and gaps. Here's a recent example which I bothered
to report and which was even fixed: https://bugs.python.org/issue42559.
Such reports can be easily closed either, so most people don't even try
to report them after initial experience.

Language Reference is also not exactly clearly and well structured, and
leaves doubts about its completeness. For example, there's a common
complaint (in narrow circles?) that Python's scoping rules are unclear
and confusing. And indeed,
https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
could be improved. I recently made a pass over it to clarify some
things, once sweet day I'll post that as a patch, and let's see what
happens (my bet is that it will be closed as many other patches).

As an example from there:

> If a name is bound in a block, it is a local variable of that block,
> unless declared as nonlocal or global. If a name is bound at the
> module level, it is a global variable. (The variables of the module
> code block are local and global.) If a variable is used in a code
> block but not defined there, it is a free variable.

Based on the above, are global/nonlocal vars free in the code block
they are declared in? It's hard to tell, because there's a soup of
terminology - "bound", "defined"; just "block", "code block", etc. And
description there and information available via the
https://docs.python.org/3/library/symtable.html module sometimes don't
agree (there are bugreports on that too).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/F47V5Q7R2AK7SSPMOFJCZ276D4564PVG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-02-13 Thread Inada Naoki 
To demonstrate how this warning is useful, I used my reference implementation.

When I try `pip install`, I found these issues soon.

https://bugs.python.org/issue43214 (Open pth file with locale-encoding)
https://github.com/pypa/pip/pull/9608 (Not a real bug, but open JSON
file with locale-encoding)

And when creating a PR for pip, I found this issue in tox:

https://github.com/tox-dev/tox/issues/1908 (Open toml file with
locale-encoding, may not work on Windows)

Although most developers won't use this option, I and few other
developers can put `export PYTHONWARNENCODING=1` in .bashrc and will
find many possible bugs that happen only on Windows, even if they
don't use Windows daily development.

Isn't this option worth enough?
-- 
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/K7PVGEHDB3BXLNFZ6UWFJOKCC337UTWO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Luciano Ramalho 
On Fri, Feb 12, 2021 at 3:36 PM Dan Stromberg  wrote:
> I think standardizing Python might be really good for controlling its growth 
> and avoiding featuritis.

The dynamics of standard committees lead to even more acute cases of
featuritis: "I support your pet feature if you support mine."

Cheers,

Luciano



>
> ___
> 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/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/VTVPNXP3DUQHWQZOSDZWJEFYRRNBQP7X/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-02-13 Thread Guido van Rossum 
> On Sat, 13 Feb 2021 at 07:11, Steven D'Aprano  wrote:
> > Without reading the PEP, how is anyone supposed to know that this
> > returns a bool?
>

By looking at the name, or at the return statements in the body. These are
expected to be really short. Tooling can certainly easily be taught what
TypeGuard[...] means -- the whole *point* is to enable tooling (it provides
an essential, albeit minor, piece of new functionality for type checkers).

On Sat, Feb 13, 2021 at 2:38 AM Paul Moore  wrote:

> I have to agree here. I'm not a frequent user of type hints yet, but I
> am starting to have to maintain code that has type hints, and from a
> maintenance perspective, I have to say that this would be really hard
> to deal with. If I saw this for the first time "in the wild", I'd have
> no idea what to do with it.
>

Think of it as new syntax. Of course you have to learn it (or Google it).
Is it easy to learn? I think so. Is it easy to recognize once you've seen
and understood it once? Yes.  Is it easy to use it correctly given an
example? Yes again.

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

[Python-Dev] Re: Python standardization

2021-02-13 Thread Mats Wichmann 



On 2/12/21 5:19 PM, Guido van Rossum wrote:
 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.


Having been through ISO standardization several times, a couple of notes.

The first time doesn't have to be particularly expensive - there's a 
route where an established organization can register to submit an 
already available standard (and I'd argue the Python language docment is 
that).  However, once you've had the one free hit, you then have to 
follow the ISO standards maintenance and development rules going 
forward. And that is comparatively expensive.


Is there value?  Every healthy project has a "three pillars" approach, 
whether stated as such or not, where there is specification, one or more 
implementations, and test. It's just that the right balance of those has 
to be determined each time (and often evolves over time, as maturity may 
change the equation).  The specification can be as formal as being 
blessed by and under control of a formal body like ISO (though it's 
still edited by practitioners), or as informal as "the comments in the 
code".  An implementation can drive the process ("reference 
implementation", where modulo bugs, the implementation determines the 
answer if something turns out to be unclear or wrong in the 
specification); or an implementation can be relatively obscure, just 
used to show "yes, we can indeed implement this".  Similarly, tests can 
be at the level of checking the implementation, or it can be as formal 
as a test suite that is administered by an accredited testing agency, 
and passing it (for a fee) is mandatory to be able to use a trademark.


With all that said: Python has all three of the pillars in place: spec, 
main implementation, several other implementations of the language, and 
a solid test suite.  Would changing the balances of those make anything 
better than it is now?  I'm not a core dev but I fail to see how.


What's the problem that is not being solved now that could be improved? 
Is it the recent fairly rate of change?



Postscript: I once participated in "standardizing" Python on a very 
limited basis.  The Linux Standard Base included a lightweight 
description of Python 2.4, with a reference to that version of the 
language spec, and a curated list of standard library modules which had 
to be provided.  The concept was that the user of any LSB-conforming 
system would know it was possible to install "LSB Python" and 
applications coded to that would then work in the expected way - the 
distributions didn't have to provide that as their main Python, just had 
to make that "known" version available.  Interesting exercise, but in 
the end I'm nearly 100% sure that the exercise added no value to the 
Python ecosystem which has done just fine for the nearly 20 years since 
that bit of work, which has since faded away into obscurity.


Cheers,

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

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

2021-02-13 Thread Paul Moore 
On Sat, 13 Feb 2021 at 17:33, Guido van Rossum  wrote:
> On Sat, Feb 13, 2021 at 2:38 AM Paul Moore  wrote:
>>
>> I have to agree here. I'm not a frequent user of type hints yet, but I
>> am starting to have to maintain code that has type hints, and from a
>> maintenance perspective, I have to say that this would be really hard
>> to deal with. If I saw this for the first time "in the wild", I'd have
>> no idea what to do with it.
>
>
> Think of it as new syntax. Of course you have to learn it (or Google it). Is 
> it easy to learn? I think so. Is it easy to recognize once you've seen and 
> understood it once? Yes.  Is it easy to use it correctly given an example? 
> Yes again.

But looking at it, it's *not* new syntax, it's a return type of
TypeGuard[List[str]], which is perfectly good syntax today. I can look
up what the type TypeGuard is, but most of the time, when maintaining
code, I don't do that - I just think "hmm, returns Foo, that's all I
need to know right now". But then I discover that it's returning a
boolean, and I'm confused. And it's always going to be an exception to
the rule that what's after the -> is the type of the return value. I
personally think "Special cases aren't special enough to break the
rules" applies here, but I admit I don't know how special this case
is, nor do I know why no less exceptional alternative is possible.

Of course I can look it up, but it's a distraction from what I was
trying to do. Of course it's easy to google, but it's the *only*
annotation I've ever needed to google. Of course it's optional and
only affects type checkers, but I don't control everything that gets
added to code bases I support.

*shrug* it makes little difference in the grand scheme of things,
it'll go in if enough people who have influence over the decision are
OK with it. And I'm sure it fills a need for certain types of project.
It's not going to make my life impossible either way. But if
impressions from casual users are being counted, I remain -1.

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

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stefano Borini 
Not sure about python, but throughout my career I had to work with
MISRA C standardisation for critical systems.
There is more and more that is handled by python that also needs to go
through validation. I wonder if there's value in that?


On Fri, 12 Feb 2021 at 18:40, 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/



-- 
Kind regards,

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

[Python-Dev] Re: Python standardization

2021-02-13 Thread Stephen J. Turnbull 
Paul Sokolovsky writes:
 > Hello,
 > 
 > On Sat, 13 Feb 2021 23:10:59 +0900
 > "Stephen J. Turnbull"  wrote:
 > 
 > > Chris Angelico writes:
 > > 
 > >  > Can you explain what would be improved by having a formalized
 > >  > standard?  
 > > 
 > > The Language Reference together with the Library Reference *already*
 > > constitute a formalized standard.  They are at least as precise as
 > > most W3C or IETF standards.
 > 
 > You must be kidding, right? Library Reference is full of
 > underspecification and gaps.

No, I'm not kidding.  Did you read what I wrote?  I did not write that
the Python References are perfect and suitable for automatic
validation.  I wrote that they are of similar quality to most
standards published by the IETF or W3C.

They are, in my experience.  (And at least the IETF email working
groups have a much easier task, since it's mostly restricted to syntax
of wire protocols -- most semantics are left up to the receiving
agents.)  For example, the first attempt at a careful description of
how the many agents in the email system interact is RFC 5598 (from
2009), while the current controlling RFC for message format is RFC
5322 (from 2008), and the actual standard is STD 11 = RFC 822 (from
1982!).  You think you have problems defining free variables in a code
block, the IETF email working groups literally operated for decades
without trying to define some important terms!

If you want more precise definitions and complete specifications in
the Language Reference and Library Reference, put them there yourself,
and encourage others to do the same.  We'll all thank you.  And you
can be thankful that you only have to get them past the Steering
Council, not the member nations (!) of ISO/IEC Joint Technical
Committee 1 / Subcommittee 22 / Working Group 21. :-)

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

[Python-Dev] Re: Python standardization

2021-02-13 Thread Wes Turner 
https://awesome-safety-critical.readthedocs.io/en/latest/
https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards

What is and is not constant time in Python could be added to structured
data elements in (implementations') docstrings.

*

"The Python Language Reference"
https://docs.python.org/3/reference/

https://docs.python.org/3/reference/lexical_analysis.html
https://docs.python.org/3/reference/datamodel.html
https://docs.python.org/3/reference/executionmodel.html
[...]

Python PEG Grammar:
https://docs.python.org/3/reference/grammar.html
https://github.com/python/cpython/blob/master/Grammar/python.gram
https://github.com/python/cpython/blob/master/Lib/test/test_grammar.py

"24. Changing CPython’s Grammar"
https://devguide.python.org/grammar/

https://devguide.python.org/appendix/#language-development-in-depth :

> Exploring CPython’s Internals
> Changing CPython’s Grammar
> Design of CPython’s Compiler
> Design of CPython’s Garbage Collector
> Adding to the Stdlib
> Changing the Python Language
> Porting Python to a new platform

*

Wikipedia: https://en.wikipedia.org/wiki/ECMAScript
Homepage: https://www.ecma-international.org/ecma-262/
Src: https://github.com/tc39/ecma262#ecmascript
Spec: https://www.ecma-international.org/ecma-262/
Spec: https://tc39.github.io/ecma262/
Spec: https://tc39.es/ecma262/ :

ECMA262 Spec Table of Contents:
```quote
Introduction
1 Scope
2 Conformance
3 Normative References
4 Overview
5 Notational Conventions
6 ECMAScript Data Types and Values
7 Abstract Operations
8 Syntax-Directed Operations
9 Executable Code and Execution Contexts
10 Ordinary and Exotic Objects Behaviours
11 ECMAScript Language: Source Code
12 ECMAScript Language: Lexical Grammar
13 ECMAScript Language: Expressions
14 ECMAScript Language: Statements and Declarations
15 ECMAScript Language: Functions and Classes
16 ECMAScript Language: Scripts and Modules
17 Error Handling and Language Extensions
18 ECMAScript Standard Built-in Objects
19 The Global Object
20 Fundamental Objects
21 Numbers and Dates
22 Text Processing
23 Indexed Collections
24 Keyed Collections
25 Structured Data
26 Managing Memory
27 Control Abstraction Objects
28 Reflection
29 Memory Model
A Grammar Summary
B Additional ECMAScript Features for Web Browsers
C The Strict Mode of ECMAScript
D Host Layering Points
E Corrections and Clarifications in ECMAScript 2015 with Possible
Compatibility Impact
F Additions and Changes That Introduce Incompatibilities with Prior Editions
G Colophon
H Bibliography
I Copyright & Software License
```quote

... https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
https://docs.python.org/3/reference/introduction.html#alternate-implementations



On Sat, Feb 13, 2021 at 1:18 PM Stefano Borini 
wrote:

> Not sure about python, but throughout my career I had to work with
> MISRA C standardisation for critical systems.
> There is more and more that is handled by python that also needs to go
> through validation. I wonder if there's value in that?
>
>
> On Fri, 12 Feb 2021 at 18:40, 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/
>
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/NR3UAEPEUJCWDBQVQW3QN4JYZWZNR2IU/
> 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/WBDCMKUYRCBG5V3KFZMNOQ3X3S7SODJH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

2021-02-13 Thread Chris Angelico 
On Sun, Feb 14, 2021 at 7:38 AM Wes Turner  wrote:
>
> https://awesome-safety-critical.readthedocs.io/en/latest/
> https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards
>
> What is and is not constant time in Python could be added to structured data 
> elements in (implementations') docstrings.
>

That debate happened a while ago regarding string subscripting. The
conclusion was that "happens in constant time" is NOT part of the
specification. The Python language stipulates that, when you subscript
a string with an integer, you'll get back a single-character string;
but it's absolutely acceptable for an implementation to do this in
O(n) time under certain circumstances if it chooses.

So you're absolutely correct: it would have to be in the
*implementations'* docstrings. It's not part of the language.

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

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

2021-02-13 Thread Eric Traut 
I think it's a reasonable criticism that it's not obvious that a function 
annotated with a return type of `TypeGuard[x]` should return a bool. That said, 
the idea of a user-defined type guard comes from TypeScript, where the syntax 
is described 
[here](https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards).
 As you can see, the return type annotation here is also not a boolean. To my 
knowledge, that has not been a barrier for TypeScript developers. As Guido 
said, it's something that a developer can easily look up if they are confused 
about what it means.

I'm open to alternative formulations that meet the following requirements:
1. It must be possible to express the type guard within the function signature. 
In other words, the implementation should not need to be present. This is 
important for compatibility with type stubs and to guarantee consistent 
behaviors between type checkers.
2. It must be possible to annotate the input parameter types _and_ the 
resulting (narrowed) type. It's not sufficient to annotate just one or the 
other.
3. It must be possible for a type checker to determine when narrowing can be 
applied and when it cannot. This implies the need for a bool response.
4. It should not require changes to the grammar because that would prevent this 
from being adopted in most code bases for many years.

Mark, none of your suggestions meet these requirements. Gregory, one of your 
suggestions meets these requirements:

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

So, the question is whether this is more understandable and readable than this:

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

Both of these approaches would require a developer to do a search to understand 
the meaning. The former also introduces a novel use of the slice notation, 
which I find very unintuitive. Between these two, I find the latter to be 
clearly preferable, but that's admittedly a subjective opinion.

As for choosing the name of the annotation... Most annotations in Python are 
nouns, for good reason. (There are a few exceptions like `Optional` that are 
adjectives.) For that reason, I'm not a fan of `Narrows`. I definitely wouldn't 
use `Constrains` because there's already a meaning in the Python type system 
for a "constrained type variable" (a TypeVar can constrained to two or more 
different types). `TypeGuard` is the term that is used in other languages to 
describe this notion, so it seems reasonable to me to adopt this term rather 
than making up a new term. Yes, it's introducing a new term that most Python 
users are not yet familiar with, but I can tell you from experience that very 
few Python developers know what "type narrowing" means. Some education will be 
required regardless of the formulation we choose.

Steven, you said you'd like to explore a decorator-based formulation. Let's 
explore that. Here's what that it look like if we were to meet all of the above 
requirements.

```python
@type_guard(List[str])
def is_str_list(val: List[object]) -> bool: ...
```

The problem here, as I mention in the "rejected ideas" section of the PEP, is 
that even with postponed type evaluations (as described in PEP 563), the 
interpreter cannot postpone the evaluation of an expression if it's used as the 
argument to a decorator. That's because it's not being used as a type 
annotation in this context. So while Mark is correct to point out that there 
has been a mechanism available for forward references since PEP 484, we've been 
trying to eliminate the use of quoted type expressions in favor of postponed 
evaluation. This would add a new case that can't be handled through postponed 
evaluation. Perhaps you still don't see that as a strong enough justification 
for rejecting the decorator-based formulation. I'm not entirely opposed to 
using a decorator here, but I think on balance that the `TypeGuard[x]` 
formulation is better. Once again, that's a subjective opinion.

Paul said:
>...to work around deficiencies in the current generation of Python typecheckers

It sounds like you're implying that this functionality will be no longer needed 
at some point in the future when type checkers improve in some (unspecified) 
manner. If that's what you meant to convey, then I disagree. I think there will 
be an ongoing need for this functionality. There's good evidence for this in 
TypeScript, where user-defined type guards have been adopted widely by 
developers.

--
Eric Traut
Contributor to Pyright & Pylance
Microsoft Corp.
___
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/XLOTPVQMG53FXPP4HBGC6YGK2ZZJ5FMM/
Code of Conduct: http://python.org/psf/code

[Python-Dev] Re: PR Review request - bpo-41928: Add support for Unicode Path Extra Field in ZipFile

2021-02-13 Thread Andrea Giudiceandrea via Python-Dev 
Terry Reedy wrote:
> I nosied and requested a review from the active zipfile 'expert' (Serhiy).

Thank you Terry.

Regards.

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

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

2021-02-13 Thread Paul Sokolovsky 
Hello,

On Sat, 13 Feb 2021 19:48:10 -
"Eric Traut"  wrote:

[]

> Paul said:
> >...to work around deficiencies in the current generation of Python
> >typecheckers  
> 
> It sounds like you're implying that this functionality will be no
> longer needed at some point in the future when type checkers improve
> in some (unspecified) manner. If that's what you meant to convey,
> then I disagree. I think there will be an ongoing need for this
> functionality. There's good evidence for this in TypeScript, where
> user-defined type guards have been adopted widely by developers.

That's certainly a good argument on its own (providing cross-language
functionality and adopting known best practices).

But taken without context like that, I wonder if the example from the
PEP647:

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)

def func1(val: List[object]):
if is_str_list(val):
print(" ".join(val)) # Error: invalid type 

would work if "type guard function" was inlined:

def func1(val: List[object]):
if all(isinstance(x, str) for x in val):
print(" ".join(val)) # Is this valid or not? 

If the answer is "no", then it points to pretty weak ability of
abstract interpretation of the current typecheckers. If the answer is
"yes", it's more reassuring, but then the problem is weak
interprocedural capabilities of the current typecheckers.

I certainly understand all the technical challenges with that (likely
performance), asymptotically turning into halting problem. And yet I
may imagine that many practically useful typeguards will be simple
enough (like above), and may be automatically type-inferred in the
future.

Then the syntax for explicit type guard annotation is less important
(would be used as an exception, not a rule), and if it's useful now to
keep up the pace of the typechecker research, then I'd be +1 with it
(instead of nitpicking at it, as seem to be the case with other recent
replies). 

> 
> --
> Eric Traut
> Contributor to Pyright & Pylance
> Microsoft Corp.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/SWRAN4MMYN3NUENFDN2ZUC7P4SVDORPY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2021-02-13 Thread Greg Ewing 

On 14/02/21 8:48 am, Eric Traut wrote:


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


Maybe something like this?


def is_str_list(val: List[str] if True else List[object]) -> bool:
   ...

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