[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Eric V. Smith]

Eric V. Smith  added the comment:

At this stage in the release cycle, if you really feel strongly about this, you 
should take it up with Guido directly.

--
assignee:  -> eric.smith

___
Python tracker 

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

[issue33257] Race conditions in Tkinter with non-threaded Tcl

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

The 1st PR is ready.
I'll continue working on the 2nd one in this ticket, too, if there are no 
objections.

--

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Eric V. Smith]

Change by Eric V. Smith :


--
keywords: +patch, patch
pull_requests: +6455, 6456
stage:  -> patch review

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Eric V. Smith]

Change by Eric V. Smith :


--
keywords: +patch
pull_requests: +6456
stage:  -> patch review

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[INADA Naoki]

INADA Naoki  added the comment:

> > I think we've learned lesson that we shouldn't use typing in modules
other than typing...

> This is a blanket statement that as hurtful as it is factually
incorrect.  Let me address the latter.

> 1. Dataclasses are entirely dependent on annotations *as described by the
typing module*.   While it would be entirely possible for users to pass an
arbitrary expression as an annotation to denote it's a field of the
dataclass, then it's confusing the reader of that code... what's the
point?  The fact that dataclasses isn't itself importing `typing` is an
implementation detail of dataclasses.

When I said "use typing module", I meant "using type information from
annotation value" preciously.
Using only name of the annotation is not harmful.

> 2. The problem isn't even specific to `typing` but stringified type
annotations in general.  If the magic sentinel annotation came from the
dataclasses module, it would be just as tricky to get it right as it is now
when this sentinel lives in `typing`.

Yes.  I think we shouldn't parse annotation value until we can expect
issues like this and estimate performance overhead of
massive calling of get_type_hints() on application startup.

> 3. singledispatch now also allows registering functions that are
type-annotated.  In fact, that is a nicer API than the old one.  That usage
also imports `typing`.  I don't see how this is a problem.

How about performance?
Isn't performance overhead of it is much larger than expected by people who
don't know internal of get_type_hints()?

I agree that annotation could very useful.
But I fear that utilizing annotation value may make ugly hack like
"ClassVar" prefix
or unexpected slow import time.  So I want to be very conservative about
utilizing annotation in stdlib.

Once it is happen, it's very hard to remove it from stdlib.
I think we should learn more about runtime usage of type hints in third
party library,
before using it in stdlib.

--

___
Python tracker 

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

[issue33468] Add try-finally contextlib.contextmanager example

[Nick Coghlan]

New submission from Nick Coghlan :

The current example for contextlib.contextmanager doesn't use try/finally, 
which sets folks up for writing resource management context managers that don't 
clean up after exceptions properly.

There's an example with try/finally down in the contextlib.closing docs, but 
I'm thinking it would be worthwhile to change the presentation of 
contextmanager itself.

--
assignee: ncoghlan
components: Documentation
messages: 316416
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add try-finally contextlib.contextmanager example
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33015] Fix function cast warning in thread_pthread.h

[Steve Dower]

Steve Dower  added the comment:

In this case, we know the behaviour is okay and the warning is wrong. We should 
suppress the warning around the offending line, rather than adding significant 
code that may introduce genuine bugs.

--

___
Python tracker 

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

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

Michael Felt  added the comment:

P.s. i apologize for probably posting in the incorrect “issues” area. Having 
followed guido’s link i see an area that is new for me. 

If it is better that i “restart” the discussion there, just ask.

--
nosy: +aixto...@gmail.com

___
Python tracker 

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

[issue33459] Define "tuple display" in the docs

[R. David Murray]

R. David Murray  added the comment:

Hmm.  OK, I didn't think that's how we'd defined those terms, but then I don't 
actually work with the parser much myself :)  However, generator expressions 
are clearly called out as a separate thing.  All of the other display types get 
their own section, so I would think tuple display should too if it really is a 
syntax unit...but maybe it isn't.

Also, I'm not clear on what 'binding' means in that table entry.

