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

[Christopher Barker]

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 turns out it's not even a "official" convention.

But it really would be nice if there was a consistent way that I could
count on to get the version of a package at run time from the package
itself.

Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!

https://www.python.org/dev/peps/pep-0396/

In the status note, it says:

"""
Further exploration of the concepts covered in this PEP has been deferred
for lack of a current champion interested in promoting the goals of the PEP
and collecting and incorporating feedback, and with sufficient available
time to do so effectively.
"""

Well, I may be willing to be that champion, if a core dev is willing to
sponsor.

And, well, after 13 years, we've seen __version__ be very broadly, though
certainly not universally used.

Honestly, I haven't looked to see to what extent setuptools supports it,
but will, of course, do so if folks think this is worth pursuing. And the
PyPA has moved toward "distribution" meta data, preliminarily supported by
importlib.metadata.version.

So  maybe this is a settled issue, and we just need to change the status of
the PEP.

But for my part, I FAR prefer the version info to be embedded in the code
of the package in a simple way, rather than hiding among the metadata, and
requiring importlib.metadata.version to get a version at runtime.

I note that PEP8 uses __version__ as an example of a "module level dunder"
-- but only suggests where it should be put, not how it be used :-)

Of course, there will be a need to update the PEP to match current
practice, and if it is me doing it, I'd make it very simple

So what do you'all think? After thirteen years, it would be nice to put
this to bed.

I think the next step is to see if I can find a sponsor :-)

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EY44EMZ2R4RUMUUIVEFFVOXM2H3L427Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

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.


Then, does anyone oppose this change?

Histrically, this idea had been rejected once. bpo-20309 proposed
making classmethod and staticmethod callable.
https://bugs.python.org/issue20309

It had been rejected by:

"I don't agree that this is a bug that should be fixed.  It adds code
that will likely never get called or needed (i.e. there has never been
a request for this in the decade long history of desciptors and it
seems like a made up requirement to me.  "
https://bugs.python.org/issue20309#msg240843


Written by Raymond Hettinger, who continued "If someone object to 
recommendation to close and really wants to push for this, I recommend 
making a business case for acceptance and then assigning this issue to 
Guido for a decision.  This is his code and AFAICT he intentionally 
didn't go down a number of possible paths for descriptors simply because 
there weren't motivating use cases."


You made the case on the issue, and have here, and Guido decided.


"actually supporting this would mean adding code that would need to be
maintained indefinitely without providing a compensating practical
benefit,"
https://bugs.python.org/issue20309#msg240898


Nick Coughlin, following Raymond, who continued
"Thanks Christian for nudging us to make a decision one way or the other."
and
"If another implementation requests clarification, we might want to 
document that "directly callable-or-not" for these descriptors is 
formally an interpreter implementation detail"


So both describe rejection as a close call that could go have gone and 
might in the future go the other way.



But status is changed now. We already have OpenWrapper. It proves
callable classmethod is "called and needed".
Although there is only one use case, we can remove more code than adding.

staticmethod.__call__() is simple C function.
https://github.com/python/cpython/pull/25117/files#diff-57bc77178b3d6f1010dd924722c87522f224d93bc341f0e46c0945094124d8f2

Victor removed OpenWrapper class already, and we can remove `DocDescripter` too.
https://github.com/python/cpython/pull/25354/files#diff-bcdfa9cbb0764d7959cda48f9084d79785f87c5ad7460f27ba2678b0bda76e38R314-L327

I think maintenance burden of staticmethod.__call__() is not higher
than OpenWrapper and DocDescripter.
Additionally, if we have same issue in other module, we can just use
staticmethod, instead of copy&paste OpenWrapper and DocDescripter.

So it provides "compensating practical benefit".



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

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

[David Mertz]

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

On Tue, Apr 13, 2021, 6:24 PM Barry Warsaw  wrote:

> 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 the list? :D
>
> -Barry
>
> ___
> 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/7JXD7SOHACL5SFTA4SBIOWPEG625LD34/
> 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/KMWEK2OLJ34PD3QE5XKTOVMSHCXC4TJA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Inada Naoki]

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 whether a particular "blah blah" is meant as 
> a type or as something else -- because you have to know what's introspecting 
> the annotations before you can tell. And that introspection could be 
> signalled by a magical decorator, but it could also be implicit: maybe you 
> have a driver that calls a function based on a CLI entry point name, and 
> introspects that function even if it's not decorated.
>
>
> I'm not sure I understand your point.  Are you saying that we need to take 
> away the general-purpose functionality of annotations, that's been in the 
> language since 3.0, and restrict annotations to just type hints... because 
> otherwise an annotation might not be used for a type hint, and then the 
> programmer would have to figure out what it means?  We need to take away the 
> functionality from all other use cases in order to lend clarity to one use 
> case?
>

I don't think we need to take away "general purpose functionality".
But if we define type hinting is 1st class use case of annotations,
annotations should be optimized for type hinting.  General purpose use
case should accept some limitation and overhead.

On the other hand, if we decide general purpose functionality is 1st
class too, we shouldn't annotation syntax different from Python
syntax.

But annotations should be optimized for type hinting anyway. General
purpose use case used only is a limited part of application. On the
other hand, type hint can be used almost everywhere in application
code base. It must cheap enough.

Regards,

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

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

