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

On Wed, Apr 14, 2021 at 12:10 PM Barry Warsaw wrote: I’d forgotten that this PEP was in Deferred state. I think it should be > rejected and I plan on making that change. importlib.metadata is a much > better approach to programmatically determining package versions. > > > https://docs.python.or

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

On Thu, Apr 15, 2021 at 2:36 PM Hugh Fisher wrote: > > > Date: Wed, 14 Apr 2021 09:57:49 +1000 > > From: Chris Angelico > > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2 > > > > > You're advocating an approach that absolutely mandates running the > > type checker, but then caches

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

> Date: Wed, 14 Apr 2021 09:57:49 +1000 > From: Chris Angelico > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2 > > 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

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

Hugh Fisher writes: > 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. That's not very persuasive. When in London, England,

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

On Thu, Apr 15, 2021 at 11:09 AM Larry Hastings wrote: > > Thanks for doing this! I don't think PEP 649 is going to be accepted or > rejected based on either performance or memory usage, but it's nice to see > you confirmed that its performance and memory impact is acceptable. > > > If I run "a

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

Thanks for doing this!  I don't think PEP 649 is going to be accepted or rejected based on either performance or memory usage, but it's nice to see you confirmed that its performance and memory impact is acceptable. If I run "ann_test.py 1", the annotations are already turned into strings.

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

On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett wrote: > I don't have a deep answer, but I do think __version__ should be specified > (or at least mentioned) at > https://docs.python.org/3/reference/datamodel.html Given the intent to reject PEP 394, I can't imagine any good would come of that. D

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

I added memory usage data by tracemalloc. ``` # Python 3.9 w/ old semantics $ python3 ann_test.py 1 code size: 121011 memory: (385200, 385200) unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05 exec: avg: 0.4067857594229281 +/- 0.0006858555167675445 # Python 3.9 w/ PEP 563 semantics $ p

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

I created simple benchmark: https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d This benchmark creates 1000 annotated functions and measure time to load and exec. And here is the result. All interpreters are built without --pydebug, --enable-optimization, and --with-lto. ``` # Python

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

Larry Hastings wrote: > On 4/14/21 1:42 PM, Baptiste Carvello wrote: > > Are there specific annoyances associated with quoting always, apart > > from the 2 more characters? > Yes.  Since the quoted strings aren't parsed by Python, syntax errors in > these strings go undetected until somebody doe

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

Baptiste Carvello wrote: > Le 14/04/2021 à 19:44, Guido van Rossum a écrit : > > No, what I heard is that, since in *most* cases the string quotes are > > not needed, people are surprised and annoyed when they encounter cases > > where they are needed. > Well, I had assumed quotes would be used i

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

https://docs.python.org/3/reference/datamodel.html On Wed, 2021-04-14 at 22:56 +, Jim J. Jewett wrote: > Paul Moore wrote: > > What's wrong with Version(module.__version__)? And if the > > __version__ > > attribute isn't a valid version, raise an exception? > > I don't have a deep answer, but

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

Paul Moore wrote: > What's wrong with Version(module.__version__)? And if the __version__ > attribute isn't a valid version, raise an exception? I don't have a deep answer, but I do think __version__ should be specified (or at least mentioned) at https://docs.python.org/3/reference/datamodel.html

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

Seems like this is something that should make its way into stdlib? On Thu, 2021-04-15 at 00:15 +0200, Antoine Pitrou wrote: > On Wed, 14 Apr 2021 22:23:44 +0100 > Paul Moore wrote: > > On Wed, 14 Apr 2021 at 21:59, David Mertz wrote: > > > > > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore > > >

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On 4/14/2021 8:00 AM, Joachim Wuttke wrote: Furthermore, if policy about API changes allows, I'd suggest that `NO_TIMESTAMP` become the new default value for `mtime`. Changing defaults is a huge pain, which we mostly avoid. -- Terry Jan Reedy ___

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Wed, 14 Apr 2021 21:38:11 +0100 Steve Holden wrote: > DEFAULT_TIMESTAMP? It's not a default timestamp, it's a placeholder value meaning "no timestamp". The aforementioned RFC 1952 explicitly says: "MTIME = 0 means no time stamp is available". So yes, it really means "no timestamp", regardles

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