I see now why you wanted to say "parenthesized expression", but as far as I can 
see the previous text is referring to it as an expression list in parenthesis 
form.  That's a bit wordy, which may be why someone used tuple display there.  
Clearly there is some ambiguity here that it would be nice to resolve, 
considering this is part of the language spec, but frankly I'm not sure what to 
suggest.  At that level I'm not sure how the "operator precedence" is actually 
"resolved"...I think it is more a matter of it being implicit in the parsing, 
but I'm not sure.  Like I said, not my area of expertise.

--

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Rick Teachey]

Rick Teachey  added the comment:

Lending my voice to the suggestion of limiting the class attribute check to 
`typing.ClassVar` and `ClassVar`. It can always be expanded later if it is 
needed.

--

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Łukasz Langa]

Łukasz Langa  added the comment:

> I think we've learned lesson that we shouldn't use typing in modules other 
> than typing...

This is a blanket statement that as hurtful as it is factually incorrect.  Let 
me address the latter.

1. Dataclasses are entirely dependent on annotations *as described by the 
typing module*.   While it would be entirely possible for users to pass an 
arbitrary expression as an annotation to denote it's a field of the dataclass, 
then it's confusing the reader of that code... what's the point?  The fact that 
dataclasses isn't itself importing `typing` is an implementation detail of 
dataclasses.

2. The problem isn't even specific to `typing` but stringified type annotations 
in general.  If the magic sentinel annotation came from the dataclasses module, 
it would be just as tricky to get it right as it is now when this sentinel 
lives in `typing`.

3. singledispatch now also allows registering functions that are 
type-annotated.  In fact, that is a nicer API than the old one.  That usage 
also imports `typing`.  I don't see how this is a problem.


> If it is really needed, I think we should only allow "typing.ClassVar".  All 
> other prefixes seems ambiguous.

I came up with "typing", "t", and straight "ClassVar" by grepping through typed 
codebases I work with.  I agree that "t" is rather arbitrary so I'm totally 
fine with leaving that one out.

--
assignee: eric.smith -> 

___
Python tracker 

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

[issue33459] Define "tuple display" in the docs

[Andrés Delfino]

Andrés Delfino  added the comment:

The documentation says a display may or may not have a comprehension :/

[1, 2, 3] is a list display too.

[x for x in range(3)] is a display that has a comprehension. Acoording to the 
doc.

--

___
Python tracker 

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

[issue33459] Define "tuple display" in the docs

[R. David Murray]

R. David Murray  added the comment:

That's a generator expression, just like [x for x in ramge(3)] is a list 
comprehension, not a list display.  And yes, in a number of circumstances 
parenthesis are required to delimit the tuple display and disambiguate the 
syntax.  That is, it is the 1, 2, 3 that is the tuple display, but sometimes 
you have to enclose it in parenthesis in order for the parser to recognize it.  
Which is why it would be good to give a more thorough explanation of what a 
tuple display is than the unlabeled one Cheryl pointed out.  I'm not entirely 
sure what the exact rules are for when you get a syntax error without the 
parens, myself :)

--

___
Python tracker 

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

[issue33467] Python 3.7: profile-opt build errors because a test seems to hang

[Rahul Ravindran]

New submission from Rahul Ravindran :

make run_profile_task

runs the tests and does not seem to have any mechanism to exclude tests that I 
could find based on looking at the Makefile.