[Larry Hastings]

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 annotations ("relaxed
annotation syntax"), not to try and make it available as an
expression.

To be honest, the most pressing issue with annotations is the
clumsy way that type variables have to be introduced. The current
convention, `T = TypeVar('T')`, is both verbose (why do I have to
repeat the name?) and widely misunderstood (many help request for
mypy and pyright follow from users making a mistaken association
between two type variables that are unrelated but share the same
TypeVar definition). And relaxed annotation syntax alone doesn't
solve this.

Nevertheless I think that it's time to accept that annotations
are for types -- the intention of PEP 3107 was to experiment with
different syntax and semantics for types, and that experiment has
resulted in the successful adoption of a specific syntax for
types that is wildly successful.



I don't follow your reasoning.  I'm glad that type hints have
found success, but I don't see why that implies "and therefore we
should restrict the use of annotations solely for type hints". 
Annotations are a useful, general-purpose feature of Python, with
legitimate uses besides type hints.  Why would it make Python
better to restrict their use now?


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 whether a particular 
"blah blah" is meant as a type or as something else -- because you 
have to know what's introspecting the annotations before you can tell. 
And that introspection could be signalled by a magical decorator, but 
it could also be implicit: maybe you have a driver that calls a 
function based on a CLI entry point name, and introspects that 
function even if it's not decorated.



I'm not sure I understand your point.  Are you saying that we need to 
take away the general-purpose functionality of annotations, that's been 
in the language since 3.0, and restrict annotations to just type 
hints... because otherwise an annotation might not be used for a type 
hint, and then the programmer would have to figure out what it means?  
We need to take away the functionality from all other use cases in order 
to lend /clarity/ to one use case?


Also, if you're stating that programmers get confused reading source 
code because annotations get used for different things at different 
places--surely that confirms that annotations are /useful/ for more than 
just type hints, in real-world code, today.  I genuinely have no sense 
of how important static type analysis is in Python--personally I have no 
need for it--but I find it hard to believe that type hints are so 
overwhelmingly important that they should become the sole use case for 
annotations, and we need to take away this long-standing functionality, 
that you suggest is being successfully used side-by-side with type hints 
today, merely to make type hints clearer.



Cheers,


//arry/

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

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

[Inada Naoki]

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 = c_open

C().c_open("README.rst")  # works
C().py_open("README.rst")  # TypeError: expected str, bytes or
os.PathLike object, not C
```

So builtin open is not io.open, but io.OpenWrapper in Python 3.9.
Making staticfunction callable fixes this issue.

```
@staticfunction
def open(...): ...
```

Now open defined in Python behaves like C function. We don't need
OpenWrapper anymore.
This has already been committed by Guido's approval. staticmethod is
callable, and OpenWrapper is just an alias of open and deprecated in
master branch.

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

Then, does anyone oppose this change?

Histrically, this idea had been rejected once. bpo-20309 proposed
making classmethod and staticmethod callable.
https://bugs.python.org/issue20309

It had been rejected by:

"I don't agree that this is a bug that should be fixed.  It adds code
that will likely never get called or needed (i.e. there has never been
a request for this in the decade long history of desciptors and it
seems like a made up requirement to me.  "
https://bugs.python.org/issue20309#msg240843

"actually supporting this would mean adding code that would need to be
maintained indefinitely without providing a compensating practical
benefit,"
https://bugs.python.org/issue20309#msg240898

But status is changed now. We already have OpenWrapper. It proves
callable classmethod is "called and needed".
Although there is only one use case, we can remove more code than adding.

staticmethod.__call__() is simple C function.
https://github.com/python/cpython/pull/25117/files#diff-57bc77178b3d6f1010dd924722c87522f224d93bc341f0e46c0945094124d8f2

Victor removed OpenWrapper class already, and we can remove `DocDescripter` too.
https://github.com/python/cpython/pull/25354/files#diff-bcdfa9cbb0764d7959cda48f9084d79785f87c5ad7460f27ba2678b0bda76e38R314-L327

I think maintenance burden of staticmethod.__call__() is not higher
than OpenWrapper and DocDescripter.
Additionally, if we have same issue in other module, we can just use
staticmethod, instead of copy&paste OpenWrapper and DocDescripter.

So it provides "compensating practical benefit".


Regards,

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

[Python-Dev] Re: Typing syntax and ecosystem

[Barry Warsaw]

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 
> function return value must be specified?)  Some of us don't use type hinting 
> or annotations (I don't even pretend to understand what they are) and don't 
> intend to.  No offence to those who like them, carry on doing your thing.
> Please reassure me, someone. 😁

Rest assured :D

-Barry




signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BC6PFRPMNKMML35GID56GANFZES3AOSE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Steve Holden]

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 optimal as it could be" or "I think it could be better" are
> all fine. But saying that the current approach is "arousing or deserving
> ridicule : extremely silly or unreasonable : absurd, preposterous" as defined
> by Merriam-Webster 
> is not necessary to make the point; it could have been phrased in such a
> way as to be a bit more respectful to those who have put in the time and
> effort to get things to where they are.
>
> My plea is very simple: that everyone would be a bit more gracious.  Email
> by its very nature does not convey meaning as well as in-person
> conversation.  As Hugh just remarked, the meaning you took from his
> comments was not the meaning he intended to convey.  These
> misunderstandings seem to be happening more and more frequently.  I read
> this list to understand the direction that Python will take in the future,
> but I have thought numerous times of unsubscribing due to all the curt "you
> said it wrong" responses like the one that triggered my first email.
>
> Any way, in the interest of not starting a flame war, I will have nothing
> more to say.
> ___
> 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/ETJCGR4ULRYY5WNOLRPULVWMBW4LCY3E/
> 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/E7LWKNKS4CDRS4AZJBZVK5UJ2W6H6AD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Hugh Fisher]

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 would we adopt or adapt, if any?

Mypy.
This has become an implementation issue, not one of which type
system to adopt. A lot of code, even in the stdlib, has been annotated
but I'm not aware of multiple different annotations with different
semantics or type systems being created.

For example, type equivalence by name only is used in Ada (or was,
it's been many years) and probably other languages. In equivalence
by name, the following code would not pass the type checker.
x : list[int]
y : list[int]
x = y # Type error

But I'm not aware of anyone implementing type by name equivalence
for Python, and the original PEP 483 seems to explicitly close off that
possibility. Instead the assumption seems to be Java/C++ structural
equivalence for types.

Skimming a bunch of current type system related PEPs, I'm not seeing
anything that a Java/C++ programmer would find unfamiliar. And this is
probably a good thing.

> * Which parts of the typing system require more frequent release cycles?
> * Is there a core technology that could be put in the stdlib and still allow 
> experimentation?
> * Would the type checker authors become core developers?
> * Do the same feature release / deprecation policies apply?

No answers from me.

> I would still be opposed to requiring type hinting in Python.

I'm opposed to requiring type hints on everything, I want to still be
able to write
x = 1
x = "hello"
etc without declaring any kind of type for x.

-- 

cheers,
Hugh Fisher
___
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/OABB53NTCBU6EKYQVVVY4IU2275XO4R4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 compiler, in Python it is "mypy".
> >   * There is the second step that runs the program but does not check
> > the types. In C/C++, this is running the executable, in Python it is
> > "python".
> >
> > In Python, we can skip the first step, and perhaps that is the source of
> > your concern.  I doubt anyone that has adopted type hinting in Python
> > will forget to run mypy, especially in a CI environment like you consider.
>
> In the current Python implementation, we can't skip the first step.
> Type hints have a significant performance impact on the Python interpreter,
> hence PEP 649. If we used the TypeScript approach, the typing hints would
> be removed before execution by the Python interpreter.
>

You're advocating an approach that absolutely mandates running the
type checker, but then caches the results in an executable file (the
JS file built from the TS source). Python already has a caching system
- the .pyc files - so if you're importing the same file more than
once, the cost of parsing type annotations is pretty much equivalent
to the cost of doing it in TypeScript.

Let's not get caught up in unfair comparisons, and just focus on
making Python as good as it possibly can be.

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

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

[Ned Batchelder]

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".
   * There is the second step that runs the program but does not check
 the types. In C/C++, this is running the executable, in Python it is
 "python".

In Python, we can skip the first step, and perhaps that is the source of
your concern.  I doubt anyone that has adopted type hinting in Python
will forget to run mypy, especially in a CI environment like you consider.

In the current Python implementation, we can't skip the first step.
Type hints have a significant performance impact on the Python interpreter,
hence PEP 649. If we used the TypeScript approach, the typing hints would
be removed before execution by the Python interpreter.


In another message, you alluded to PEP 649 being a solution to run-time 
type checking.  Maybe I'm misunderstanding something: type annotations 
never do type checking at runtime.  As I understand it, PEP 649 is about 
avoiding the overhead of evaluating the type expression itself, not 
about checking the types of values.




As for "forget to run mypy", no-one sets out to do the wrong thing. The
difference here is that with TypeScript -> JavaScript, if you forget to run
the translation step, the program won't run because TypeScript is not
valid JavaScript. Same was true for the old CFront C++ -> C translator.
Errors are automatically detected.

If you forget to run mypy, you've got a program which *looks* correct
but might not be.

Yes, absolutely.  But who is running mypy manually, and therefore could 
forget it? It will be a step in a Makefile, or a tox.ini, or a CI script.


You are right that this approach to type checking can surprise people 
coming from other languages.  And absolutely, you should not use type 
annotations without checking them.  People will learn to do it right.


--Ned.

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

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

[Chris Angelico]

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 typing, so you don't have to annotate
anything that doesn't need it.

Annotating function parameters/return values is about the extent that
I'd ever do for most programs, and even then, not all functions.

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

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

[Hugh Fisher]

> 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 runs the program but does not check
> the types. In C/C++, this is running the executable, in Python it is
> "python".
>
> In Python, we can skip the first step, and perhaps that is the source of
> your concern.  I doubt anyone that has adopted type hinting in Python
> will forget to run mypy, especially in a CI environment like you consider.

In the current Python implementation, we can't skip the first step.
Type hints have a significant performance impact on the Python interpreter,
hence PEP 649. If we used the TypeScript approach, the typing hints would
be removed before execution by the Python interpreter.

As for "forget to run mypy", no-one sets out to do the wrong thing. The
difference here is that with TypeScript -> JavaScript, if you forget to run
the translation step, the program won't run because TypeScript is not
valid JavaScript. Same was true for the old CFront C++ -> C translator.
Errors are automatically detected.

If you forget to run mypy, you've got a program which *looks* correct
but might not be.

-- 

cheers,
Hugh Fisher
___
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/E7ZGBMYX7MCIX2DGDFLHB5XTSYN5IXJL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Hugh Fisher]

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 two, I haven't used it.)  They all
> demand that variables be declared with types, and then proceed to fill
> them with bit patterns that can't be introspected (unless you build it
> in to class definitions yourself).

There are a lot of programmers like me. Those languages I listed are
widely used, and therefore we assume that if a Python language construct
looks like something we've used before, it will work in the same way.

> Python's different approach is a compromise.  And as usual Guido's
> time machine (or somebody borrowed it) is in evidence: if that example
> bothers you, request that people around you who type things like that
> use stub files instead so you don't have to deal with it.

And that would be the TypeScript style approach, "typed Python" is a
language that gets translated into non-type hinted dynamic Python.
No-one who works in JavaScript needs to deal with TypeScript
language features unless they want to. This is not true of the current
typing in Python.

[ munch ]
> This is a good point, but having an explicitly typed language would
> mean I can't really use Python at work (that is, I can't recommend it
> to my business and economics students, who don't program, really, they
> record scripts).

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

>  > From an environmental point of view we're also doing the read
>  > source, lexical scan, syntax parse twice rather than once.
>
> This is not true.  Most programs, *especially* programs that are
> complex enough to want type-checking, are run far more often than they
> are type-checked.

Among the software devs I work with, testing and checking is something
you do *every* time you make a change. If I'm adding type checks to my
program, that's because I want them to be checked.

Historical example would be lint for C programs. Running lint wasn't
required before compiling your C code, but it was so useful that a
number of projects made it compulsory, and the functionality of lint
was eventually incorporated into the C compiler itself.

[ munch ]
> I like to think of it as "Python typing has some warts, but that's
> because it will turn out to be a prince(ss) when you kiss it."

Yes, perfect is the enemy of good enough. I'm reading (OK, skimming)
the emails about implementing PEP 649 on this list and I'm seeing
significant problems in the current tools, not just cosmetic.

-- 

cheers,
Hugh Fisher
___
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/ANIPH3CFWDWIP2SRN2YQVPWR5I3KNIPD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Rob Cliffe via Python-Dev]

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: that the type of every function 
parameter or function return value must be specified?)  Some of us don't 
use type hinting or annotations (I don't even pretend to understand what 
they are) and don't intend to.  No offence to those who like them, carry 
on doing your thing.

Please reassure me, someone. 😁
Rob Cliffe


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

[Python-Dev] Re: Typing syntax and ecosystem

[Adrian Freund]

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 different type checkers. Take 
this example:

if condition:
a = 1
else:
a = "foo"
reveal_type(a)

Mypy raises an error at the second assignment and infers a as int. Pyright on 
the other hand doesn't report errors and infers a as Union[int, str].
Both approaches are equally valid and have their advantages and drawbacks.

My second concern would be the development speed. Python type checking is still 
relatively young and is developing at a vastly different rate from the rest of 
the language. While cpython currently has a 1 year release cycle mypy had 5 
releases (excluding minor releases) in the last year.
This development speed difference can also be seen by the use of 
typing_extensions to back port typing features to older python versions.
GitHub search shows 16.500 python results for "from typing_extensions" 
(excluding forks).
Being tied to the cpython release cycle would probably significantly hinder the 
development of a type checker.

I agree that a delay between a python release and mypy (and other type 
checkers) supporting it isn't optimal, but it can probably be solved much 
easier: By having more developers put in work to keep it up do date.
This work would still need to be done, even for a type checker that's part of 
the standard library.
The only difference would be that changes would then cause tests in cpython to 
fail instead of just in mypy.

In the future, when development on type checkers has slowed, adding a type 
checker to the standard library might be useful, but in my opinion it would 
currently do more harm than good.


Adrian Freund

On April 13, 2021 11:55:05 PM GMT+02:00, 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.
>
>There is always a delay after a Python release before Mypy catches up
>to—and that's the type checker hosted in the python organization on
>github.
>
>I believe this is an unfortunate state of affairs for many users. I am
>not aware of any other optionally typed language that underwent core
>changes to support type annotations and yet does not bundle a type
>checker.
>
>Cheers,
>
>Luciano
>
>
>
>On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher  wrote:
>>
>> > Message: 1
>> > Date: Sun, 11 Apr 2021 13:31:12 -0700
>> > From: Barry Warsaw 
>> > Subject: [Python-Dev] Re: PEP 647 Accepted
>>
>> >
>> > This is something the SC has been musing about, but as it’s not a fully 
>> > formed idea, I’m a little hesitant to bring it up.  That said, it’s 
>> > somewhat relevant: We wonder if it may be time to in a sense separate the 
>> > typing syntax from Python’s regular syntax.  TypeGuards are a case where 
>> > if typing had more flexibility to adopt syntax that wasn’t strictly legal 
>> > “normal” Python, maybe something more intuitive could have been proposed.  
>> > I wonder if the typing-sig has discussed this possibility (in the future, 
>> > of course)?
>>
>> [ munch ]
>>
>> >
>> > Agreed.  It’s interesting that PEP 593 proposes a different approach to 
>> > enriching the typing system.  Typing itself is becoming a little ecosystem 
>> > of its own, and given that many Python users are still not fully embracing 
>> > typing, maybe continuing to tie the typing syntax to Python syntax is 
>> > starting to strain.
>>
>> I would really like to see either "Typed Python" become a different 
>> programming
>> language, or progress to building type checking into the CPython 
>> implementation
>> itself. (Python 4 seems to me the obvious release.) The current halfway 
>> approach
>> is confusing and slightly ridiculous.
>>
>> The first, a separate programming language, would be like RATFOR and CFront
>> in the past and TypeScript today. Typed Python can have whatever syntax the
>> designers want because it doesn't have to be compatible with Python, just as
>> TypeScript is not constrained by JavaScript. A type checker translates
>> the original
>> Typed Python source into "dynamic" or "classic" Python for execution. (Maybe
>> into .pyc instead of .py?)
>>
>> This would mean no overhead for type checking in CPython itself. No need to
>> contort the parser into ignoring bits of code that are, in effect,
>> syntax checked
>> comments. And for the typing in Python enthusiasts, you won't have to listen
>> to people like me complaining.
>>
>> The second approach is to assume that type checking in Python is useful and
>> popular. Not with me, but I'm willing to accept that I'm in the minority and 
>> can
>> be ignored - after all, I can still write my Python code without type

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

[Ethan Furman]

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 earliest, as the open

This should be 3.10 at least (and even that is pushing it by now).


Ah, thanks -- fixed (and fingers crossed for 3.10 -- most of the code/tests are 
already written).


While this does create some duplication, there are valid reasons for it:

* the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio 
from
    Python 2 under a different naming scheme (however, see the Open 
Questions
    section below)
* the class method is mainly for the ``bytearray.fromord`` case, with
    ``bytes.fromord`` added for consistency


I don't see an "Open questions" section in this email (only an "Open issues" 
section talking about memoryview).


Fixed (removed reference to Open questions).

I don't find the argument for a builtin very persuasive. Why is it important to recreate the Python 2 trio? `bchr` is a 
more obscure name than `bytes.fromord`. `bytes.fromord` is already short and doesn't require an import, so we don't gain 
that much from the separate builtin.


`chr` and `ord` are builtins, so `bchr` fits right in.  `bytes.fromord` is there to mirror `bytearray.fromord` and 
facilitate duck-typing.  What you are doing will affect which one you reach for.  For me at least, reading code that 
contains `bytes.fromord` puts too much emphasis on the type and method, whilst `bchr` has it just right.  :-)


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

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

[Larry Hastings]

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 is that people should be 
able to write interactive consoles that simulate the standard REPL.  
For example:


Python 3.10.0a7+ (heads/master-dirty:a9cf69df2e, Apr 12 2021, 
15:36:39) [MSC v.1900 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> code.interact()
Python 3.10.0a7+ (heads/master-dirty:a9cf69df2e, Apr 12 2021, 
15:36:39) [MSC v.1900 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> # Call has not returned.  Prompt is from code.InteractiveConsole.
>>> def f(x:int): -> float

>>> f.__annotations__ # should match REPL result

>>> ^Z

now exiting InteractiveConsole...
>>> Now back to repl

If the REPL compiles with "mode='single' and spec is changes to "when 
mode is 'single'", then above should work.  Larry, please test with 
your proposed implementation.



A couple things!

1. I apologize if the PEP wasn't clear, but this section was talking
   about the problem of /module/ annotations in the implicit __main__
   module when using the interactive REPL. Annotations on other objects
   (classes, functions, etc) defined in the interactive REPL work as
   expected.
2. The above example has a minor bug: when defining a return annotation
   on a function, the colon ending the function declaration goes
   /after/ the return annotation.  It should have been "def f(x:int) ->
   float:".
3. The above example works fine when run in my branch.
4. You need to "from __future__ import co_annotations" in order to
   activate delayed evaluation of annotations using code objects in my
   branch.  I added that (inside the code.interact() shell!) and it
   still works fine.

So I'm not sure what problem you're proposing to solve with this "mode 
is single" stuff.


 * If you thought there was a problem with defining annotations on
   functions and classes defined in the REPL, good news!, it was never
   a problem.
 * If you're solving the problem of defining annotations on the
   interactive module /itself,/ I don't understand what your proposed
   solution is or how it would work.  The problem is, how do you create
   a code object that defines all the annotations on a module, when the
   module never finishes being defined because it's the interactive shell?


Cheers,


//arry/

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

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

[Hugh Fisher]

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, both 
> from an academic and industrial point of view, and similar (with some 
> variants) to what has been done also for JavaScript, Ruby, PHP, Lua, Perl, 
> Scheme, etc. over the same period.

I'm aware of the difference between untyped and dynamic typing, and want
to emphasise that I *like* the dynamic typing in Python. My complaint is not
with gradual typing, but the current way it is done.

[ munch ]

> No need to integrate in CPython, one can already provide runtime type 
> checking using the current language, see e.g. 
> https://pypi.org/project/typeguard/

The current runtime type checking approach is causing significant performance
problems, hence PEP 563, PEP 649, and the current discussion on python-dev
about how to reduce them.

In the TypeScript approach, "typed Python" is a distinct programming language
that is translated into dynamic Python, those problems go away because the
type notation would not be valid Python code. In the integrated approach, type
checking built in, there would still be overhead but it would be
*useful* overhead
doing the actual type checking.

-- 

cheers,
Hugh Fisher
___
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/FSOSTLSCKCUQQUJQBWGDZMUASROAMYGR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Hugh Fisher]

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" ]
x = ExtremelyComplicatedObject()
without even having to qualify it as
x : object

> > Having a type checker run before the Python interpreter in our
> > current day continuous build/integration environment adds a
> > second step and therefore the chance for it to be forgotten, for
> > version mismatches, for warning/error reports to be misdirected.
> > From an environmental point of view we're also doing the read
> > source, lexical scan, syntax parse twice rather than once.
>
> This is simply not a good point in itself, and on top of that it seems to
> completely ignore that Python could be untyped, which is something I am almost
> certain won't likely change ever. At the very least you would have to pass a
> flag to the interpreter to run the type checker, which completely invalidates
> your "people will forget it if they have to explicitly run it" point.

This is my second (and somewhat preferred) proposal where type hints
are recognised by the CPython interpreter, but they would remain optional.
So no flag needed. If there aren't any type hints, that's fine. If there are
type hints, assume they are there on purpose and parse and check.

> All I can think of are reasons *not to* include it with the interpreter, 
> mainly
> that it would be bound to the same super slow release cycle.
> Please also consider that a type checker is something that no user will have 
> to
> run, only developers.

Getting slightly off topic, I have always thought that one of the strengths
of Python is that every use is a potential developer. If you have a Python
program and a text editor, you can change it. No special tools required.

> Why?? This reads like "let's break stuff that is absolutely working" for no 
> real
> discerning reason. Why would you do this? -- Why would we break workflows that
> work? Why would we add a code generating step to typed Python code?
> I am really struggling here to understand what would be the benefit here, it
> seems you want to make it slightly harder for people to forget to run it, by
> either making it always run or forcing a new code generation step.

This is the model used by TypeScript (and various other dialects of JavaScript)
and it works for them. The big advantage is that the Python interpreter does
not need to know about typing, so no PEP 543 and no PEP 649, which is
currently generating a lot of esoteric (to me) discussion on python-dev.

> Please do not take these comments personally, in a verbal setting I would try 
> to
> use social cues to try to pass the feedback more lightly.

No complain from me Filipe, you're doing better at this than I am.

-- 

cheers,
Hugh Fisher
___
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/76EQHZLNMVWVSBIM5XBHHTKPXP7EJLLJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

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 4000 PyPI
projects).

Victor

On Tue, Apr 13, 2021 at 10:59 PM Guido van Rossum  wrote:
>
> 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 other hand, `1if 2else 3` is accepted despites the fact that "2e" can
>> > be recognized as an incomplete floating point number. In this case the
>> > tokenizer pushes "e" back and returns "2".
>> >
>> > Shouldn't it do the same with "0o"? It is possible to make `0or[]` be
>> > parseable again. Python implementation is able to tokenize this example:
>> >
>> > $ echo '0or[]' | ./python -m tokenize
>> > 1,0-1,1:NUMBER '0'
>> > 1,1-1,3:NAME   'or'
>> > 1,3-1,4:OP '['
>> > 1,4-1,5:OP ']'
>> > 1,5-1,6:NEWLINE'\n'
>> > 2,0-2,0:ENDMARKER  ''
>> >
>> > On other hand, all these examples look weird. There is an assymmetry:
>> > `1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
>> > visually the boundary between a number and the following identifier or
>> > keyword, especially if numbers can contain letters ("b", "e", "j", "o",
>> > "x") and underscores, and identifiers can contain digits. On both sides
>> > of the boundary can be letters, digits, and underscores.
>> >
>> > I propose to change the Python syntax by adding a requirement that there
>> > should be a whitespace or delimiter between a numeric literal and the
>> > following keyword.
>> >
>>
>> 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)].
>>
>> Since this code is clearly ambiguous, it makes more sense to emit a
>> SyntaxWarning if there is no space between number and identifier.
>
>
> I would totally make that a SyntaxError, and backwards compatibility be 
> damned.
>
> --
> --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/OU3USHVMXZJD4SA3FJGQQVQYAORHY5BM/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5VYOQRW4DOVDNSIB3G7GBHSUL5ZC3QZO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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

