[issue43918] anext builtin docstring has no signature text or info about default argument

[Erik Welch]

Erik Welch  added the comment:

Thanks for taking a look Terry.  I saw that error as well.  It is separate from 
this issue, and I don't think it is a bug.  No other builtin functions or 
methods that raise this error with this text have such a notice in their 
docstring, so it doesn't seem appropriate to me to add it to the docstring at 
this point in time.

Search for "" to find other functions and methods that have 
the same issue.  `dict.pop` is one such example.

`inspect.signature(anext)` and `inspect.signature(next)` both raise ValueError. 
 The text for `next` is what one may hope to see (and why you raise a fair 
point): `"ValueError: no signature found for builtin "`.  The difference between `anext` and `next` in this regard is that 
`anext` uses the argument clinic.  It is the argument clinic that converts 
`NULL` to `""` in the signature text that inspect tries (and 
fails) to parse to get the AST of.

I actually did poke around a bit at having the the Argument Clinic and 
`inspect` module more intelligently pick up this case to give a better error.  
I think this is doable, but should not be part of this bug report.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14965] super() and property inheritance behavior

[Victor Milovanov]

Victor Milovanov  added the comment:

There's a patch attached to this bug. Why is its stage "needs patch"?

--
nosy: +Victor Milovanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Ammar Askar]

Ammar Askar  added the comment:

For what it's worth I think Brett's suggestion of just removing the coverage 
build entirely is good too since it seems like no one actually looks at the 
results and they take up valuable CI time.

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

Coverage runs are still failing on the master, and I think at least we should 
do something like allow failure or other wise github will send notifications 
for this flaky run.

--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[Aritn Sarraf]

Aritn Sarraf  added the comment:

Understood. Thanks both, for taking the time to look.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38530] Offer suggestions on AttributeError and NameError

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I opened PR 25584 to fix this current behavior:

>>> v
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'v' is not defined. Did you mean: 'id'?
>>> vv
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'vv' is not defined. Did you mean: 'id'?
>>> vvv
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'vvv' is not defined. Did you mean: 'abs'?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38530] Offer suggestions on AttributeError and NameError

[Dennis Sweeney]

Change by Dennis Sweeney :


--
nosy: +Dennis Sweeney
nosy_count: 8.0 -> 9.0
pull_requests: +24304
pull_request: https://github.com/python/cpython/pull/25584

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42737] PEP 563: drop annotations for complex assign targets

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

Ah, seems like there is still one open PR. Keeping this up for that...

--
resolution: postponed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42737] PEP 563: drop annotations for complex assign targets

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
resolution:  -> postponed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42725] PEP 563: Should the behavior change for yield/yield from's

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
keywords: +patch
pull_requests: +24303
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25583

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42737] PEP 563: drop annotations for complex assign targets

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:


New changeset 8cc3cfa8afab1651c4f6e9ba43a7ab7f10f64c32 by Batuhan Taskaya in 
branch 'master':
bpo-42737: annotations with complex targets no longer causes any runtime 
effects (GH-23952)
https://github.com/python/cpython/commit/8cc3cfa8afab1651c4f6e9ba43a7ab7f10f64c32


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43874] argparse crashes on subparsers with no dest/metava

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Wait for responses

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43925] Add hangul syllables to unicodedata.decomposititon

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I verified the claim in 3.19.0a7 freshly compiled today.

>>> import unicodedata as ud
>>> ud.decomposition('\uac00')
''
>>> for cp in range(0xac00, 0xd7a4):
if (s := ud.decomposition(chr(cp))) != '':
print(cp, s)

>>>

--
nosy: +terry.reedy
type:  -> enhancement
versions: +Python 3.11 -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43889] Pickle performance regression in 3.10

[Ken Jin]

Ken Jin  added the comment:

I'm unable to reproduce the regression locally with pyperformance. 
Additionally, the links on speed.python.org show that the results returned to 
normal after a week (again seemingly without any commit to cause such a change).

I'm closing this bug as it doesn't seem related to the code in cpython itself. 
Thanks everyone.

-

$ pyperf compare_to 2021-04-13_23-59-master-11159d2c9d66.json.gz 
2021-04-14_23-03-master-3fc65b97d09f.json.gz  
pickle_dict: Mean +- std dev: [2021-04-13_23-59-master-11159d2c9d66] 72.0 us +- 
1.6 us -> [2021-04-14_23-03-master-3fc65b97d09f] 73.1 us +- 0.9 us: 1.02x slower
pickle_list: Mean +- std dev: [2021-04-13_23-59-master-11159d2c9d66] 11.1 us +- 
0.1 us -> [2021-04-14_23-03-master-3fc65b97d09f] 11.0 us +- 0.1 us: 1.01x faster

Benchmark hidden because not significant (1): pickle

Geometric mean: 1.00x slower

--
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43918] anext builtin docstring has no signature text or info about default argument

[Terry J. Reedy]

Terry J. Reedy  added the comment:

inspect.signature(anext) raises "ValueError:  builtin 
has invalid signature".  Guido, is this a bug?  Even if not, docstring should 
have it.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43754] Eliminate bindings for partial pattern matches

[Brandt Bucher]

Brandt Bucher  added the comment:

Since the feature freeze is coming up (and this changes the bytecode), I'd like 
to open this up for review now.

It probably shouldn't actually be merged before the AST changes in issue 43892, 
though. There will be quite a few conflicts that need resolving, but I'd rather 
integrate the AST changes into this PR than force Nick to integrate these 
deeper changes into his branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28874] test_logging fails and freezes

[wim glenn]

wim glenn  added the comment:

I was seeing this problem when building 3.6.4. Fixed it by replacing the test 
cert with a newer one from 3.6.13:

curl 
https://raw.githubusercontent.com/python/cpython/v3.6.13/Lib/test/keycert.pem > 
./Lib/test/keycert.pem

Hope this helps someone else one day..

--
nosy: +wim.glenn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Guido van Rossum]

Guido van Rossum  added the comment:

I think "no user-visible changes" is a pipe dream. Deleting __annotations__ 
seems fairly pointless so I don't mind changes that are only visible when you 
do that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Larry Hastings]

Larry Hastings  added the comment:

> Functions don't store __annotations__ in their __dict__, it is a
> separate slot named func_annotations (see funcobject.c). I guess
> that's because the __dict__ is purely for user-defined function
> attributes.