On Wed, 14 Apr 2021 22:23:44 +0100 Paul Moore wrote: > On Wed, 14 Apr 2021 at 21:59, David Mertz wrote: > > > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: > >> > >> If it's not basically equivalent to packaging.version.Version (and > >> based on PEP 440) then we'll be creating a nightma

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

On Wed, 14 Apr 2021 at 21:59, David Mertz wrote: > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: >> >> If it's not basically equivalent to packaging.version.Version (and >> based on PEP 440) then we'll be creating a nightmare of confusion, >> because PEP 440 versions are fundamental to pack

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

On 4/14/21 1:42 PM, Baptiste Carvello wrote: Are there specific annoyances associated with quoting always, apart from the 2 more characters? Yes.  Since the quoted strings aren't parsed by Python, syntax errors in these strings go undetected until somebody does parse them (e.g. your static t

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

On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote: > That's assuming the syntax in the annotations doesn't diverge too > much > from the Python syntax as far as brackets etc are concerned. I must > say > I'm not too worried about typing. But the hypothetic "def foo(prec: > --precision int

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

On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: > If it's not basically equivalent to packaging.version.Version (and > based on PEP 440) then we'll be creating a nightmare of confusion, > because PEP 440 versions are fundamental to packaging. > Are you suggesting that users should have to inst

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

On Wed, Apr 14, 2021 at 4:19 PM Paul Moore wrote: > PS I see Barry plans on rejecting the PEP, which I think is probably > the right decision, given the way this thread has developed. > Barry makes good plans. Putting the version into the sources is a bit of an anti-pattern. IMO. -Fred --

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

Hi, Le 14/04/2021 à 19:44, Guido van Rossum a écrit : > > No, what I heard is that, since in *most* cases the string quotes are > not needed, people are surprised and annoyed when they encounter cases > where they are needed. And if you have a large code base it takes an > expensive run of the st

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

DEFAULT_TIMESTAMP? Kind regards, Steve On Wed, Apr 14, 2021 at 8:03 PM wrote: > If the so, then a better name than NO_TIMESTAMP should be chosen, as the > gzip specification does not allow for no timestamp. > ___ > Python-Dev mailing list -- python-d

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

On Wed, 14 Apr 2021 at 18:04, Eric V. Smith wrote: >> Anyway, the question now for me is whether this is worth any more of my time. >> >> So: >> - Is there someone willing to sponsor? >> - Do folks generally think there's a chance of it being accepted without a >> huge debate and expansion of sco

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