[Python-Dev] Re: Typing syntax and ecosystem

[Barry Warsaw]

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 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 would we adopt or adapt, if any?
* Which parts of the typing system require more frequent release cycles?
* Is there a core technology that could be put in the stdlib and still allow 
experimentation?
* Would the type checker authors become core developers?
* Do the same feature release / deprecation policies apply?

I would still be opposed to requiring type hinting in Python.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P7GMIJY3S7MX25SJB7QZZ57WWYRBV7YD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

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 interactive consoles that simulate the standard REPL.  For example:


Python 3.10.0a7+ (heads/master-dirty:a9cf69df2e, Apr 12 2021, 15:36:39) 
[MSC v.1900 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import code
>>> code.interact()
Python 3.10.0a7+ (heads/master-dirty:a9cf69df2e, Apr 12 2021, 15:36:39) 
[MSC v.1900 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> # Call has not returned.  Prompt is from code.InteractiveConsole.
>>> def f(x:int): -> float

>>> f.__annotations__ # should match REPL result

>>> ^Z

now exiting InteractiveConsole...
>>> Now back to repl

If the REPL compiles with "mode='single' and spec is changes to "when 
mode is 'single'", then above should work.  Larry, please test with your 
proposed implementation.


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

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

[Barry Warsaw]

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 the list? :D

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7JXD7SOHACL5SFTA4SBIOWPEG625LD34/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jelle Zijlstra]

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 least (and even that is pushing it by now).


>
> While this does create some duplication, there are valid reasons for it:
>
> * the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio
> from
>Python 2 under a different naming scheme (however, see the Open
> Questions
>section below)
> * the class method is mainly for the ``bytearray.fromord`` case, with
>``bytes.fromord`` added for consistency
>
>
> I don't see an "Open questions" section in this email (only an "Open
issues" section talking about memoryview).

I don't find the argument for a builtin very persuasive. Why is it
important to recreate the Python 2 trio? `bchr` is a more obscure name than
`bytes.fromord`. `bytes.fromord` is already short and doesn't require an
import, so we don't gain that much from the separate builtin.
___
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/V7O7RGOL2QT73VZJFMPVZAAIZUKXZW72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Luciano Ramalho]

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 type checker hosted in the python organization on
github.