I brought up functions because I'm now proposing to make classes and modules 
behave more like functions in this one way, that they too will now lazy-create 
an empty annotations dict every time.  But yes, function objects don't store 
__annotations__ in their __dict__, and best practices for 3.9 and before was to 
use fn.__annotations__ or getattr() when getting the annotations from a 
function object, and 3.10 will not change that best practice.

I don't know specifically why the implementor made that design choice, but I 
might have done that too.  Most function objects don't have a __dict__ so this 
is almost always cheaper overall.  And recreating the dict seems harmless.

(Just to round the bases on this topic: I don't think you should be permitted 
to delete __annotations__, like most other metadata items on functions / 
classes / modules.  But I don't propose to change that for 3.10.)


> So if you look in __dict__ it will be like it's still Python 3.9,
> but if you're using the attribute (the recommended approach for code
> that only cares about 3.10) it'll be as if it always existed. Sounds
> pretty compatible to me.

Yes, exactly.  That was the thing I finally figured out this afternoon.  Sorry 
for being a slow learner.

Again, this approach will change the semantics around deleting annotations on 
class and module objects.  Deleting them won't be permanent--if you delete one, 
then ask for it, a fresh one will be created.  But that seems harmless.


> So, honestly I don't understand what your concern with the lazy
> approach is. Was your design based on having a bit in the
> class/module object (outside its __dict__) saying "I already
> lazily created one"? Or am I missing something?

My concern is that always lazy-creating on demand will change user-visible 
behavior.  Consider this code:

class C:
a:int=3

del C.__annotations__
print(C.__annotations__)

In 3.9, that throws an AttributeError, because C no longer has an 
'__annotations__' attribute.  If I change Python 3.10 so that classes and 
modules *always* lazy-create __annotations__ if they don't have them, then this 
code will succeed and print an empty dict.

That's a user-visible change, and I was hoping to avoid those entirely.  Is it 
a breaking change?  I doubt it.  Is it an important change?  It doesn't seem 
like it.  I bring it up just in the interests of considering every angle.  But 
I don't think this is important at all, and I think always lazy-creating 
annotations dicts on classes and modules is the right approach.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43864] [Windows] test_importlib logs: DeprecationWarning: WindowsRegistryFinder.find_module() is deprecated and slated for removal in Python 3.12; use find_spec() instead

[Brett Cannon]

Change by Brett Cannon :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43762] Add audit events for loading of sqlite3 extensions

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Maybe it's better to send the event only if the connection succeeded:

diff --git a/Modules/_sqlite/module.c b/Modules/_sqlite/module.c
index 8dbfa7b38a..0220978cf2 100644
--- a/Modules/_sqlite/module.c
+++ b/Modules/_sqlite/module.c
@@ -97,6 +97,12 @@ static PyObject* module_connect(PyObject* self, PyObject* 
args, PyObject*
 
 result = PyObject_Call(factory, args, kwargs);
 
+if (result) {
+if (PySys_Audit("sqlite3.connected", "O", self) < 0) {
+return -1;
+}
+}
+
 return result;
 }

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43762] Add audit events for loading of sqlite3 extensions

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Something like the attached patch, if I understand you correctly?

--
Added file: https://bugs.python.org/file49982/patch.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43762] Add audit events for loading of sqlite3 extensions

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Good question. sqlite3_load_extension() loads an extension into a database 
connection, so it would make sense to also pass the connection object. I'd say 
we do it; it's a small change, and as you say: if we wanted to add it later, we 
couldn't.

Ref.
- http://www.sqlite.org/c3ref/load_extension.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Guido van Rossum]

Guido van Rossum  added the comment:

So, honestly I don't understand what your concern with the lazy approach is. 
Was your design based on having a bit in the class/module object (outside its 
__dict__) saying "I already lazily created one"? Or am I missing something?

Also, I'll stop going on about "best practice".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Guido van Rossum]

Guido van Rossum  added the comment:

Functions don't store __annotations__ in their __dict__, it is a separate slot 
named func_annotations (see funcobject.c). I guess that's because the __dict__ 
is purely for user-defined function attributes.

But perhaps for classes the C equivalent of this pseudo-code will work?

@property
def __annotations__(self):
if "__annotations__" not in self.__dict__:
self.__dict__["__annotations__"] = {}
return self.__dict__["__annotations__"]

The whole thing is protected by the GIL of course, so there's no race condition 
between the check and the assignment.

So if you look in __dict__ it will be like it's still Python 3.9, but if you're 
using the attribute (the recommended approach for code that only cares about 
3.10) it'll be as if it always existed. Sounds pretty compatible to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Steven is right that this would be a behavior change.  It is also out of line 
with Python norms where all objects are born true and have to learn to be false 
with either __len__ or __bool__.  It is not a norm for bool(obj) to raise an 
exception.

Following Steven's suggestion, I'll mark this a closed.

Thank for the suggestion.

--
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Larry Hastings]

Larry Hastings  added the comment:

Hmm.  Sorry for the stream-of-consciousness thought process here, but this 
approach adds wrinkles too.

Function objects from the very beginning have lazy-created their annotations 
dict if it's not set.  Which means this works fine:

while True:
del fn.__annotations__
print(fn.__annotations__)

You can do that all day.  The function object will *always* create a new 
annotations object if it doesn't have one.  del fn.__annotations__ always 
works, and accessing fn.__annotations__ always succeeds.  It doesn't retain any 
state of "I already lazily created one, I shouldn't create another".

If I add getsets to classes and modules so they lazy-create annotations on 
demand if they otherwise aren't set, then either a) they need an extra bit set 
somewhere that says "I lazily created an empty annotations dict once, I 
shouldn't do it again", or b) they will duplicate this behavior that functions 
display.

a) would better emulate existing semantics; b) would definitely be a 
user-visible breaking change.  There's actually a test in the 
Lib/test/test_opcodes (iirc) that explicitly tests deleting __annotations__, 
then checks that modifying the annotations dict throws an exception.  I haven't 
done any investigating to see if this check was the result of a regression, and 
there was a bpo issue, and there was a valid use case, etc etc etc.

