[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 13 Apr 2021 03:09:28 +0100 Filipe Laíns wrote: > > This is simply not a good point in itself, and on top of that it seems to > completely ignore that Python could be untyped, Python is definitely not untyped. It's strongly typed. Its typing is just dynamic and isn't explicitly spelled

[Python-Dev] Revive PEP 396 -- Module Version Numbers ?

I've already asked on python-ideas, but it was suggested that as there's a PEP already, it's time to move this along. So here's the pitch. Over the years, I've seen __version__ used very broadly but not *quite* in all packages. I've always known it was a convention, not a requirement. But it

[Python-Dev] Re: Boundaries between numbers and identifiers

I feel like all of these examples, if found in the wild, are far more likely to be uncaught bugs than programmer intent. Being strict about spaces (or parents, brackets, etc. in other contexts) around numbers is much more straightforward than a number of edge cases where is not obvious what will

[Python-Dev] Re: Making staticmethod callable, any oposite?

On 4/13/2021 9:20 PM, Inada Naoki wrote: But Mark Shannon said we shouldn't make such a change without discussing at python-dev. I don't know we *should*, but I agree that it is *ideal*. I consider this case borderline. A lot of changes get made, and must be, without pydev discussion.

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On 4/12/21 7:43 PM, Hugh Fisher wrote: Having a type checker run before the Python interpreter in our current day continuous build/integration environment adds a second step This is very similar to statically typed languages. They also have two steps: * There is the first step that checks

[Python-Dev] Typing syntax and ecosystem, take 2

Hugh Fisher writes: > In any Python 3.6 or later, type > > >>> x : float = 1 > >>> isinstance(x, float) > >>> type(x) [snip] > As someone who has programmed in FORTRAN, Pascal, C/C++, > Java, and Go this is not at all what I consider reasonable. >From the point of view of

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi Larry, On 4/12/21, 6:57 PM, "Larry Hastings" wrote: Again, by "works on PEP 563 semantics", you mean "doesn't raise an error". But the code has an error. It's just that it has been hidden by PEP 563 semantics. I don't agree that changing Python to automatically hide errors is an

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Le 13/04/2021 à 04:24, Guido van Rossum a écrit : > > I've been thinking about this a bit, and I think that the way forward is > > for Python to ignore the text of annotations ("relaxed annotation > >

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, Le 13/04/2021 à 04:24, Guido van Rossum a écrit : > I've been thinking about this a bit, and I think that the way forward is > for Python to ignore the text of annotations ("relaxed annotation > syntax"), not to try and make it available as an expression. Then, what's wrong with quoting?

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 2021-04-13 at 09:20 +0200, Antoine Pitrou wrote: > On Tue, 13 Apr 2021 03:09:28 +0100 > Filipe Laíns wrote: > > > > This is simply not a good point in itself, and on top of that it seems to > > completely ignore that Python could be untyped, > > Python is definitely not untyped.  It's

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, Le 12/04/2021 à 03:55, Larry Hastings a écrit : > > I look forward to your comments, 2 reading notes: * in section "Annotations That Refer To Class Variables": > If it's possible that an annotation function refers > to class variables--if all these conditions are true: > > * The

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, Apr 13, 2021 at 1:46 AM Hugh Fisher wrote: > In any Python 3.6 or later, type > > >>> x : float = 1 > >>> isinstance(x, float) > > or replace the second line with > > >>> type(x) > > As someone who has programmed in FORTRAN, Pascal, C/C++, > Java, and Go this is not at all

[Python-Dev] Re: Boundaries between numbers and identifiers

26.04.18 21:37, Serhiy Storchaka пише: > In Python 2.5 `0or[]` was accepted by the Python parser. It became an > error in 2.6 because "0o" became recognizing as an incomplete octal > number. `1or[]` still is accepted. > > On other hand, `1if 2else 3` is accepted despites the fact that "2e" can >

[Python-Dev] PEP-0467: Minor API improvements for binary sequences

Looking for final comments before submitting for SC approval. It would be nice to finally get this resolved. :) Full text follows. --- PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings wrote: > > On 4/12/21 7:24 PM, Guido van Rossum wrote: > > I've been thinking about this a bit, and I think that the way forward is > for Python to ignore the text of annotations ("relaxed annotation syntax"), > not to try and make it available as

[Python-Dev] Re: Boundaries between numbers and identifiers

On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka wrote: > 26.04.18 21:37, Serhiy Storchaka пише: > > In Python 2.5 `0or[]` was accepted by the Python parser. It became an > > error in 2.6 because "0o" became recognizing as an incomplete octal > > number. `1or[]` still is accepted. > > > > On

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression. To be honest, the most pressing issue with