I believe this is an unfortunate state of affairs for many users. I am
not aware of any other optionally typed language that underwent core
changes to support type annotations and yet does not bundle a type
checker.

Cheers,

Luciano



On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher  wrote:
>
> > Message: 1
> > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > From: Barry Warsaw 
> > Subject: [Python-Dev] Re: PEP 647 Accepted
>
> >
> > This is something the SC has been musing about, but as it’s not a fully 
> > formed idea, I’m a little hesitant to bring it up.  That said, it’s 
> > somewhat relevant: We wonder if it may be time to in a sense separate the 
> > typing syntax from Python’s regular syntax.  TypeGuards are a case where if 
> > typing had more flexibility to adopt syntax that wasn’t strictly legal 
> > “normal” Python, maybe something more intuitive could have been proposed.  
> > I wonder if the typing-sig has discussed this possibility (in the future, 
> > of course)?
>
> [ munch ]
>
> >
> > Agreed.  It’s interesting that PEP 593 proposes a different approach to 
> > enriching the typing system.  Typing itself is becoming a little ecosystem 
> > of its own, and given that many Python users are still not fully embracing 
> > typing, maybe continuing to tie the typing syntax to Python syntax is 
> > starting to strain.
>
> I would really like to see either "Typed Python" become a different 
> programming
> language, or progress to building type checking into the CPython 
> implementation
> itself. (Python 4 seems to me the obvious release.) The current halfway 
> approach
> is confusing and slightly ridiculous.
>
> The first, a separate programming language, would be like RATFOR and CFront
> in the past and TypeScript today. Typed Python can have whatever syntax the
> designers want because it doesn't have to be compatible with Python, just as
> TypeScript is not constrained by JavaScript. A type checker translates
> the original
> Typed Python source into "dynamic" or "classic" Python for execution. (Maybe
> into .pyc instead of .py?)
>
> This would mean no overhead for type checking in CPython itself. No need to
> contort the parser into ignoring bits of code that are, in effect,
> syntax checked
> comments. And for the typing in Python enthusiasts, you won't have to listen
> to people like me complaining.
>
> The second approach is to assume that type checking in Python is useful and
> popular. Not with me, but I'm willing to accept that I'm in the minority and 
> can
> be ignored - after all, I can still write my Python code without type
> annotations.
> If so running a type checker as a separate step, as we do at the moment, is
> like asking C programmers to run the preprocessor by hand.
>
> In today's world of continuous build and integration, it seems silly
> to me to have
> a type checker read the source, scan into lexical tokens, build an
> abstract syntax
> tree, perform semantic analysis with type checking, and then throw it away
> before running an interpreter which reads the same source, scans into lexical
> tokens, builds an abstract syntax tree, and executes. On the purely pragmatic
> level there is an extra chance for mismatches and things to go wrong; and from
> an environmental viewpoint it isn't a great use of resources.
>
> --
>
> cheers,
> Hugh Fisher
> ___
> 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/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/
> 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/FAYGAU72I3LJGZRFQNM4UFDGREYYI5WZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

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$
Last-Modified: $Date$
Author: Nick Coghlan , Ethan Furman 
Status: Deferred
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2014
Python-Version: 3.9
Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 2021-04-13