My instinct is that deleting o.__annotations__ is not an important or 
widely-used use case.  In fact I plan to recommend against it in my "best 
practices" documentation.  So either approach should be acceptable.  Which 
means I should go with the simpler one, the one that will duplicate the 
function object's always-recreate-annotations-dicts behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43908] array.array should remain immutable

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

> Does the test suite pass for apply-to-all.diff?

No, multiple tests fail. First test_distutils fails, then during the re-run, 
test_multiprocessing_forkserver, test_multiprocessing_spawn, and test_pdb fail.

> Also, quite a hornet's nest you've uncovered (about __class__ assignment).

Yes, indeed. Apropos, I see that bpo-24991 is still open.

> Would that be fixed better with the IMMUTABLE flag?

That would be a change of functionality, given that we apply the immutable flag 
to all built-in types. Currently __class__ assignment is allowed for heap 
types, and it has been so for many years.

I feel reluctant to add apply-to-all.diff to the PR right now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

[Larry Hastings]

Change by Larry Hastings :


--
title: Add an empty annotations dict to all unannotated classes and modules -> 
Lazy-create an empty annotations dict in all unannotated user classes and 
modules

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Larry Hastings]

Larry Hastings  added the comment:

And I just had a realization.  Lazy creation of an empty annotations dict, 
for both classes and modules, will work fine.

As stated in my previous comment in this issue, my goal here is to improve best 
practices in 3.10+, while preserving the unfortunate best practices of 3.9 and 
before.  I don't know why I couldn't see it before, but: adding a getset to 
modules and user classes, and lazily creating the empty annotations dict if not 
set, ought to work fine.  The getset code will have to store the annotations 
dict in the class / module dict but that's not a big deal.

If you're in 3.10+, and your code looks in the class dict for annotations, and 
we lazy-create it with a getset and store it in the class dict, then you still 
see what you expected to see.

* If the class has annotations, they'll be in the class dict.
* If the class has no annotations, but someone accessed
  cls.__annotations__, the empty dict will be lazily created
  and you'll see it.
* If the class doesn't have annotations, then the class dict
  won't have an '__annotations__' key, which is what you were expecting.

In any scenario the old best practices code works fine.

If you're in 3.10+, and your code uses cls.__annotations__ or getattr() to get 
the class dict, and we lazy-create it with a getset and store it in the class 
dict, then you also get what you expected.  If the class or module has 
annotations, you get them; if it doesn't, it lazy creates an empty dict and 
stores and returns that.  Your code works fine too.

Sorry I've been slow on figuring this out--but at least I got there in the end, 
before beta.  And it's good news!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43914] Highlight invalid ranges in SyntaxErrors

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +24302
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25582

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Paul Moore]

Paul Moore  added the comment:


New changeset fc82f3f8fb36f88a4e7238a463812c2916bd4db0 by Stéphane Bidoul in 
branch '3.8':
[3.8] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576) 
(GH-25579)
https://github.com/python/cpython/commit/fc82f3f8fb36f88a4e7238a463812c2916bd4db0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Paul Moore]

Paul Moore  added the comment:


New changeset d962b00fcffa9070acdca850753f254828caa1d7 by Stéphane Bidoul in 
branch '3.9':
[3.9] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25578)
https://github.com/python/cpython/commit/d962b00fcffa9070acdca850753f254828caa1d7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Larry Hastings]

Larry Hastings  added the comment:

I'm please you folks are as supportive as you are of what I'm doing here, given 
that you seem a little unsure of the details.  I concede that there's a lot 
going on and it can be hard to keep it all in your head.

The point of this issue / PR is to improve the best practices for 3.10 without 
breaking the best practices for 3.9 and before.

Best practice in 3.10 is to use inspect.get_annotations(), and failing that, 
three-argument getattr(), for all annotated objects.  This issue / PR permits 
that to happen.

Best practices for 3.9 differed between different objects.  For classes, you 
had no choice but to look in the class dict because of the inheritance problem. 
 (Either that, or, the elaborate scheme 'attrs' used.)  That code will 
emphatically _still work_ in 3.10.  We are not breaking backwards compatibility.

So, the best practices in 3.9 and before will still work in 3.10.  But the best 
practices for 3.10+ are improved because of the work we're doing here and in 
other places.

My intent was to document the best practices for 3.10+.  If folks think it 
would be helpful, this same section in the 3.10 docs can also describe best 
practices for 3.9 and before.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Berker Peksag]

Berker Peksag  added the comment:

Thank you for taking your time to improve the sqlite3 module!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Eric V. Smith]

Eric V. Smith  added the comment:

"It's fine to have advice ..."

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Eric V. Smith]

Eric V. Smith  added the comment:

It's find to have advice of "do X in 3.9", and "do Y in 3.10+". I think the 
issue is: if you have code that needs to run in 3.9 and 3.10+, what should you 
do? There needs to be some advice for that case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43914] Highlight invalid ranges in SyntaxErrors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Great!!!  I also tried
>>> try: compile("a xyzjdkjfk", '', 'single')
except SyntaxError as e:
print(e, e.msg, e.lineno, e.offset, e.end_lineno, e.end_offset)


invalid syntax. Perhaps you forgot a comma? (, line 1) invalid syntax. Perhaps 
you forgot a comma? 1 1 1 12

The language change that enables the display change is the addition of 
end_lineno and end_offset attributes.  I will look into using these in IDLE.  I 
will submit a PR to augment the What's New entry, so others can  also improve 
their error marking.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38659] enum classes cause slow startup time

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Seems that the buildbots are going back to green so I will close the revert PR. 
THanks a lot, Ethan for the fix and the investigation!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38659] enum classes cause slow startup time

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Stéphane Wirtel]

Change by Stéphane Wirtel :


--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

Hi Berker,

No problem, that was just a question/suggestion, and I fully understand your 
remarks. 

Thanks for your feedback.

Stéphane

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43874] argparse crashes on subparsers with no dest/metava

[Terence Honles]

Terence Honles  added the comment:

Sorry I didn't know what to put, and now that you changed it I understand what 
behavior means. Thanks for changing it.

Should I do anything further? Not sure how to proceed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43936] os.path.realpath() normalizes paths before resolving links on Windows

[Barney Gale]

New submission from Barney Gale :

Capturing a write-up by eryksun on GitHub into a new bug.

Link: https://github.com/python/cpython/pull/25264#pullrequestreview-631787754

