Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Serhiy, for example `issubclass(typing.MutableMapping, typing.Mapping)` returns
`True` while neither of those two are actual class objects. These relationships
are kept mostly so that `typing.*` can be used as a drop-in repla
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Yes, this is because subclassing `typing.NamedTuple` is not an actual
subclassing, but is just a syntactic sugar for calling
`collections.namedtuple`. A discussion about allowing subclassing/extending
named tuples previously ap
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I would say it is too late. `typing.NamedTuple` is out there for more than a
year and is quite actively used. A search on GitHub shows thousands of files
that import `typing.NamedTuple` and a macroscopic fraction of tho
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Apart from the fact that it's too late, if you had to do it over again,
could it be done as a class decorator?
Yes, this could be done as a decorator which would replace the original class
with a named tuple after i
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
To be honest I am still undecided on this. In principle, I am OK with status
quo, but I am also OK, with the PR that will prohibit non-classes. I am a bit
worried that it may break some existing code, so it is probably not f
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
This is actually an intended behaviour. Moreover, the implicit optionality of
arguments that default to `None` is deprecated and will be removed in one of
the future versions. (Note that since typing module is still provi
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> not a bug
stage: -> resolved
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Apparently there is another type with a similar problem -- DefaultDict.
Will fix this now.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 2a363d2930e29ec6d8a774973ed5a4965f881f5f by Ivan Levkivskyi in
branch 'master':
bpo-32873: Remove a name hack for generic aliases in typing module (GH-6376)
https://github.com/python/cpython/
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +6088
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32873>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Ivan Levkivskyi <levkivs...@gmail.com> 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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33211>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Ivan Levkivskyi <levkivs...@gmail.com> 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
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
This is not a bug but an explicit design decision. Generic classes are _static_
typing concept and therefore are not supposed to work freely with _dynamic_
class creation. During discussion of PEP 560 it was decided that there
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
https://devguide.python.org/ will help you.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> If we're going to call new_class in make_dataclass, then we should change the
> signature of make_dataclass to have the new_class parameters.
Why? I think we should care about what API/signature is reasonable/typical for
New submission from Ivan Levkivskyi <levkivs...@gmail.com>:
Currently this code
def f(x: int = None):
pass
get_type_hints(f)
returns {'x': Optional[int]}. I propose to abandon this behaviour. Although
there is not yet a definitive decision about this aspect of PEP 484, see
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +5961
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
OK, let us then keep this issue as a remainder that we need to update the
runtime behaviour when the static one changes.
--
___
Python tracker <rep...@bugs.python.or
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Thanks Will!
I think this is actually a different (although very similar issue). It looks
like it is easy to fix. Could you please open a separate issue (and mention it
here)? Also could you please provide a typical exampl
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +6066
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
This is not a bug, but a misunderstanding:
* First, ABCMeta doesn't have `__prepare__`, it is just `type.__prepare__`
* Second, the third argument to `types.new_class` is called `kwds` for a
reason. It is not a namespace like in
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +6035
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 834940375ae88bc95794226dd8eff1f25fba1cf9 by Ivan Levkivskyi in
branch 'master':
bpo-32873: Treat type variables and special typing forms as immutable by copy
and pickle (GH-6216)
https://github.com/python/cpython/
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +gvanrossum
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33061>
___
New submission from Ivan Levkivskyi <levkivs...@gmail.com>:
This is clearly a bug. Would you like to make a PR?
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I think it makes sense to also fix this in 3.7. I will prepare a backport now.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +5918
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33061>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I am still -1 on changing this in Python 3.7, unless Guido wants this in 3.7,
if yes, then we can go ahead. Otherwise, I think we can consider just merging
this into master, in this case I would switch to the PR to discuss the d
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Would it be worthwhile to show an example of a subclass that overrides or
> extends __new__?
I think yes. I would actually add few examples what could (and maybe also
couldn't) be done with
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 40472dd42de4f7265d456458cd13ad6894d736db by Ivan Levkivskyi (jab)
in branch 'master':
bpo-33018: Improve issubclass() error checking and message. (GH-5944)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss
Islington (bot)) in branch '3.7':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I am closing this for now. We can re-open it later if problems will appear in
3.7.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pyth
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> you'll notice that's an error?
Yes, but there are other scenarios, like using `init=False` or updating
existing class definition and forgetting to update call sites (which will still
work), etc.
What would we lose by not
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 5d8bb5d07be2a9205e7059090f0ac5360d36b217 by Ivan Levkivskyi (Miss
Islington (bot)) in branch '3.7':
bpo-32999: Revert GH-6002 (fc7df0e6) (GH-6189) (GH-6190)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 4573820d2a9156346392838d455e89f33067e9dd by Ivan Levkivskyi
(aetracht) in branch 'master':
bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Some part of the discussion is in https://bugs.python.org/issue32428
I still think it is important to flag things like this as an error:
@dataclass
class C:
x = field()
This is a big bug magnet. Especially taking into a
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Would you merge this into master?
OK, I played with this a bit and it looks good. There is however a merge
conflict now, and a NEWS item is missing. I will leave a comment
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
The typing repo PR is not merged yet, but I am closing this here, the remainder
is tracked in typing repo.
--
resolution: -> fixed
stage: patch review -> resolved
status: op
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset ac5602746ed39ca6591e98e062e587121ac71371 by Ivan Levkivskyi in
branch '3.7':
bpo-33061: Add missing 'NoReturn' to __all__ in typing.py (GH-6127) (#6162)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Actually, the behaviour when __suclasscheck__ returns True for non-class
objects may be used by some code. Even typing module did this, I tried to
remove as much as possible of this, but I think there may be few such
situation
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:
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 othe
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 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/c8a8d6b347d5a6899feb7c810d28f22f3cb151b8
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:
Yes, this is expected, you should use ``super().__setattr__()``.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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: closed -
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35143>
___
___
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
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/cpython/commit
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:
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/5eea0ad50c32d38909ff4e29309e2cc3c6ccb2c0
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
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
Change by Ivan Levkivskyi :
--
assignee: -> levkivskyi
___
Python tracker
<https://bugs.python.org/issue34700>
___
___
Python-bugs-list mailing list
Un
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue34776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
keywords: +patch, patch
pull_requests: +11329, 11330
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +11329
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33416>
___
_
Change by Ivan Levkivskyi :
--
keywords: +patch, patch, patch
pull_requests: +11329, 11330, 11331
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35766>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
New changeset 9932a22897ef9905161dac7476e6976370e13515 by Ivan Levkivskyi in
branch 'master':
bpo-33416: Add end positions to Python AST (GH-11605)
https://github.com/python/cpython/commit/9932a22897ef9905161dac7476e6976370e13515
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
__
Python tracker
<https://bugs.python.org/issue35540>
__
___
Python-bugs-list mailing list
Unsub
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 docs
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/68b56d02ef20479b87c65e523cf3dec1b7b77d40
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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:
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:
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 during
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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/cpython/commit
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/cpython/commit
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35717>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
FYI, I started working on this. I will have PR ready end of next week.
Serhiy, I don't think we should keep both this and issue22616 open. Which one
would you prefer to close?
--
___
Python tracker
<ht
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue35631>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
Closed as superseded by https://bugs.python.org/issue33416
--
superseder: -> Add endline and endcolumn to every AST node
___
Python tracker
<https://bugs.python.org/issu
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue22616>
___
___
Ivan Levkivskyi added the comment:
> I'm sure we will find use cases though I doubt that many compiler syntax
> errors would benefit (since a syntax error means that we don't have a
> completely matched grammar rule).
This is mostly useful for code analysis tools and IDEs.
&g
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 about this
Ivan Levkivskyi added the comment:
New changeset 62c35a8a8ff5854ed470b1c16a7a14f3bb80368c by Ivan Levkivskyi in
branch 'master':
bpo-35814: Allow same r.h.s. in annotated assignments as in normal ones
(GH-11667)
https://github.com/python/cpython/commit
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
Buildbots are green, this can be now closed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
It looks like an opposite side of https://github.com/python/typing/issues/508
(I wanted to work on it, but never had time to, sorry).
This question appeared couple times before, and I think there are pros and cons
for both returning a ForwardRef
Ivan Levkivskyi added the comment:
+1 from me.
There are two ways to enable this:
* Add -OOO that would remove all three: asserts, docstrings, annotations
* Add separate --O-asserts --O-docstrings --O-annotations (or similar)
I think I like the second option more.
@cary Please note that our
Change by Ivan Levkivskyi :
--
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/issue36470>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +gvanrossum, levkivskyi
___
Python tracker
<https://bugs.python.org/issue36466>
___
___
Python-bugs-list mailing list
Unsub
Ivan Levkivskyi added the comment:
Mypy already takes first overload for ambiguous arguments. This example is
however genuinely unsafe from the static typing point of view. Please read the
docs
https://mypy.readthedocs.io/en/latest/more_types.html#type-checking-the-variants
Ivan Levkivskyi added the comment:
I totally agree with Serhiy
--
___
Python tracker
<https://bugs.python.org/issue36042>
___
___
Python-bugs-list mailin
Ivan Levkivskyi added the comment:
Good idea! This should be easy to fix/update, this was initially discussed in
https://github.com/python/typing/issues/339.
--
___
Python tracker
<https://bugs.python.org/issue36
401 - 500 of 680 matches
Mail list logo