Abstract


During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series.

This PEP proposes five small adjustments to the APIs of the ``bytes`` and
``bytearray`` types to make it easier to operate entirely in the binary domain:

* Discourage passing single integer values to ``bytes`` and ``bytearray``
* Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative constructors
* Add ``bytes.fromord`` and ``bytearray.fromord`` alternative constructors
* Add ``bytes.getbyte`` and ``bytearray.getbyte`` byte retrieval methods
* Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators

And one built-in::

* ``bchr``

PEP Deferral


This PEP has been deferred until Python 3.9 at the earliest, as the open
questions aren't currently expected to be resolved in time for the Python 3.8
feature addition deadline in May 2019 (if you're keen to see these changes
implemented and are willing to drive that resolution process, contact the PEP
authors).

Proposals
=

Discourage use of current "zero-initialised sequence" behaviour
---

Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
argument and interpret it as meaning to create a zero-initialised sequence
of the given size::

>>> bytes(3)
b'\x00\x00\x00'
>>> bytearray(3)
bytearray(b'\x00\x00\x00')

This PEP proposes to update the documentation to discourage making use of that
input type dependent behaviour in Python 3.10, suggesting to use a new, more
explicit, ``bytes.fromsize(n)`` or ``bytearray.fromsize(n)`` spelling instead
(see next section).