> `nt._getfinalpathname()` opens a handle to a file/directory with 
> `CreateFileW()` and calls `GetFinalPathNameByHandleW()`. The latter makes a 
> few system calls to get the final opened path in the filesystem (e.g. 
> "\Windows\explorer.exe") and the canonical DOS name of the volume device on 
> which the filesystem is mounted (e.g. "\Device\HarddiskVolume2" -> "\\?\C:") 
> in order to return a canonical DOS path (e.g. "\\?\C:\Windows\explorer.exe").
> 
> Opening a handle with `CreateFileW()` entails first getting a fully-qualified 
> and normalized NT path, which, among other things, entails resolving ".." 
> components naively in the path string. This does not take reparse points such 
> as symlinks and mountpoints into account. The only time Windows parses ".." 
> components in an opened path the way POSIX does is in the kernel when they're 
> in the target path of a relative symlink.
> 
> `nt.readlink()` opens a handle to the file with the flag 
> `FILE_FLAG_OPEN_REPARSE_POINT`. If the final path component is a reparse 
> point, it opens it instead of traversing it. Then the reparse point is read 
> with the filesystem control request, `FSCTL_GET_REPARSE_POINT`. System 
> symlinks and mountpoints (`IO_REPARSE_TAG_SYMLINK` and 
> `IO_REPARSE_TAG_MOUNT_POINT`) are the only supported name-surrogate 
> reparse-point types, though `os.stat()` and `os.lstat()` handle all 
> name-surrogate types as 'links'. Moreover, only symlinks get the `S_IFLNK` 
> mode flag in a stat result, because they're the only ones we can create with 
> `os.symlink()` to satisfy the usage `if os.path.islink(src): 
> os.symlink(os.readlink(src), dst)`.
>
> > What would it take to do a POSIX-style "normalize as we resolve",
> > and would we want to? I guess we'd need to call nt._getfinalpathname()
> > on each path component in turn (C:, C:\Users, C:\Users\Barney etc),
> > which from my pretty basic Windows knowledge might be rather slow if
> > that involves file handles.
> 
> You asked, so I decided to write up an outline of what implementing a 
> POSIX-style `realpath()` might look like in Windows. At its core, it's 
> similar to POSIX: lstat(), and, for a symlink, readlink() and recur. The 
> equivalent calls in Windows are the following:
> 
> * `CreateFileW()` (open a handle)
> 
> * `GetFileInformationByHandleEx()`: `FileAttributeTagInfo`
> 
> * `DeviceIoControl()`: `FSCTL_GET_REPARSE_POINT`
> 
> 
> A symlink has the reparse tag `IO_REPARSE_TAG_SYMLINK`.
> 
> Filesystem mountpoints (aka junctions, which are like Unix bind mountpoints) 
> must be retained in the resolved path in order to correctly resolve relative 
> symlinks such as "\spam" (relative to the resolved device) and "..\..\spam". 
> Anyway, this is consistent with the UNC case, since mountpoints on a remote 
> server can never be resolved (i.e. a final UNC path never resolves 
> mountpoints).
> 
> Here are some of the notable differences compared to POSIX:
> 
> * If the source path is not a "\\?\" verbatim path, `GetFullPathNameW()` 
> must be called initially.  However, ".." components in the target path of a 
> relative symlink must be resolved the POSIX way, else symlinks in the target 
> path may be removed incorrectly before their target is resolved (e.g. 
> "foo\symlink\..\bar" incorrectly resolved as "foo\bar"). The opened path is 
> initially normalized as follows:
>   
>   * replace forward slashes with backslashes
>   * collapse repeated backslashes (except the UNC root must have exactly 
> two backslashes)
>   * resolve a relative path (e.g. "spam"), drive-relative path (e.g. 
> "Z:spam"), or rooted path (e.g. "\spam") as a fully-qualified path (e.g. 
> "Z:\eggs\spam")
>   * resolve "." and ".." components in the opened path (naive to symlinks)
>   * strip trailing spaces and dots from the final component (e.g. 
> "C:\spam. . ." -> "C:\spam")
>   * resolve reserved device names in the final component of a non-UNC 
> path (e.g. "C:\nul" -> "\\.\nul")
> 
> * Substitute drives (e.g. created by "subst.exe", or `DefineDosDeviceW`) 
> and mapped drives (e.g. created by "net.exe", or `WNetAddConnection2W`) must 
> be resolved, respectively via `QueryDosDeviceW()` and 
> `WNetGetUniversalNameW()`. Like all DOS 'devices', these drives are 
> implemented as object symlinks (i.e. symlinks in the object namespace, not to 
> be confused with filesystem symlinks). The target path of these drives, 
> however, is not a Device object, but rather a filesystem path on a device 
> that can include any number of path components, some of which may be 
> filesystem symlinks that need to be resolved. Normally when a path is opened, 
> the system object manager reparses all DOS 'devices' to the path of an actual 
> Device object, or a path on a Device object, 

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Berker Peksag]

Berker Peksag  added the comment:

This would make sqlite3 module unusable for many users. We have already 
increased the minimal required version in 3.10 and am opposed to do this change.

I also don't understand what part of msg370266 made you think that this is a 
reasonable change. The gist of the previous version increase was a failed test 
in older SQLite versions. As far as I'm aware, there is no such an issue to 
warrant such a step increase for minimum version requirement (from 3.7.15 to 
3.26.0)

--
nosy: +berker.peksag

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Larry Hastings]

Larry Hastings  added the comment:

I'm not breaking backwards compatibility--that's the point of all this.  But 
I'm improving the experience.  And if you don't care about 3.9 and before, you 
can stick to the new improved experience.

Looking in the class dict for annotations is terrible, but that's best practice 
for 3.9 and earlier because of the flawed design of annotations.

For 3.10+, best practice to look at annotations is inspect.get_annotations() 
for all objects.  But this isn't best practice for 3.9, because the function 
didn't exist in 3.9.  Also, the paragraph might go on to say, if you have a 
good reason why you can't call inspect.get_annotations(), best practice no 
longer requires you to look in the class dict, because of this very issue/PR 
that is behavior we are changing for 3.10.