Previously, on Python 3.6, this test test_poplib was 
failing(https://bugs.python.org/issue32753) and the profile_task would ignore 
failing tests. 

Now, with the Python 3.7 build, the test seems to hang and hence profile opt 
builds cannot be built.
Attached is the trace of the build based on Python-3.7.0b4

--
components: Build
files: stack_trace1.txt
messages: 316408
nosy: Rahul Ravindran
priority: normal
severity: normal
status: open
title: Python 3.7: profile-opt build errors because a test seems to hang
versions: Python 3.7
Added file: https://bugs.python.org/file47582/stack_trace1.txt

___
Python tracker 

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

[issue33459] Define "tuple display" in the docs

[Andrés Delfino]

Andrés Delfino  added the comment:

Ignore the previous comment.

The thing is that "tuple displays" like:

nums = (n for n in range(10))

Yield a generator expression instead of a tuple.

Also, unparenthesized "tuple displays" like 1, 2, 3 can't be used in 
expressions, AFAIK:

>>> if 3 == 1, 2, 3:
SyntaxError: invalid syntax

So, you end up using parenthesized expressions to use tuples in expressions. So 
talking about "tuple displays" in the operator precedence table doesn't make 
much sense to me :/

Also, if a "tuple display" doesn't yield a tuple, should it be named a "tuple 
display" after all?

--

___
Python tracker 

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

[issue33459] Define "tuple display" in the docs

[Andrés Delfino]

Andrés Delfino  added the comment:

The thing is that "tuple displays" like:

nums = (n for n in range(10))

Yield a generator expression instead of a tuple.

Also, unparenthesized "tuple displays" like 1, 2, 3 can't be used in 
expressions, AFAIK:

>>> if 3 == 1, 2, 3:
SyntaxError: invalid syntax

So, you end up using parenthesized expressions (that may or may not shield 
tuples) to use tuples in expressions. So talking about "tuple expressions" in 
the operator precedence table doesn't make much sense to me :/

Also, if a "tuple display" doesn't yield a tuple, should it be named a "tuple 
display" after all?

--

___
Python tracker 

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

[issue33466] Distutils does not support the compilation of Objective-C++ (“.mm”) files

[Alexander Böhn]

Change by Alexander Böhn :


--
keywords: +patch
pull_requests: +6453
stage:  -> patch review

___
Python tracker 

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

[issue33466] Distutils does not support the compilation of Objective-C++ (“.mm”) files

[Alexander Böhn]

New submission from Alexander Böhn :

Attempting to compile an Objective-C++ source file suffixed “.mm” results in an 
error complaining about the file extension being unrecognized.

--
components: Distutils
messages: 316405
nosy: dstufft, eric.araujo, fish2000
priority: normal
severity: normal
status: open
title: Distutils does not support the compilation of Objective-C++ (“.mm”) files
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33346] Syntax error with async generator inside dictionary comprehension

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are several related PEPs:

PEP 492 -- Coroutines with async and await syntax
PEP 525 -- Asynchronous Generators
PEP 530 -- Asynchronous Comprehensions

I haven't found anything explicit about this case. PEP 492 says that just 
"await" is not enough for converting a function into a coroutine. Explicit 
"async def" is required. PEP 530 says nothing about implementation details, it 
omits the fact that comprehensions are implemented by creating and calling an 
implicit function. From the implementation's point of view PEP 530 means that 
"async for" and "await" inside an implicit function make it an asynchronous 
function, and implicit "await" is added in the place of it's call. The natural 
extension of this is than an implicit "await" should have the same effect as 
explicit "await", in particular it should make an outer implicit function an 
asynchronous function and add other implicit "await" in the place of it's call, 
and so forth. But all this is implied, and is not said explicitly.

I don't understand one paragraph in PEP 530:

"""
In principle, asynchronous generator expressions are allowed in
any context.  However, in Python 3.6, due to ``async`` and ``await``
soft-keyword status, asynchronous generator expressions are only
allowed in an ``async def`` function.  Once ``async`` and ``await``
become reserved keywords in Python 3.7, this restriction will be
removed.
"""

Does it mean that even more restrictions should be removed than PR 6766 does? 
And what is the relation between this restriction and making "async" and 
"await" reserved keywords?

--

___
Python tracker 

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

[issue33465] test_from_import_missing_attr_has_name_and_so_path fails when select is a builtin instead of an extension

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue33465] test_from_import_missing_attr_has_name_and_so_path fails when select is a builtin instead of an extension

[Matthias Klose]

New submission from Matthias Klose :

==
ERROR: test_from_import_missing_attr_has_name_and_so_path 
(test.test_import.ImportTests)
--
Traceback (most recent call last):
  File "/usr/lib/python3.7/test/test_import/__init__.py", line 98, in 
test_from_import_missing_attr_has_name_and_so_path
self.assertEqual(cm.exception.path, select.__file__)
AttributeError: module 'select' has no attribute '__file__'

--
Ran 75 tests in 0.618s

FAILED (errors=1, skipped=1)
test test_import failed

--
components: Tests
messages: 316403
nosy: brett.cannon, doko, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: test_from_import_missing_attr_has_name_and_so_path fails when select is 
a builtin instead of an extension
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