However, the current handling of numeric inputs in the default constructors
would remain in place indefinitely to avoid introducing a compatibility break.

No other changes are proposed to the existing constructors.


Addition of explicit "count and byte initialised sequence" constructors
---

To replace the now discouraged behaviour, this PEP proposes the addition of an
explicit ``fromsize`` alternative constructor as a class method on both
``bytes`` and ``bytearray`` whose first argument is the count, and whose
second argument is the fill byte to use (defaults to ``\x00``)::

>>> bytes.fromsize(3)
b'\x00\x00\x00'
>>> bytearray.fromsize(3)
bytearray(b'\x00\x00\x00')
>>> bytes.fromsize(5, b'\x0a')
b'\x0a\x0a\x0a\x0a\x0a'
>>> bytearray.fromsize(5, b'\x0a')
bytearray(b'\x0a\x0a\x0a\x0a\x0a')

``fromsize`` will behave just as the current constructors behave when passed a
single integer, while allowing for non-zero fill values when needed.

Similar to ``str.center``, ``str.ljust``, and ``str.rjust``, both parameters
would be positional-only with no externally visible name.


Addition of "bchr" function and explicit "single byte" constructors
---

As binary counterparts to the text ``chr`` function, this PEP proposes
the addition of a ``bchr`` function and an explicit ``fromord`` alternative
constructor as a class method on both ``bytes`` and ``bytearray``::

>>> bchr(ord("A"))
b'A'
>>> bchr(ord(b"A"))
b'A'
>>> bytes.fromord(65)
b'A'
>>> bytearray.fromord(65)
bytearray(b'A')

These methods will only accept integers in the range 0 to 255 (inclusive)::

>>> bytes.fromord(512)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: integer must be in range(0, 256)

>>> bytes.fromord(1.0)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'float' object cannot be interpreted as an integer

While this does create some duplication, there are valid reasons for it:

* the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio from
  Python 2 under a different naming scheme (however, see the Open Questions
  section below)
* the class method is mainly for the ``bytearray.fromord`` case, with
  ``bytes.fromord`` added for consistency

The documentation of the ``ord`` builtin will be updated to explicitly note
that ``bchr`` is the primary inverse operation for bina

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