So, best practices changed in 3.10.  And I plan to add a section to the docs 
somewhere that says "Here are best practices for accessing annotations in 
3.10+".  As I said, if you think the Python 3.10 docs should have a section 
about "here are best practices in 3.9", I can add that too, but it'll be a 
different paragraph.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43935] Fix typo in Turtle.back docstring

[Stéphane Wirtel]

New submission from Stéphane Wirtel :

Thank you for your contribution but as you know, you have to sign the CLA.

https://github.com/python/cpython/pull/25581#issuecomment-826150064

--
nosy: +matrixise

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43935] Fix typo in Turtle.back docstring

[Tarjei Bærland]

Change by Tarjei Bærland :


--
keywords: +patch
pull_requests: +24301
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25581

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43935] Fix typo in Turtle.back docstring

[Tarjei Bærland]

Change by Tarjei Bærland :


--
assignee: docs@python
components: Documentation
nosy: docs@python, tarjeiba
priority: normal
severity: normal
status: open
title: Fix typo in Turtle.back docstring
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43913] unittest module cleanup functions not run unless tearDownModule() is defined

[Terry J. Reedy]

Terry J. Reedy  added the comment:

import unittest

#def setUpModule(): raise Exception()
#def tearDownModule(): print('module teardown')

unittest.addModuleCleanup(print, 'module cleanup')

class Dummy(unittest.TestCase):
def test_dummy(self):
self.addCleanup(print, 'test cleanup')
self.addClassCleanup(print, 'class cleanup')

unittest.main()
--
Above verifies the claim in 3.10.0a7.   Only 'test cleanup' and 'class cleanup' 
print. Uncomment either function and 'module cleanup' is also printed.

https://docs.python.org/3/library/unittest.html#unittest.addModuleCleanu
"""
unittest.addModuleCleanup(function, /, *args, **kwargs)

Add a function to be called after tearDownModule() to cleanup resources 
used during the test class. Functions will be called in reverse order to the 
order they are added (LIFO). They are called with any arguments and keyword 
arguments passed into addModuleCleanup() when they are added.

If setUpModule() fails, meaning that tearDownModule() is not called, then 
any cleanup functions added will still be called.
"""
This seems slightly ambiguous as to behavior when no tearDownModule.  However, 
the doc for addClassCleanup is exactly parallel.

https://docs.python.org/3/library/unittest.html#unittest.TestCase.addClassCleanup
"""
classmethod addClassCleanup(function, /, *args, **kwargs)

Add a function to be called after tearDownClass() to cleanup resources used 
during the test class. Functions will be called in reverse order to the order 
they are added (LIFO). They are called with any arguments and keyword arguments 
passed into addClassCleanup() when they are added.

If setUpClass() fails, meaning that tearDownClass() is not called, then any 
cleanup functions added will still be called.
"""

The doc for addCleanup is also parallel.  The behavior difference therefore 
seems like a bug and calling in any case seems more correct.

Ryan, can you prepare a PR?

--
nosy: +ezio.melotti, michael.foord, rbcollins, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43913] unittest module cleanup functions not run unless tearDownModule() is defined

[Terry J. Reedy]

Change by Terry J. Reedy :


--
stage:  -> needs patch
versions: +Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43933] Regression in python3.10 with traceback frame having lineno of -1

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Thanks for the bisection, Anthony

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43933] Regression in python3.10 with traceback frame having lineno of -1

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Marking as release blocker since is breaking pytest

--
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43933] Regression in python3.10 with traceback frame having lineno of -1

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
assignee:  -> Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Stéphane Wirtel]

Change by Stéphane Wirtel :


--
keywords: +patch
pull_requests: +24300
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25580

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43934] Minimal version of SQLite3 - 3.26 ?

[Stéphane Wirtel]

New submission from Stéphane Wirtel :

After reading this issue: https://bugs.python.org/msg370266, I think SQLite 
3.26.0 could be the minimal version for Python 3.10.


I have checked the following distributions

CentOS 8: stable : 8.3.2011: 3.26.0
Debian 10: stable : 10 : 3.27.2
Ubuntu 20.04: stable : 20.04: 3.31.1

CentOS 7: oldstable : 7.9.2009: 3.7.17
Debian 9: oldstable : 9.13: 3.16.2

--
messages: 391797
nosy: matrixise
priority: normal
severity: normal
status: open
title: Minimal version of SQLite3 - 3.26 ?
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[Aritn Sarraf]

Aritn Sarraf  added the comment:

Hi Steve, a couple things to preface my following comment. (1) Didn't mean to 
suggest that the current behavior is a bug. I don't think it is a bug, rather 
that it can easily lead to bugs. (2) Sorry for tagging the previous versions, 
I'm not familiar with the ticket system and didn't realize I was asking for 
(nor do I want) this to be changed in previous versions as well. I thought it 
just means what versions was this ticket relevant to.

I do realize and appreciate the basic object model regarding `bool(obj)`, and 
there is nothing in the threading documentation or the language as a whole that 
would lead me to believe that Events should be evaluated for their truthiness 
directly. However, I would like to expand on my case further before closing the 
ticket.

I believe there is a fundamental difference in the "perception" of what an 
Event object represents vs most other objects, *with respect to how bool should 
be evaluated on it*. It undeniably draws very clear parallels to a true boolean 
flag, and is often used as a surrogate for such. I realize it is more than 
that, that it's used for synchronization as well as other things, but the fact 
that Event is so often assigned to a variable called "flag" or a variable that 
implies a discrete boolean state (like my original stop_thread example), rather 
than a variable name that encompasses the full concept of an event, is a good 
indication that this is how people view/use the object. 

Given that the concept of Event and a boolean flag are so closely intertwined, 
I think that (but am *not* suggesting the following) it could even be 
considered appropriate for `bool(not_set_event)` to evaluate to False.  Again, 
I am not suggesting this, as I realize that an Event is more than just it's 
underlying "set" state. But, this is why I think that more often than not it is 
Ambiguous what a developer actually intended by directly evaluating such.

Now, in terms of what the current behavior enables us to do, in other words, by 
adopting this change, what abilities in the language/threading framework are we 
losing. The only thing I can think of is the ability to do this: `event = event 
or Event()`. I don't have statistics on this but I would make the assumption, 
and I believe it's a safe one, that the vast majority of situations where Event 
shows up in a boolean evaluated statement (e.g. if, while, not, and/or) is as 
`event.is_set()`. So much so, that I would even go so far as to make the 
assumption that there is a decently high probability that if someone does write 
`event or/and other_variable` it was done so in error. However, this is nothing 
but an assumption, with no evidence to back it up, so really the point I want 
to get across here is that there is not much utility in `bool(event)` and I 
don't think we're hindering the language in any way by forbidding it.