[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences

Thanks for this PEP! Most of these proposals would make for useful improvements to the language. I have a few pieces of feedback below. El mar, 13 abr 2021 a las 14:14, Ethan Furman () escribió: > This PEP has been deferred until Python 3.9 at the earliest, as the open > This should be 3.10 at

[Python-Dev] Re: Typing syntax and ecosystem

On Apr 13, 2021, at 14:55, Luciano Ramalho wrote: > > Hugh was unfortunate in presenting the problem, but I agree that we > should commit all the way to supporting type hints, and that means > bundling a type checker as part of the standard library and > distribution. I wouldn’t necessarily be

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Wed, Apr 14, 2021 at 9:45 AM Hugh Fisher wrote: > I don't want Python to be explicitly typed either. I'm happy with dynamic > typing, and do not want to have to write even > x : object You don't. That's not the proposal. The proposals have ALL been about gradual typing and inferred

[Python-Dev] Re: Typing syntax and ecosystem

The old rule is best: be strict in what you produce and liberal i what you accept. Kind regards, Steve On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman wrote: > On 4/12/2021 6:34 PM, Brett Cannon wrote: > > Had the sentences ended at "confusing" or said something like "I don't > think it's as

[Python-Dev] Re: Typing syntax and ecosystem

On Apr 13, 2021, at 16:35, Rob Cliffe via Python-Dev wrote: > (Gasps in horror.) I can only hope I've misunderstood this sentence. Has it > ever been even tentatively suggested that type hinting become mandatory? > (What would that even mean: that the type of every function parameter or >

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + codeop modules is that people should be able to write

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 13 Apr 2021 at 12:09, Filipe Laíns wrote: > [ munch ] > > Python is not a typed language, it is a language with optional typing. Well, it's a dynamically typed language. And yes I agree, I want typing to remain optional. I am happy that I can write x = 1 x = [ "hello", "world" ]

[Python-Dev] Re: Typing syntax and ecosystem

On 13/04/2021 23:21, Barry Warsaw wrote: I would still be opposed to requiring type hinting in Python. -Barry (Gasps in horror.)  I can only hope I've misunderstood this sentence.  Has it ever been even tentatively suggested that type hinting become mandatory?  (What would that even mean:

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 13 Apr 2021 at 20:30, Stephen J. Turnbull wrote: [ munch ] > > As someone who has programmed in FORTRAN, Pascal, C/C++, > > Java, and Go this is not at all what I consider reasonable. > > From the point of view of typing, you've programmed in one other > language. ;-) (Maybe Go makes

[Python-Dev] Re: Typing syntax and ecosystem

On Wed, 14 Apr 2021 at 08:21, Barry Warsaw wrote: > I wouldn’t necessarily be opposed to bundling a type checker with the > interpreter/stdlib, but I think there are some issues with it. Just off the > top of my head (there are undoubtedly many more issues to resolve): > > * Which type checker

[Python-Dev] Re: Boundaries between numbers and identifiers

It would be useful to first estimate how many projects would be broken by such incompatible change (stricter syntax). Inada-san wrote https://github.com/methane/notes/blob/master/2020/wchar-cache/download_sdist.py to download source files using https://hugovk.github.io/top-pypi-packages/ API (top

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 3:28 PM, Terry Reedy wrote: On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + codeop modules

[Python-Dev] Re: Typing syntax and ecosystem

Hugh was unfortunate in presenting the problem, but I agree that we should commit all the way to supporting type hints, and that means bundling a type checker as part of the standard library and distribution. There is always a delay after a Python release before Mypy catches up to—and that's the

[Python-Dev] Re: Boundaries between numbers and identifiers

On Apr 13, 2021, at 12:52, Serhiy Storchaka wrote: > > New example was found recently (see https://bugs.python.org/issue43833). > [0x1for x in (1,2)] > [31] > > It is parsed as [0x1f or x in (1,2)] instead of [0x1 for x in (1,2)]. That’s a wonderfully terrible example! Who’s maintaining

[Python-Dev] Re: Boundaries between numbers and identifiers

On 14/04/21 8:54 am, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka >  >>> [0x1for x in (1,2)] I would totally make that a SyntaxError, and backwards compatibility be damned. Indeed. Python is not Fotran! -- Greg

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Tue, 13 Apr 2021 at 18:43, Stéfane Fermigier wrote: > [ munch ] > > Python is, historically, a dynamically typed language, and gradual typing > (see https://en.wikipedia.org/wiki/Gradual_typing) has been progressively > added to it in the last decade or so. This is a legitimate approach,

[Python-Dev] Re: Typing syntax and ecosystem

I see multiple problems with including a type checker as part of the standard library: First of all this would require defining precise type checking semantics and not making breaking changes to them. Currently some parts of type checking are not precisely defined and are done differently by

[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences

On 4/13/21 3:01 PM, Jelle Zijlstra wrote: Thanks for this PEP! Most of these proposals would make for useful improvements to the language. I have a few pieces of feedback below. El mar, 13 abr 2021 a las 14:14, Ethan Furman escribió: This PEP has been deferred until Python 3.9 at the

[Python-Dev] Re: Typing syntax and ecosystem, take 2

> From: Ned Batchelder [ munch ] > This is very similar to statically typed languages. They also have two > steps: > > * There is the first step that checks the types but does not run the > program. In C/C++, this is the compiler, in Python it is "mypy". > * There is the second step that

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On 4/13/21 7:40 PM, Hugh Fisher wrote: From: Ned Batchelder [ munch ] This is very similar to statically typed languages. They also have two steps: * There is the first step that checks the types but does not run the program. In C/C++, this is the compiler, in Python it is "mypy".

[Python-Dev] Re: Typing syntax and ecosystem, take 2

On Wed, Apr 14, 2021 at 9:47 AM Hugh Fisher wrote: > > > From: Ned Batchelder > [ munch ] > > This is very similar to statically typed languages. They also have two > > steps: > > > > * There is the first step that checks the types but does not run the > > program. In C/C++, this is the

[Python-Dev] Making staticmethod callable, any oposite?

Hi, all. I am implementing PEP 597. During review, Victor suggested to deprecate `OpenWrapper`. `OpenWrapper` is defined only for compatibility between C function and Python function: ``` from _pyio import open as py_open from _io import open as c_open class C: py_open = py_open c_open

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 1:52 PM, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings > wrote: On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings wrote: > > > On 4/13/21 1:52 PM, Guido van Rossum wrote: > > > Because typing is, to many folks, a Really Important Concept, and it's > confusing to use the same syntax ("x: blah blah") for different purposes, in > a way that makes it hard to tell