[Guido van Rossum]

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 other hand, `1if 2else 3` is accepted despites the fact that "2e" can
> > be recognized as an incomplete floating point number. In this case the
> > tokenizer pushes "e" back and returns "2".
> >
> > Shouldn't it do the same with "0o"? It is possible to make `0or[]` be
> > parseable again. Python implementation is able to tokenize this example:
> >
> > $ echo '0or[]' | ./python -m tokenize
> > 1,0-1,1:NUMBER '0'
> > 1,1-1,3:NAME   'or'
> > 1,3-1,4:OP '['
> > 1,4-1,5:OP ']'
> > 1,5-1,6:NEWLINE'\n'
> > 2,0-2,0:ENDMARKER  ''
> >
> > On other hand, all these examples look weird. There is an assymmetry:
> > `1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
> > visually the boundary between a number and the following identifier or
> > keyword, especially if numbers can contain letters ("b", "e", "j", "o",
> > "x") and underscores, and identifiers can contain digits. On both sides
> > of the boundary can be letters, digits, and underscores.
> >
> > I propose to change the Python syntax by adding a requirement that there
> > should be a whitespace or delimiter between a numeric literal and the
> > following keyword.
> >
>
> 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)].
>
> Since this code is clearly ambiguous, it makes more sense to emit a
> SyntaxWarning if there is no space between number and identifier.
>

I would totally make that a SyntaxError, and backwards compatibility be
damned.

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

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

[Guido van Rossum]

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 an expression.
>
> To be honest, the most pressing issue with annotations is the clumsy way
> that type variables have to be introduced. The current convention, `T =
> TypeVar('T')`, is both verbose (why do I have to repeat the name?) and
> widely misunderstood (many help request for mypy and pyright follow from
> users making a mistaken association between two type variables that are
> unrelated but share the same TypeVar definition). And relaxed annotation
> syntax alone doesn't solve this.
>
> Nevertheless I think that it's time to accept that annotations are for
> types -- the intention of PEP 3107 was to experiment with different syntax
> and semantics for types, and that experiment has resulted in the successful
> adoption of a specific syntax for types that is wildly successful.
>
>
> I don't follow your reasoning.  I'm glad that type hints have found
> success, but I don't see why that implies "and therefore we should restrict
> the use of annotations solely for type hints".  Annotations are a useful,
> general-purpose feature of Python, with legitimate uses besides type
> hints.  Why would it make Python better to restrict their use now?
>

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 whether a particular "blah blah" is
meant as a type or as something else -- because you have to know what's
introspecting the annotations before you can tell. And that introspection
could be signalled by a magical decorator, but it could also be implicit:
maybe you have a driver that calls a function based on a CLI entry point
name, and introspects that function even if it's not decorated.

OTOH, not requiring that annotations are syntactically valid expressions
might liberate such a CLI library too: you could write things like

def foo(prec: --precision int):
...


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

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

[Serhiy Storchaka]

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
> be recognized as an incomplete floating point number. In this case the
> tokenizer pushes "e" back and returns "2".
> 
> Shouldn't it do the same with "0o"? It is possible to make `0or[]` be
> parseable again. Python implementation is able to tokenize this example:
> 
> $ echo '0or[]' | ./python -m tokenize
> 1,0-1,1:    NUMBER '0'
> 1,1-1,3:    NAME   'or'
> 1,3-1,4:    OP '['
> 1,4-1,5:    OP ']'
> 1,5-1,6:    NEWLINE    '\n'
> 2,0-2,0:    ENDMARKER  ''
> 
> On other hand, all these examples look weird. There is an assymmetry:
> `1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
> visually the boundary between a number and the following identifier or
> keyword, especially if numbers can contain letters ("b", "e", "j", "o",
> "x") and underscores, and identifiers can contain digits. On both sides
> of the boundary can be letters, digits, and underscores.
> 
> I propose to change the Python syntax by adding a requirement that there
> should be a whitespace or delimiter between a numeric literal and the
> following keyword.
> 

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

Since this code is clearly ambiguous, it makes more sense to emit a
SyntaxWarning if there is no space between number and identifier.

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

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

[Larry Hastings]

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 annotations is the clumsy 
way that type variables have to be introduced. The current convention, 
`T = TypeVar('T')`, is both verbose (why do I have to repeat the 
name?) and widely misunderstood (many help request for mypy and 
pyright follow from users making a mistaken association between two 
type variables that are unrelated but share the same TypeVar 
definition). And relaxed annotation syntax alone doesn't solve this.


Nevertheless I think that it's time to accept that annotations are for 
types -- the intention of PEP 3107 was to experiment with different 
syntax and semantics for types, and that experiment has resulted in 
the successful adoption of a specific syntax for types that is wildly 
successful.



I don't follow your reasoning.  I'm glad that type hints have found 
success, but I don't see why that implies "and therefore we should 
restrict the use of annotations solely for type hints". Annotations are 
a useful, general-purpose feature of Python, with legitimate uses 
besides type hints.  Why would it make Python better to restrict their 
use now?



//arry/

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

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

[Guido van Rossum]

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
> > syntax"), not to try and make it available as an expression.
>
> Then, what's wrong with quoting? It's just 2 characters, and prevent the
> user (or their IDE) from trying to parse them as Python syntax.
>

Informal user research has shown high resistance to quoting.


> As a comparison: docstrings do get quoting, even though they also have
> special semantics in the language.
>

Not the same thing. Docstrings use English, which has no formal (enough)
syntax. The idea for annotations is that they *do* have a formal syntax, it
just evolves separately from that of Python itself.

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

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

[Filipe Laíns]

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 strongly typed.  Its typing is
> just dynamic and isn't explicitly spelled in most syntax.
> 
> Regards
> 
> Antoine.

Yes, of course. I built on on the context to avoid being overly pedantic.

Cheers,
Filipe Laíns


signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JP7LW7L7PGFXQHHTRW6SO5F26SWVAEMM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Carl Meyer via Python-Dev]

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 
improvement.  As the Zen says: "Errors should never pass silently."

This is really the heart of the debate over PEP 649 vs PEP 563.  If you 
examine an annotation, and it references an undefined symbol, should that throw 
an error?  There is definitely a contingent of people who say "no, that's 
inconvenient for us".  I think it should raise an error.  Again from the Zen: 
"Special cases aren't special enough to break the rules."  Annotations are 
expressions, and if evaluating an expression fails because of an undefined 
name, it should raise a NameError.

Normally in Python, if you reference a symbol in a function definition line, 
the symbol must be defined at that point in module execution. Forward 
references are not permitted, and will raise `NameError`.