With respect to backwards compatibility, while it is not backwards compatible, 
it is very refactor friendly. First of all, there will not be many properly 
used cases (e.g. `event = event or Event()`) where this would show up in the 
first place. And second, since we're raising an exception rather than returning 
a different value, we won't introduce unexpected behavior to any existing use 
cases.

All this said, any bugs that this behavior can lead to, are most likely easily 
caught and resolved. But, I think that this change would be, and only be, a 
benefit to developing threaded applications in Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43933] Regression in python3.10 with traceback frame having lineno of -1

[Anthony Sottile]

New submission from Anthony Sottile :

This is breaking pytest for failed assertions: 
https://github.com/pytest-dev/pytest/pull/8227

It also breaks the traceback in the output below

Here's a minimal example:

```python
class Boom:
def __enter__(self):
return self
def __exit__(self, *_):
raise AssertionError('boom!')


def main() -> int:
with Boom():
raise AssertionError('hi')


if __name__ == '__main__':
exit(main())
```

On python3.9 you get this:

```
Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
raise AssertionError('hi')
AssertionError: hi

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 14, in 
exit(main())
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
raise AssertionError('hi')
  File "/home/asottile/workspace/cpython/t.py", line 5, in __exit__
raise AssertionError('boom!')
AssertionError: boom!
```

output in python3.10:

```
Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 10, in main
raise AssertionError('hi')
AssertionError: hi

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/asottile/workspace/cpython/t.py", line 14, in 
exit(main())
  File "/home/asottile/workspace/cpython/t.py", line -1, in main
  File "/home/asottile/workspace/cpython/t.py", line 5, in __exit__
raise AssertionError('boom!')
AssertionError: boom!
```

Notice the second to last frame is now missing and invalid (line -1)

I bisected this and found this is the culprit:


https://github.com/python/cpython/commit/3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67
https://github.com/python/cpython/pull/24202

```
3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67 is the first bad commit
commit 3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67
Author: Mark Shannon 
Date:   Wed Jan 13 12:05:43 2021 +

bpo-42908: Mark cleanup code at end of try-except and with artificial 
(#24202)

* Mark bytecodes at end of try-except as artificial.

* Make sure that the CFG is consistent throughout optimiization.

* Extend line-number propagation logic so that implicit returns after 
'try-except' or 'with' have the correct line numbers.

* Update importlib

 Lib/test/test_dis.py  |2 +-
 Lib/test/test_sys_settrace.py |   40 +
 Python/compile.c  |  135 +-
 Python/importlib.h| 3153 ++---
 Python/importlib_external.h   | 4489 -
 Python/importlib_zipimport.h  | 1013 +-
 6 files changed, 4473 insertions(+), 4359 deletions(-)
bisect run success
```

which appears to be due to bpo-42908

--
messages: 391795
nosy: Anthony Sottile, Mark.Shannon, pablogsal
priority: normal
severity: normal
status: open
title: Regression in python3.10 with traceback frame having lineno of -1
versions: Python 3.10, Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43874] argparse crashes on subparsers with no dest/metava

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Terence, a 'crash' for this tracker is a core dump or equivalent with no 
exception/traceback.

--
nosy: +terry.reedy
stage:  -> patch review
type: crash -> behavior
versions:  -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43932] f-string decimal has leading space

[Mark Dickinson]

Change by Mark Dickinson :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43932] f-string decimal has leading space

[Mark Dickinson]

Mark Dickinson  added the comment:

This is by design, and documented under the "sign" section here: 
https://docs.python.org/3/library/string.html#format-specification-mini-language

The space before ".2f" is an instruction to leave space for a sign, "-" for a 
negative number and " " for a positive number. To avoid that space, use a 
format of ".2f" instead of " .2f".

>>> format(15, ".2f")
'15.00'
>>> format(15, " .2f")
' 15.00'
>>> format(15, "+.2f")
'+15.00'

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks Andrei

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed

[Jason R. Coombs]

Change by Jason R. Coombs :


--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Using zipfile.Path with several files prematurely closes zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43193] Installer for All users

[Muhammad Hussein Ammari]

Change by Muhammad Hussein Ammari :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43193] Installer for All users

[Muhammad Hussein Ammari]

Muhammad Hussein Ammari  added the comment:

Duplicate: https://bugs.python.org/issue25166

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25166] Windows All Users installation places uninstaller in user profile

[Muhammad Hussein Ammari]

Change by Muhammad Hussein Ammari :


--
title: Windows AllUsers installation places uninstaller in user profile -> 
Windows All Users installation places uninstaller in user profile

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows

[Stéphane Wirtel]

Stéphane Wirtel  added the comment:

Hi Shreyan Avigyan,

For that, you need to follow the forum of SQLite.

https://www.sqlite.org/forum/forum

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43932] f-string decimal has leading space

[Akshay K]

New submission from Akshay K :

When using a f-string to print a number with a certain number of decimal 
places, the number is printed with a leading space.

--
components: Interpreter Core
files: fstringdemo.py
messages: 391789
nosy: Axeinator, eric.smith
priority: normal
severity: normal
status: open
title: f-string decimal has leading space
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49981/fstringdemo.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

Do anyone notice any bug in SQLite 3.35.5? If not then I think it's time to 
upgrade to SQLite 3.35.5.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows

[Stéphane Wirtel]

Change by Stéphane Wirtel :


--
nosy: +matrixise

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38659] enum classes cause slow startup time

[Ethan Furman]

Ethan Furman  added the comment:

Pablo, did my latest patch resolved the errors?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

Change by Stéphane Bidoul :


--
pull_requests: +24299
pull_request: https://github.com/python/cpython/pull/25579

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

Change by Stéphane Bidoul :


--
nosy: +sbidoul
nosy_count: 5.0 -> 6.0
pull_requests: +24298
pull_request: https://github.com/python/cpython/pull/25578

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Looks like a duplicate of https://bugs.python.org/issue40564 , which was fixed 
and closed so this can also be closed.

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores.