On Wed, 14 Apr 2021 at 18:01, David Mertz wrote: > > On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker > wrote: >> >> Another possible issue: using Version would require an extra import in many >> module initializations -- is that a performance issue that would matter? > > > I like having a `V

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

Hi Larry, On 4/14/21, 1:56 PM, "Larry Hastings" wrote: >My plan was to post it here and see what the response was first. Back in > January, when I posted the first draft, I got some very useful feedback that > resulted in some dramatic changes. This time around, so far, nobody has > su

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

My plan was to post it here and see what the response was first. Back in January, when I posted the first draft, I got some very useful feedback that resulted in some dramatic changes.  This time around, so far, nobody has suggested even minor changes.  Folks have just expressed their opinion

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

On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum wrote: > Let's just wait for the SC to join the discussion. I'm sure they will, > eventually. > FYI the PEP has not been sent to us via https://github.com/python/steering-council/issues as ready for pronouncement, so we have not started officiall

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

On Apr 13, 2021, at 22:40, Christopher Barker wrote: > > Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago! > > https://www.python.org/dev/peps/pep-0396/ I’d forgotten that this PEP was in Deferred state. I think it should be rejected and I plan on making that change

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

Let's just wait for the SC to join the discussion. I'm sure they will, eventually. On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings wrote: > On 4/14/21 10:44 AM, Guido van Rossum wrote: > > besides the cost of closing the door to relaxed annotation syntax, there's > the engineering work of undoin

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

On Wed, Apr 14, 2021 at 11:03 AM Paul Bryan wrote: > What would you expect get_type_hints(...) to return with relaxed syntax? > Today, for type hint annotations, it returns a type, which I'd argue is an > important feature to preserve (in it or some successor). > It would have to return some oth

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

If the so, then a better name than NO_TIMESTAMP should be chosen, as the gzip specification does not allow for no timestamp. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.pyt

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Wed, 2021-04-14 at 18:06 +, j.wut...@fz-juelich.de wrote: > The gzip specification [1] makes clear that the mtime field is always present. > The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. > MTIME = 0 means no time stamp is available. Hence no need for a > new co

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

The gzip specification [1] makes clear that the mtime field is always present. The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. MTIME = 0 means no time stamp is available. Hence no need for a new constant NO_TIMESTAMP. So this is primarily a documentation problem [2]. F

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

On 4/14/21 10:44 AM, Guido van Rossum wrote: besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits,

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

What would you expect get_type_hints(...) to return with relaxed syntax? Today, for type hint annotations, it returns a type, which I'd argue is an important feature to preserve (in it or some successor). On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote: > On Wed, Apr 14, 2021 at 10:47 AM

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

On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan wrote: > I favour annotations for type hints; the writing's been on the wall for > some time. I think the necessary escape hatch for those using it for other > purposes should be Annotated[Any, ...] (or a similar, nicer alternative). > > Guido, one of t

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

I favour annotations for type hints; the writing's been on the wall for some time. I think the necessary escape hatch for those using it for other purposes should be Annotated[Any, ...] (or a similar, nicer alternative). Guido, one of the difficulties I'm having is understanding the direction you'

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

On Wed, Apr 14, 2021 at 9:42 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hi, > > tl;dr: imho the like or dislike of PEP 563 is related to whether people > intend to learn a second syntax for typing, or would rather ignore it; > both groups should be taken into account. > > Le

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

On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki wrote: > 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 bl

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

On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings wrote: > > 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 >>

[Python-Dev] Re: Typing syntax and ecosystem

> Date: Wed, 14 Apr 2021 11:24:12 +0200 > From: Antoine Pitrou > Subject: [Python-Dev] Re: Typing syntax and ecosystem > > Can you explain why you think C++ typing is based on structural > equivalence? I'd rather not have a detailed discussion of C++ typing on python-dev. My example was Ada styl

[Python-Dev] Re: Typing syntax and ecosystem

On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher wrote: > 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

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

Hi, gzip.NO_TIMESTAMP sounds like a good idea. But I'm not sure about changing the default behavior. I would prefer to leave it unchanged. I guess that your problem is that you don't access gzip directly, but uses a higher level API which doesn't give access to the timestamp parameter, like the t

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

> > Date: Tue, 13 Apr 2021 19:55:38 -0400 > From: Ned Batchelder > > 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 > avoidin

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

On Wed, Apr 14, 2021 at 5:00 AM Joachim Wuttke wrote: > gzip compression, using class GzipFile from gzip.py, by default > inserts a timestamp to the compressed stream. If the optional > argument `mtime` is absent or None, then the current time is used [1]. > > This makes outputs non-deterministic

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

On 4/14/2021 12:38 PM, Christopher Barker wrote: Anyway, the question now for me is whether this is worth any more of my time. So: - Is there someone willing to sponsor? - Do folks generally think there's a chance of it being accepted without a huge debate and expansion of scope. I think

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

On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker wrote: > Another possible issue: using Version would require an extra import in > many module initializations -- is that a performance issue that would > matter? > I like having a `Version` object that is easily importable in the standard librar

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

On Wed, Apr 14, 2021 at 5:24 AM Victor Stinner wrote: > There are two main use cases for versions: > > * Display them to the user > * Compare versions to check if one is newer, older or the same > > I dislike using strings for comparison. You need to use > packaging.version for that: > https://pa

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

Hi, tl;dr: imho the like or dislike of PEP 563 is related to whether people intend to learn a second syntax for typing, or would rather ignore it; both groups should be taken into account. Le 13/04/2021 à 19:30, Guido van Rossum a écrit : > On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello >

[Python-Dev] gzip.py: allow deterministic compression (without time stamp)

gzip compression, using class GzipFile from gzip.py, by default inserts a timestamp to the compressed stream. If the optional argument `mtime` is absent or None, then the current time is used [1]. This makes outputs non-deterministic, which can badly confuse unsuspecting users: If you run "diff"

[Python-Dev] Re: Typing syntax and ecosystem

I agree that showing support for type hints is important, as long as this doesn't convey the counterproductive message that type hints have become almost mandatory. They are useful in some circumstances, and less so (specially when dealing with beginners or non-professional programmers) in others.

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

Agreed! I was trying to figure out why an API from Vaex 3.x was no longer working, and to my human eye, this quickly pointed me at the issue. However as a way to automatically check for versions, this is a mess. I have no idea what additional keys the next version might add or remove, for exampl

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

Simon, I'm not sure your note made it to the list -- bringing it back on. On Wed, Apr 14, 2021 at 1:15 AM Simon Cross wrote: > I would be +1 on having a small PEP like this one to give __version__ > an official blessing and some well-defined expected behaviour. > > I don't have a deep opinion o

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

On Wed, Apr 14, 2021 at 7:48 AM David Mertz wrote: > >>> vaex.__version__ > {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': > '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': > '0.6.0', 'vaex-ml': '0.11.1'} > Well, THAT is a great argument for som

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

I recently encountered this, which is very useful, but only for a human-readable perspective. >>> import vaex >>> vaex.__version__ {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter': '0.6.0', 'vaex-ml': '

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

On 14/04/2021 2:20 am, Inada Naoki wrote: 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_op

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

On 4/12/21 7:24 PM, Guido van Rossum wrote: 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 re

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

It looks like a small subset of PEP 484, syntactically. So it should be fine. Possibly cython might be interested in using a relaxed notation if it is ever introduced, e.g. ‘long long’ or ‘static int’ (for a return type)? On Wed, Apr 14, 2021 at 02:27 Antoine Pitrou wrote: > > For the record, Cy

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

On 4/13/21 6:20 PM, Inada Naoki wrote: Then, does anyone oppose this change? Having staticmethod, etc., be callable would make my code much easier in at least two different projects. Please make this change. -- ~Ethan~ ___ Python-Dev mailing list

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

> In my Python projects, I like to provide the version as a tuple which > can be used directly for comparison To add to this, comparing tuples doesn't always work well for projects where multiple release lines are maintained simultaneously, e.g. user-facing changes introduced in minor/point releas

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

On Wed, 14 Apr 2021 at 13:28, Victor Stinner wrote: > There are two main use cases for versions: > > * Display them to the user > * Compare versions to check if one is newer, older or the same > > I dislike using strings for comparison. You need to use > packaging.version for that: > https://packa

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

On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker wrote: > So what do you'all think? After thirteen years, it would be nice to put this > to bed. There are two main use cases for versions: * Display them to the user * Compare versions to check if one is newer, older or the same I dislike usin

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

Also, would it be possible to enhance to tokenizer to report a SyntaxWarning, rather than a SyntaxError? Victor ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailm

[Python-Dev] Re: 0xfor 3. Parser bug?

14.04.21 13:22, Stefano Borini пише: > This was just posted on SO > > https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3 > > I can reproduce it with a simpler example > 0xfor 3 > 15 > > Is it a bug in the parser, or working as intended? It's not onl

[Python-Dev] 0xfor 3. Parser bug?

This was just posted on SO https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3 I can reproduce it with a simpler example >>> 0xfor 3 15 Is it a bug in the parser, or working as intended? It's not only for hex. This works to >>> 3or 50 3 -- Kind regar

[Python-Dev] Re: Typing syntax and ecosystem

On Wed, 14 Apr 2021 10:12:19 +1000 Hugh Fisher wrote: > > 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]

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

For the record, Cython allows using annotations for typing: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations I don't know if they are fully compatible with the type hints we're talking about here. Regards Antoine. On Wed, 14 Apr 2021 10:58:07 +0900 Inad