Michael Felt  added the comment:

FYI: as my primary effort for AIX concerned ctypes.find_library() - and that is 
now in the Python3-3.7 branch - when I do a PR it will only be for "current" 
efforts, i.e., Python3-3.7 and later.

As much as I feel it is important I'll backport myself into branches I'll label 
"aix.vX.Y.Z", where the starting point is always anew from vX.Y.Z

More detailed: (e.g., on 3.4.8, which I am working on now)

git clone -b v3.4.8 g...@github.com:aixtools/cpython.git python-3.4.8
git branch aix.v3.4.8
cat ../aix.patch | patch ...
make and test
git commit -m"my message"
git push to_my_fork

As much as possible, I want to be in sync with python - and give you the option 
of including anything AIX.

As counts for most, if not all, this is "free-time", not paid - but I will 
always try to respond to questions re: AIX.

Guido - thank you for the support!

--

___
Python tracker 

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

[issue25109] test_code_module tests fail when run from the installed location

[Matthias Klose]

Matthias Klose  added the comment:

this seems to be fixed in 3.6 (3.6.5) and 3.7 (beta4).

--
resolution:  -> fixed
stage: needs patch -> 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

[issue30850] [2.7] bsddb3: test01_basic_replication() of test_bsddb3 fails randomly on AMD64 Windows8.1 Refleaks 2.7

[STINNER Victor]

STINNER Victor  added the comment:

Oh no, I saw it again!

http://buildbot.python.org/all/#/builders/51/builds/119/steps/3/logs/stdio

running: test_bsddb3 (1569 sec)
running: test_bsddb3 (1599 sec)
1:02:05 [403/403/1] test_bsddb3 crashed
(...)
1 test failed:
test_bsddb3

--

___
Python tracker 

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

[issue33464] AIX and "specialized downloads" links

[Guido van Rossum]

Guido van Rossum  added the comment:

Given that we don't feel it is worth the effort to support AIX in the CPython 
source explicitly, I think it's right that we at least link to Michael's 
efforts in the "other downloads" page.

I don't actually know if this should go to the python.org website tracker 
(https://github.com/python/pythondotorg/issues) or here (here's appropriate if 
it's in the CPython source repo -- in that case Michael can submit a PR linked 
to this issue.)

--

___
Python tracker 

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

[issue33346] Syntax error with async generator inside dictionary comprehension

[Guido van Rossum]

Guido van Rossum  added the comment:

@Ivan: Please stop bringing up that we should drop the implicit scope for 
comprehensions. I know you feel this way, but it's not going to happen.

@Serhiy: What does the PEP for async/await say? (Or is there a separate PEP for 
allowing async/await inside comprehensions?)

@Yury: Your thoughts?

I do think the code from the OP's example should be expected to work.

Does it / should it work the same way for generator expressions?

--

___
Python tracker 

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

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This would have to go through a deprecation cycle, but it would be a nice 
improvement (faster, cleaner, and consistent with data classes).

--
assignee: rhettinger -> 
components: +Library (Lib)

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[INADA Naoki]

INADA Naoki  added the comment:

> We can't break the API at this point in the release cycle.

We hadn't release RC, and we hadn't documented dataclass module yet.
How about making "dataclass" module as porvisional state?

I think we've learned lesson that we shouldn't use typing in modules other than 
typing...


> But I am open to what string prefixes we should allow.

If it is really needed, I think we should only allow "typing.ClassVar".
All other prefixes seems ambiguous.

--

___
Python tracker 

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

[issue33464] AIX and "specialized downloads" links

[Michael Felt]

New submission from Michael Felt :

I struggled with how python was packaged by others. Key points being: many 
dependencies, no assurance you could uninstall the dependencies and/or python.

A little over two years ago I started looking for 'root causes' of problems 
that potential users of python (on AIX) were having.

To me it is clear that the packaging problems from two years back are just as 
alive as they were in 2015 and 2016. Since then I have learned a few things 
about python (thanks to all who helped). I would like to apply this knowledge 
and provide a 'cleaner' packaging of Python for AIX - both Python3 and Python2.