[hai shi]

hai shi  added the comment:

Thanks Marc-Andre for your supplement of PEP-100.
Thanks Inada, victor for your review and merge.

After PR-23096 merged, I suggest to close this bpo.
If there have any other questions, we can reopen it again.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Paul Moore]

Paul Moore  added the comment:


New changeset 196983563d05e32d2dcf217e955a919f9e0c25e1 by Stéphane Bidoul in 
branch 'master':
bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576)
https://github.com/python/cpython/commit/196983563d05e32d2dcf217e955a919f9e0c25e1


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42725] PEP 563: Should the behavior change for yield/yield from's

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>  I just thought having a whole “expr-without-walrus-or-yield” subgrammar 
> would be tedious.

Yeah I have experimented with something similar in the past and this becomes 
out of hand super quickly and leafs to a lot of duplication.

Similarly, a flag that conditionally accept some rules can be quite tricky to 
hey right with the backtracking and those require some extra metagrammar so 
adding the flag is not super unreadable. 

In my humble opinion, I think is far simpler to reject this after the parsing 
is done, either in the compiler or the symbol table.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42725] PEP 563: Should the behavior change for yield/yield from's

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is no “expr-without-await-or-async-for” subgrammar, but "await" and 
asynchronous comprehensions are invalid in synchronous functions. There should 
be similar flag for annotations in symtable.c.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43780] Sync importlib_metadata enhancements through 3.10.

[Jason R. Coombs]

Change by Jason R. Coombs :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43901] Add an empty annotations dict to all unannotated classes and modules

[Guido van Rossum]

Guido van Rossum  added the comment:

And that’s a problem. There needs to be a recommendation on what to do for code 
that spans 3.9 and 3.10. What should users do otherwise? Drop 3.9 as soon as 
they introduce 3.10 support? Withhold 3.10 support until 3.9 reaches EOL?

IOW you can’t just break backward compatibility. (That’s why PEP 563 was rolled 
back in the first place.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42725] PEP 563: Should the behavior change for yield/yield from's

[Guido van Rossum]

Guido van Rossum  added the comment:

I don’t really care how you do it, I just thought having a whole 
“expr-without-walrus-or-yield” subgrammar would be tedious.

If there is a way to have the “in-an-annotation” flag set during parsing that 
may be better, I don’t know.

Maybe Lysandros has an idea?

--
nosy: +Guido.van.Rossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43931] Add the Python version to the API data.

[Gabriele N Tornetta]

Change by Gabriele N Tornetta :


--
keywords: +patch
pull_requests: +24297
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25577

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43931] Add the Python version to the API data.

[Gabriele N Tornetta]

New submission from Gabriele N Tornetta :

When Python is embedded in other applications, it is not easy to determine 
which version of Python is being used. This change exposes the Python version 
as part of the API data. Tools like Austin 
(https://github.com/P403n1x87/austin) can benefit from this data when targeting 
applications like uWSGI, as the Python version can then be inferred 
systematically by looking at the exported symbols rather than relying on 
unreliable pattern matching or other hacks (like remote code execution etc...).

--
components: C API
messages: 391779
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: Add the Python version to the API data.
type: enhancement
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

Change by Stéphane Bidoul :


--
nosy: +Marcus.Smith -sbidoul

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

Change by Stéphane Bidoul :


--
keywords: +patch
pull_requests: +24296
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25576

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

Change by Stéphane Bidoul :


--
nosy: +dstufft, ncoghlan, paul.moore, pradyunsg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43780] Sync importlib_metadata enhancements through 3.10.

[Jason R. Coombs]

Jason R. Coombs  added the comment:


New changeset c6ca368867bd68d44f333df840aa85d425a51410 by Jason R. Coombs in 
branch 'master':
bpo-43780: Sync with importlib_metadata 3.10 (GH-25297)
https://github.com/python/cpython/commit/c6ca368867bd68d44f333df840aa85d425a51410


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0

[Stéphane Bidoul]

New submission from Stéphane Bidoul :

I've just released pip 21.1, so this is to update the bundled copy (as well as 
updating setuptools).

--
components: Library (Lib)
messages: 391777
nosy: sbidoul
priority: normal
severity: normal
status: open
title: Update bundled pip to 21.1 and setuptools to 56.0.0
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43520] Make Fraction(string) handle non-ascii slashes

[Frédéric Grosshans-André]

Frédéric Grosshans-André  added the comment:

@Gregory P. Smith 

unicodedata.numeric, in the sdandard library, already handles non-Ascii 
fractions in many scripts. The current “problem” is it outputs a float (even 
for integers):

>>> unicodedata.numeric('⅔')
0.

The UnicodeData.txt file from the Unicode standard it takes its data from, 
however, contains the corresponding “ascii fractions”. For example, below are 
two lines of this file for two (very) different ways of encoding two thirds

2154;VULGAR FRACTION TWO THIRDS;No;0;ON; 0032 2044 
0033;;;2/3;N;FRACTION TWO THIRDS
1245B;CUNEIFORM NUMERIC SIGN TWO THIRDS DISH;Nl;0;L2/3;N;

Adding an exact value extraction to unicodedata should be doable, either via an 
function or an extra keyword to the unicodedata.numeric function.

The only information that would be lost (but which is unavailable now anyway) 
would be for the few codepoints which encode reducible fractions. As of unicode 
13.0, these codepoints are

* ↉ U+2189 VULGAR FRACTION ZERO THIRDS
* ৷ U+109F7 MEROITIC CURSIVE FRACTION TWO TWELFTHS
* ৸ U+109F8 MEROITIC CURSIVE FRACTION THREE TWELFTHS
* ৹ U+109F9 MEROITIC CURSIVE FRACTION FOUR TWELFTHS
* ৻ U+109FB MEROITIC CURSIVE FRACTION SIX TWELFTHS
* ৽ U+109FD MEROITIC CURSIVE FRACTION EIGHT TWELFTHS
* ৾ U+109FE MEROITIC CURSIVE FRACTION NINE TWELFTHS
* ৿ U+109FF MEROITIC CURSIVE FRACTION TEN TWELFTHS

--
nosy: +frederic.grosshans

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43921] test_ssl fails on Windows buildbots

[Christian Heimes]

Christian Heimes  added the comment:


New changeset ce9a0643496ba802ea97a3da20eace3a1117ea48 by Christian Heimes in 
branch 'master':
bpo-43921: also accept EOF in post-handshake auth test (GH-25574)
https://github.com/python/cpython/commit/ce9a0643496ba802ea97a3da20eace3a1117ea48


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is not a bug fix, it is a change of behaviour ("enhancement"). All of 3.6 
through 3.9 are in feature freeze. 3.10 is probably in feature freeze, but if 
not it is extremely close to it. So this can only go into 3.11 and (maybe) 3.10.

But I don't think this is a good enhancement. I am sorry that you keep making 
the mistake of wrongly assuming that you can use threading Events that way, but 
your mistake is not necessarily a flaw in the object.

Is there anything in the documentation that leads you to believe that Events 
are intended to be used that way?

The basic object model of Python is that all objects can be duck-typed as 
bools, that is they are either truthy or falsey. Values which represent 
"nothing" in some sense (empty containers, zero numbers, None) should evaluate 
as False; values which represent "something" (non-empty containers, non-zero 
numbers, arbitrary objects) should evaluate as True. This model goes back to 
the earliest days of Python 1.x before we even had a bool type or True and 
False singletons, and 1 and 0 where used instead.

`bool(obj)` is a fundamental operation, like `print(obj)`, which should never 
fail.

You say: "the intention behind bool(event) is ambiguous" but I don't believe 
that is correct. Unless documented differently, the intention behind 
bool(event) is:

- events are not containers;
- or numbers;
- but they are "things" (objects);
- and so they should evaluate as True.

So unless you can provide evidence for this ambiguity, or evidence that many 
other people make this same mistake, I will recommend this issue be closed.

--
nosy: +steven.daprano
type: behavior -> enhancement
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16386] imp.find_module does not specify registry key it searches on windows

[Irit Katriel]

Irit Katriel  added the comment:

Both 
http://docs.python.org/3/library/importlib.html#importlib.machinery.WindowsRegistryFinder
 
and 
http://docs.python.org/3/library/imp.html#imp.find_module:

are now deprecated. Is this issue still relevant?

--
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27521] Misleading compress level header on files created with gzip

[Irit Katriel]

Irit Katriel  added the comment:

I believe this was fixed here: https://github.com/python/cpython/pull/18077

--
nosy: +iritkatriel
resolution:  -> duplicate
status: open -> pending
superseder:  -> gzip metadata fails to reflect compresslevel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[artin sarraf]

Change by artin sarraf :


--
keywords: +patch
nosy: +sarf
nosy_count: 1.0 -> 2.0
pull_requests: +24294
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25575

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43929] Raise on threading.Event.__bool__ due to ambiguous nature

[Aritn Sarraf]

New submission from Aritn Sarraf :

I'll sometimes find myself accidentally doing something like this (especially 
after a long break from using the threading module): 
```
stop_thread = threading.Event()
...
while not stop_thread:  # bug - bool(stop_thread) will always evaluate to True
...
```

Since the intention behind bool(event) is ambiguous and most likely often used 
improperly, I think that it would be a good idea to protect against this easy 
to produce bug, by overriding __bool__ to raise. There is precedent for this 
behavior in the popular numpy library, see here:
https://github.com/numpy/numpy/blob/623bc1fae1d47df24e7f1e29321d0c0ba2771ce0/numpy/core/src/multiarray/number.c#L829

Expanding on my thoughts:
1) Most operations on a threading.Event are associated with checking the 
truthiness of the underlying state of the Event. Meaning that there are many 
opportunities for bool(event) to be called improperly.
2) I can't think of any cases where  you would want to evaluate truthiness on 
anything other than the underlying "set" state of the Event. The one exception 
I can think of being the following (however, I believe this is generally 
accepted to be an anti-pattern, which I don't think should be considered a 
redeeming case for allowing bool(event)):
```
def my_func(event=None):
event = event or threading.Event()
...
```
3) It is an easy addition to protect against this. Simply by raising in __bool__
4) The only backwards incompatibilities this could create are in cases where 
the event is being evaluated for truthiness incorrectly, and in the 
anti-pattern case described in point 2.

--
components: Library (Lib)
messages: 391771
nosy: asarraf
priority: normal
severity: normal
status: open
title: Raise on threading.Event.__bool__ due to ambiguous nature
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43921] test_ssl fails on Windows buildbots

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +24293
pull_request: https://github.com/python/cpython/pull/25574

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37322] test_ssl: test_pha_required_nocert() emits a ResourceWarning

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +24292
pull_request: https://github.com/python/cpython/pull/25573

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37322] test_ssl: test_pha_required_nocert() emits a ResourceWarning

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +24291
pull_request: https://github.com/python/cpython/pull/25572

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43817] Add inspect.get_annotations()

[Larry Hastings]

Larry Hastings  added the comment:

Perhaps eval_str=ONLY_IF_STRINGIZED should also add the semantics "if 
evaluating any string fails, behave as if eval_str=false".  I would *not* 
propose adding that for eval_str=true.  But people keep asking for this.  Hmm.

The heuristic is a tricky thing.  That's why in my "PEP 1212" idea I proposed a 
way that a function like get_annotations() could determine unambiguously 
whether or not the annotations for an object were stringized.  (And, if we did 
do something like that in a future Python version, this would also change the 
"if evaluating any string fails" behavior I just proposed.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43817] Add inspect.get_annotations()

[Inada Naoki]

Inada Naoki  added the comment:

>
> The difference between eval_str=True and eval_str=ONLY_IF_STRINGIZED:
>
> def foo(a:int, b:"howdy howdy"): ...
>
> inspect.get_annotations(foo, eval_str=True) throws an exception.
> inspect.get_annotations(foo, eval_str=ONLY_IF_STRINGIZED) returns {'a': int, 
> b: 'howdy howdy'}
>
> Type hints have a convention that string annotations are a "forward 
> declaration" and should be eval()uated.  Annotations don't have such a 
> convention--a string is a legal annotation, and is not required to be valid 
> Python.
>

For such use case, ONLY_IF_STRINGIZED thorows an exception for `def
foo(a: "howdy howdy")` anyway.
In such cases, they should use `eval_str=False`, or `eval_str=True`
*and* `return_str_when_eval_failed=True` option.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com