And yet you have implemented PEP 649, whose entire raison d'être is to 
implement a "special case" to "break the rules" by delaying evaluation of 
annotations such that a type annotation, unlike any other expression in the 
function definition line, may include forward reference names which will not be 
defined until later in the module.

The use case for `if TYPE_CHECKING` imports is effectively the same. They are 
just forward references to names in other modules which can't be imported 
eagerly, because e.g. it would cause a cycle. Those who have used type 
annotations in earnest are likely to confirm that such inter-module forward 
references are just as necessary as intra-module forward references for the 
usability of type annotations.

So it doesn't seem that we have here is a firm stand on principle of the Zen, 
it appears to rather be a disagreement about exactly where to draw the line on 
the "special case" that we all already seem to agree is needed.

The Zen argument seems to be a bit of a circular one: I have defined PEP 649 
semantics in precisely this way, therefore code that works with PEP 649 does 
not have an error, and code that does not work with PEP 649 "has an error" 
which must be surfaced!

With PEP 563, although `get_type_hints()` cannot natively resolve inter-module 
forward references and raises `NameError`, it is possible to work around this 
by supplying a globals dict to `get_type_hints()` that has been augmented with 
those forward-referenced names. Under the current version of PEP 649, it 
becomes impossible to get access to such type annotations at runtime at all, 
without reverting to manually stringifying the annotation and then using 
something like `get_type_hints()`. So for users of type annotations who need 
`if TYPE_CHECKING` (which I think is most users of type annotations), the 
best-case overall effect of PEP 649 will be that a) some type annotations have 
to go back to being ugly strings in the source, and b) if type annotation 
values are needed at runtime, `get_type_hints()` will still be as necessary as 
it ever was.

It is possible for PEP 649 to draw the line differently and support both 
intra-module and inter-module forward references in annotations, by doing 
something like https://github.com/larryhastings/co_annotations/pull/3 and 
replacing unknown names with forward-reference markers, so the annotation 
values are still accessible at runtime. This meets the real needs of users of 
type annotations better, and gives up none of the benefits of PEP 649.

Carl



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

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

[Baptiste Carvello]

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 annotation function is being defined inside
>   a class scope.
> * The generated code for the annotation function
>   has at least one ``LOAD_NAME`` instruction.

I'm afraid I don't really understand the second condition. Would it be
possible to rephrase it in a less technical way, i.e. some condition on
the user code itself, not on what the implementation does with it.

* in section "Interactive REPL Shell":

> For the sake of simplicity, in this case we forego delayed evaluation.

This has the unpleasant consequence that any code using forward
references cannot be copy-pasted into the REPL. While such copy-pasting
is a very casual practice and does already often break, it is sometimes
useful in quick'n dirty prototyping. Would it be possible to specify
that in this case, a possible NameError in evaluation is caught, and the
annotation is set to None or some sentinel value?

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

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

[Baptiste Carvello]

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? It's just 2 characters, and prevent the
user (or their IDE) from trying to parse them as Python syntax.

As a comparison: docstrings do get quoting, even though they also have
special semantics in the language.

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

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

[Stéfane Fermigier]

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 what I consider reasonable. I do not
> believe other programmers with experience in typed languages
> would expect this behaviour either.
>

I have 30 years experience in other programming languages (C, C++, Pascal,
Java...) and I'm OK with this behaviour :)

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, both
from an academic and industrial point of view, and similar (with some
variants) to what has been done also for JavaScript, Ruby, PHP, Lua, Perl,
Scheme, etc. over the same period.

See for instance
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.683.8854&rep=rep1&type=pdf
for more references.


> If typing is the future of Python, and the number of PEPs being
> worked on suggests that it is, then type checking should be
> integrated into CPython itself.
>

No need to integrate in CPython, one can already provide runtime type
checking using the current language, see e.g.
https://pypi.org/project/typeguard/


> An alternative is the TypeScript/JavaScript model, where typed
> Python becomes a distinct programming language that cannot
> be executed directly by the Python interpreter.
>

There are a few compile-to-Python languages out there (See a list here:
https://github.com/sfermigier/awesome-functional-python#languages ), some
with desirable (for some people at least) characteristics (homoiconic
syntax, language-level support for actors and functional programming,
pattern matching, etc.). They have very limited success in terms of
adoption which is probably a lesson to keep in mind.

  S.


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
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/7TZPJ6F7W6LLWKRQIFP3EWFW4SYBY2XT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ned Batchelder]

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 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 runs the program but does not check
   the types. In C/C++, this is running the executable, in Python it is
   "python".

In Python, we can skip the first step, and perhaps that is the source of 
your concern.  I doubt anyone that has adopted type hinting in Python 
will forget to run mypy, especially in a CI environment like you consider.


--Ned.

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

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

[Stephen J. Turnbull]

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 typing, you've programmed in one other
language. ;-)  (Maybe Go makes two, I haven't used it.)  They all
demand that variables be declared with types, and then proceed to fill
them with bit patterns that can't be introspected (unless you build it
in to class definitions yourself).

Python's different approach is a compromise.  And as usual Guido's
time machine (or somebody borrowed it) is in evidence: if that example
bothers you, request that people around you who type things like that
use stub files instead so you don't have to deal with it.

If, on the other hand, you want explicitly typed variables (and not
just "if we must have types, I want them integrated", I think you'll
have a serious fight on your hands.  It's often quite useful to me,
for one, that names are not typed while objects are.

 > Having a type checker run before the Python interpreter in our
 > current day continuous build/integration environment adds a
 > second step and therefore the chance for it to be forgotten, for
 > version mismatches, for warning/error reports to be misdirected.

This is a good point, but having an explicitly typed language would
mean I can't really use Python at work (that is, I can't recommend it
to my business and economics students, who don't program, really, they
record scripts).

 > From an environmental point of view we're also doing the read
 > source, lexical scan, syntax parse twice rather than once.

This is not true.  Most programs, *especially* programs that are
complex enough to want type-checking, are run far more often than they
are type-checked.

 > If typing is the future of Python, and the number of PEPs being
 > worked on suggests that it is, then type checking should be
 > integrated into CPython itself.

I don't see it as *the* future of Python.

And I don't really see why it should be integrated into CPython.  To
me it seems to be a language facility, not an implementation facility.
Integrating it with CPython would likely result in disintegrating it
from PyPy and other implementations.  I don't think that is desirable
at all -- the version skew you mentioned would likely occur here.

I like to think of it as "Python typing has some warts, but that's
because it will turn out to be a prince(ss) when you kiss it."  

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

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

[Antoine Pitrou]

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 in most syntax.

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