I would appreciate my downloadable packages being listed on the "other" 
downloads list. If you wanted to make it complete - the other two I know of are 
Perzl's site (http://www.perzl.org/aix/index.php?n=main.python), and, of 
course, the IBM AIX Toolbox 
(https://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html#P).

I have involved (currently managed and run it) an AIX portal since 2001 - 
http://www.rootvg.net. The last 5 or 6 years I have been hosting a second 
portal I call "aixtools".

In short, I hope you will consider adding - at least - my aixtools wiki pages: 
http://www.aixtools.net/index.php/python3 and 
http://www.aixtools.net/index.php/python (for python2).

Many thanks for your consideration,

Michael

--
messages: 316395
nosy: Michael.Felt, gvanrossum
priority: normal
severity: normal
status: open
title: AIX and "specialized downloads" links
versions: Python 2.7, Python 3.4, Python 3.5, 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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Eric V. Smith]

Eric V. Smith  added the comment:

We can't break the API at this point in the release cycle. But I am open to 
what string prefixes we should allow.

--

___
Python tracker 

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

[issue33461] json.loads(encoding=) does not emit deprecation warning.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm wondering if it can be removed at all. Maybe it was left in issue4136 due 
to oversight.

--
nosy: +bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[INADA Naoki]

INADA Naoki  added the comment:

"t.ClassVar" looks ugly...
How about dropping ClassVar support of dataclass module for 3.7?

--
nosy: +inada.naoki

___
Python tracker 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Eric V. Smith]

Eric V. Smith  added the comment:

The more I think about this, the more I think Łukasz is correct that just 
checking for strings starting with "ClassVar", "typing.ClassVar", or 
"t.ClassVar" is the correct thing to do. This is the change he made in 
https://github.com/python-attrs/attrs/pull/367.

In some private email I had discussed extracting the module name, if any, from 
the string annotation, and looking it up in sys.modules. This doesn't buy you 
much because you have to know how the caller imported typing. If they used 
"import typing as t", then you can't look up "t" in sys.modules. You could do 
some horrible frame trick to find out what the caller knew as "t", but that 
still won't work in plenty of cases. I don't want to use a complex solution 
that still doesn't work in all cases, and would indeed work in fewer places 
than just examining the string. The only name we could reliably detect is 
"typing.ClassVar", all others wouldn't be in sys.modules correctly.

So, that leaves us with just looking at the string and guessing what the caller 
meant. I think the three strings that Łukasz suggested are good enough.

This will need to be well documented. The documentation should note that things 
like this will break:

from __future__ import annotations
from typing import ClassVar as CV
@dataclass
class C:
x: CV

x will not be a class variable here, since @dataclass will see the annotation 
as "CV" and not know that it means typing.ClassVar.

InitVar has a similar problem. What strings to use there? "InitVar" and 
"dataclasses.InitVar", of course. But maybe "dc.InitVar"? It's hard to say with 
no in-the-field usage examples to search for. I'll start with just the first 
two strings.

I really don't want to use regexes here. But a refinement would be to not just 
use .startswith, and instead use a word boundary. After all, "ClassVarOfMine" 
should probably not be considered a ClassVar. I'll leave that issue for another 
day, though.

I'll have a patch ready before the sprints are over.

--
assignee:  -> eric.smith

___
Python tracker 

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

[issue33346] Syntax error with async generator inside dictionary comprehension

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think this can be fixed simpler. Currently a comprehension become 
asynchronous in two cases:

1. Explicitly, when it contains 'async for'. This is visible at AST level.

2. Implicitly, when any of inner expressions contains 'await'.

But asynchronous comprehensions should behave the same way as 'await'. I think 
that a comprehension should be made implicitly asynchronous if any of inner 
expressions contains explicit or implicit asynchronous comprehension. This is 
implemented in PR 6766.

--
nosy: +gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue33346] Syntax error with async generator inside dictionary comprehension

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +6452
stage:  -> patch review

___
Python tracker 

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

[issue33443] Typo in Python/import.c

[Yuki Wakisaka]

Change by Yuki Wakisaka :


--
versions:  -Python 3.8

___
Python tracker 

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

[issue15443] datetime module has no support for nanoseconds

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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