Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35717>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
I think this can be closed now. Whether to merge doc-fix backport to now
security-only 3.6 branch is up to Ned.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pytho
Ivan Levkivskyi added the comment:
New changeset 31ec52a9afedd77e36a3ddc31c4c45664b8ac410 by Ivan Levkivskyi
(Ville Skyttä) in branch 'master':
bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396)
https://github.com/python/cpyt
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35631>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
__
Python tracker
<https://bugs.python.org/issue35540>
__
___
Python-bugs-list mailing list
Unsub
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 68b56d02ef20479b87c65e523cf3dec1b7b77d40 by Ivan Levkivskyi (Ismo
Toijala) in branch 'master':
bpo-35341: Add generic version of OrderedDict to typing (GH-10850)
https://github.com/python/cpython/commit/68b56d02ef20479b87c65e523cf3de
Ivan Levkivskyi added the comment:
I would propose to keep this one open as a superseding
https://bugs.python.org/issue23864 and close the latter (assuming we are not
going to make all classes protocols, we I think we really shouldn't, and
instead we should improve the
Ivan Levkivskyi added the comment:
Also typing is technically still provisional, we can backport this to previous
versions (at least to 3.7).
--
___
Python tracker
<https://bugs.python.org/issue35
Ivan Levkivskyi added the comment:
Yes, since we already have `DefaultDict`, `Counter`, and `ChainMap` from
collections, we can also add `OrderedDict`.
--
___
Python tracker
<https://bugs.python.org/issue35
Ivan Levkivskyi added the comment:
New changeset f71a5922916abd6cc7bf7d99ed4715b6e96e5981 by Ivan Levkivskyi (Ismo
Toijala) in branch '3.7':
bpo-34921: Allow escaped NoReturn in get_type_hints (GH-9750) (GH-10772)
https://github.com/python/cpyt
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
issue22616 is a bit different (proposing line/column ranges instead of just
endline/endcolumn). I am happy to close this one in favor of issue22616 if we
agree that we will go with endline/endcolumn.
I can't guarantee, but likely I will work on this d
Ivan Levkivskyi added the comment:
I am with Inada-san actually. I would go as far as saying that
@cached_property
@abstractmethod
def something(): ...
should unconditionally raise on definition. Mostly because this is just
misleading. This declaration doesn't guarantee tha
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
The separation may look arbitrary, but the idea is quite simple. Only those
classes with few methods support structural checks. Those classes have few
independent abstract methods (or even just one method), while in classes with
large APIs like `Sequence
Change by Ivan Levkivskyi :
--
nosy: -miss-islington
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 0bee3c36d406e47fa9f99cfc1e07b701512c4f3f by Ivan Levkivskyi
(Denis Osipov) in branch 'master':
bpo-35119: Fix RecursionError in example of customizing module attribute
access. (GH-10323)
https://github.com/python/cpyt
Ivan Levkivskyi added the comment:
Ah, sorry, I didn't understand this was a documentation issue. Please feel free
to submit a PR that fixes the example to use `super().__setattr__()`.
--
resolution: not a bug ->
stage: resolved -> needs patch
status: clo
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35143>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
Yes, this is expected, you should use ``super().__setattr__()``.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
Serhiy, thanks for benchmarks and good suggestions!
> If make NewType a class, I would make the repr looking like a call
This is a nice idea, it indeed looks better. We can probably also use
`_type_repr()` helper for the argument (for consiste
Ivan Levkivskyi added the comment:
New changeset c8a8d6b347d5a6899feb7c810d28f22f3cb151b8 by Ivan Levkivskyi
(Sebastian Rittau) in branch 'master':
bpo-35089: Don't mention typing.io and typing.re (GH-10173)
https://github.com/python/cpython/commit/c8a8d6b347d5a6899feb7c810
Ivan Levkivskyi added the comment:
OK, so now we have two "competing" PRs. I think I like Serhiy's PR a bit more,
since it is simpler. I would propose to look at benchmarks and then decide. Are
there any other factors I am missing for choosing one or
Ivan Levkivskyi added the comment:
I think we can just go ahead and allow this. If there is a volunteer, please go
ahead, otherwise I will try to find time for this myself.
--
___
Python tracker
<https://bugs.python.org/issue34
Ivan Levkivskyi added the comment:
Hm, I think this should be allowed. The formulation in the docs is not very
clear, but the wording in the PEP clarifies the intention. Indeed, only
annotations at the same scope with global declarations should be prohibited.
So I think this is a bug
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0 by Ivan Levkivskyi (Noah
Wood) in branch 'master':
bpo-34921: Allow escaped NoReturn in get_type_hints (GH-9750)
https://github.com/python/cpython/commit/5eea0ad50c32d38909ff4e29309e2c
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue34776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
assignee: -> levkivskyi
___
Python tracker
<https://bugs.python.org/issue34700>
___
___
Python-bugs-list mailing list
Un
Ivan Levkivskyi added the comment:
I think there is also a fourth option: add a flag to `get_type_hints()` that
will guard evaluation of forward references, as proposed in
https://github.com/python/typing/issues/508. If the evaluation of a "forward
reference" raises an error, th
Ivan Levkivskyi added the comment:
OK, lets close this for now. We will see if there are any other situations.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
This was a conscious decision (i.e we decided that the old inconsistency is a
bug). See https://bugs.python.org/issue33018 for previous discussion. What is
your use case? If it is critical, we can reconsider this
Ivan Levkivskyi added the comment:
> [..] but I think it's the best we can do. It's consistent with any other
> class derived from tuple or list: [...]
I agree with this argument. Sorry for delay with my response and thank you Eric
for taking care
Ivan Levkivskyi added the comment:
> but even then types in the typing could themselves implement
> `__instancecheck__` and `__subclasscheck__` and retain the old behavior.
It doesn't work that way. `__instancecheck__` and `__subclasscheck__` tweaks
the behaviour of superclas
Ivan Levkivskyi added the comment:
It was a deliberate decision. You can find some motivation in PEP 560, and yes
we used provisional status here. It was a hard decision, but we decided that
giving up few percent of backwards compatibility is a reasonable price for up
to 5x performance
Ivan Levkivskyi added the comment:
TBH, I don't like this idea. Consider this situation:
@singledispatch
def what(x: Iterable) -> None:
print('general case')
@what.register
def _(x: Sequence[int]) -> None:
print('special case'
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue34499>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
> Could we revert abstract types in `typing` to respond True to
> `isinstance(..., type)` again?
No, making them classes will cause significant performance penalty (I don't
remember numbers now, but importing `typing` may be twice slower). Plus
Ivan Levkivskyi added the comment:
This is why we have 4 months of betas :-)
On one hand making objects in `typing` module not classes was intentional, but
on another hand this use case looks totally fine.
I would say we could update the check in `functools` to accept more things. I
am
Change by Ivan Levkivskyi :
--
Removed message: https://bugs.python.org/msg323770
___
Python tracker
<https://bugs.python.org/issue34422>
___
___
Python-bug
Ivan Levkivskyi added the comment:
This is an intentional change. It would be a bad idea to use `__name__` instead
of what is currently `_name`, because semantics is subtly different. Also the
fact that types in typing module used to be actual class objects was an
implementation detail
Ivan Levkivskyi added the comment:
Oh I just re-read my comment and there are so many typos that I will write a
new one, sorry.
--
___
Python tracker
<https://bugs.python.org/issue34
Ivan Levkivskyi added the comment:
This is an intentional change. It would be a bad idea to use `_name` instead of
`__name__`, because semantics is subtly different. Also the fact that type in
typing object used to be actual class object was an implementation detail (also
typing is still
Ivan Levkivskyi added the comment:
Eric, I like your solution. It is probably not perfect, but at least it solves
the existing problem without introducing obvious problems.
Neil, your way will not work since named tuples don't have NamedTuple in their
MROs:
CustomNT.mro == (CustomNT,
Ivan Levkivskyi added the comment:
The problem with this solution is that it may brea (relatively common) use case
of tuple valued fields, e.g.:
>>> tuple(*[x for x in a])
Traceback (most recent call last):
File "", line 1, in
TypeError: tuple expected at most
Ivan Levkivskyi added the comment:
OK, so the crux of the bug is this difference:
>>> a = (1, 2)
>>> tuple(x for x in a)
(1, 2)
>>> NamedTupleAttribute(x for x in a)
NamedTupleAttribute(example= at 0x10e2e52a0>)
A potential solution would be to either
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue34363>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
FWIW I am rather -1 on this. More detailed errors messages are always good, but
in the proposed form it looks more like a distraction. I think just showing a
fully qualified name of the function would be both more concise and more
informative, since the
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 336c945858055059a65134d4c501a85037d70d99 by Ivan Levkivskyi
(Ville Skyttä) in branch 'master':
bpo-34336: Don't promote possibility to leave out typing.Optional (#8677)
https://github.com/python
Ivan Levkivskyi added the comment:
> 3.7 is less convenient and less consistent
Taking into account that internal API is something one should never use, I
don't think these terms apply here. Anyway, we will provide some helpers for
external use in one of the next
Ivan Levkivskyi added the comment:
Oh yes, this is a "stateful" bug. It will not appear if run in isolation. Btw,
the underlying bug will be worse with `from __future__ import annotations`, so
it would make sense to fix this sooner than later.
--
nosy: +lu
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.o
Ivan Levkivskyi added the comment:
Adding Yury as an inspect expert. I don't think this is something urgent, we
can probably postpone this to 3.7.1.
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/is
Ivan Levkivskyi added the comment:
Hm, replacing the return with a random string, this leads to another crash:
Traceback (most recent call last):
File "", line 1, in
File "/Users/ilevkivskyi/src/cpython/Lib/_sitebuiltins.py", line 103, in
__call__
return pydo
Ivan Levkivskyi added the comment:
I think this can be closed now.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 97b523db7c79c18c48516fba9410014d9896abc4 by Ivan Levkivskyi
(Serhiy Storchaka) in branch 'master':
bpo-33652: Remove __getstate__ and __setstate__ methods in typing. (GH-7144)
https://github.com/python/cpyt
Ivan Levkivskyi added the comment:
Yes, these are just legacy from times when TypeVars were serialized by value,
not by identity like now. I think it should be safe to remove them. Would you
like to make a PR?
--
___
Python tracker
<ht
Ivan Levkivskyi added the comment:
New changeset 09f3221fbbf72692308149054e4f7668b08b22eb by Ivan Levkivskyi
(Serhiy Storchaka) in branch 'master':
bpo-33652: Improve pickle support in the typing module. (GH-7123)
https://github.com/python/cpyt
Ivan Levkivskyi added the comment:
New changeset 717204ffcccfe04a34b6c4a52f0e844fde3cdebe by Ivan Levkivskyi
(Andrés Delfino) in branch '3.6':
[3.6] bpo-32769: A new take on annotations/type hinting glossary entries
(GH-6829) (GH-7128)
https://github.com/python/cpyt
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33649>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset 6e33f810c9e3a549c9379f24cf1d1752c29195f0 by Ivan Levkivskyi
(Andrés Delfino) in branch 'master':
bpo-32769: A new take on annotations/type hinting glossary entries (GH-6829)
https://github.com/python/cpyt
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +6746
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33616>
___
___
Py
Ivan Levkivskyi added the comment:
This is now fixed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33569>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33616>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
New changeset 09ca5906b7d1619b7efed0bebb6f3c424fe3d83b by Ivan Levkivskyi (Miss
Islington (bot)) in branch '3.7':
bpo-28556: Don't simplify unions at runtime (GH-6841) (GH-6979)
https://github.com/python
Ivan Levkivskyi added the comment:
New changeset f65e31fee3b55dfb6ed5398179d5c5d6b502dee5 by Ivan Levkivskyi in
branch 'master':
bpo-28556: Don't simplify unions at runtime (GH-6841)
https://github.com/python/cpython/commit/f65e31fee3b55dfb6ed539817
Change by Ivan Levkivskyi :
--
pull_requests: +6624
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
Yes, local annotations are important and should be mentioned (maybe even with
an example).
--
___
Python tracker
<https://bugs.python.org/issue32
Ivan Levkivskyi added the comment:
What I think Guido might mean is that some type annotations are not strictly
speaking type hints. For example, `dataclasses.InitVar`, is not really a type,
it is just a way to indicate how constructor should be constructed. I could see
similar potential
Ivan Levkivskyi added the comment:
> ... but annotations are a slightly more general concept because they may be
> used for other purposes than to indicate the type of a variable ...
Yes, I agree.
--
___
Python tracker
<https://bugs.p
Ivan Levkivskyi added the comment:
Yes, all this also applies to 3.6.
--
___
Python tracker
<https://bugs.python.org/issue32769>
___
___
Python-bugs-list mailin
Ivan Levkivskyi added the comment:
Maybe we can consider backporting this to 3.7? Andrés, if you think it makes
sense, you can cherry-pick the commit and open a PR against 3.7 branch.
--
___
Python tracker
<https://bugs.python.org/issue32
Ivan Levkivskyi added the comment:
New changeset f2290fb19a9b1a5fbeef0971016f72683e8cd1ad by Ivan Levkivskyi
(Andrés Delfino) in branch 'master':
bpo-32769: Write annotation entry for glossary (GH-6657)
https://github.com/python/cpython/commit/f2290fb19a9b1a5fbeef0971016f72
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33421>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
pull_requests: +6446
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
pull_requests: +6445
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
This is now fixed on master by
https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc10a58c
(the comment is updated).
--
resolution: -> fixed
stage: -> resolved
status: open -&g
Ivan Levkivskyi added the comment:
New changeset 43d12a6bd82bd09ac189069fe1eb40cdbc10a58c by Ivan Levkivskyi in
branch 'master':
bpo-28556: Minor fixes for typing module (GH-6732)
https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40
Change by Ivan Levkivskyi :
--
pull_requests: +6423
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
New changeset bd5f96581bf23f6d05fc106996428a8043b6b084 by Ivan Levkivskyi in
branch 'master':
bpo-32717: Document PEP 560 (GH-6726)
https://github.com/python/cpython/commit/bd5f96581bf23f6d05fc106996428a
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +6419
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Ivan Levkivskyi added the comment:
> Bug or not this is not going to change without a PEP, so I'm not sure it's a
> good idea to keep this issue open.
I agree this requires a PEP. I would like to keep this open as a place for
pre-PEP discussions among those interested (and a
Change by Ivan Levkivskyi :
--
assignee: -> levkivskyi
___
Python tracker
<https://bugs.python.org/issue33315>
___
___
Python-bugs-list mailing list
Unsubscrib
Ivan Levkivskyi added the comment:
Yes, the comment needs to be updated, but as you said, no guaranties about
undocumented dunder attribute. We tried to preserve as much of the API as
possible in 3.7 after PEP 560, but something needs to be sacrificed (especially
in the purely internal API
Ivan Levkivskyi added the comment:
> Could you please product a draft PR showing how that would work? It might
not be accepted right away but it would be useful to have.
It is not 100% clear to whom this was addressed. Anyway, Semyon, if you don't
have time, then I can make a s
New submission from Ivan Levkivskyi :
Some Python tools (in particular I am interested in type checkers) will benefit
from knowing where a given expression ends to indicate/highlight location of an
error in the source code. Other tools and IDEs may have also some other
benefits. Currently
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue7>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
See https://bugs.python.org/issue33346 for yet another example where implicit
function scope complicates life.
--
___
Python tracker
<https://bugs.python.org/issue3
Ivan Levkivskyi added the comment:
My guess this is a consequence of the implicit function scope in
comprehensions, see https://bugs.python.org/issue3692
I would say a proper solution would be to drop the implicit function scope in
favour of other mechanisms, but this will require some work
Ivan Levkivskyi added the comment:
Mariatta,
> While I understand why it behaves the way it is now, but it seems wrong
> behavior. Perhaps we should look into finding a solution.
I am all in favour of dropping implicit function scope in comprehensions
(mostly because of weirdnes
Ivan Levkivskyi added the comment:
I think this issue appeared previously on typing tracker. The current
recommendation is to escape problematic annotations with quotes:
q: 'Queue[int]'
I don't think it will be added to typing, because following this way typing
will gro
Ivan Levkivskyi added the comment:
> I was hoping to see if this was seen as a reasonable patch that might be
> accepted.
I didn't look carefully but superficially it looks reasonable, so it is worth
trying.
> Also, while I think it would be nice, I take it a patch for
201 - 300 of 681 matches
Mail list logo