Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33211>
___
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>
___
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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
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:
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: +6035
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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:
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
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
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/
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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +5961
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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:
> 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:
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:
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 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 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:
> 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:
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
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 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
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:
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:
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/
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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +gvanrossum
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33061>
___
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:
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:
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
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
resolution: -> not a bug
stage: -> resolved
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
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
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:
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:
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 <levkivs...@gmail.com> added the comment:
I am sick now, so can't work on this. There is a small chance I will be able to
work on this issue this week. Is it possible to fix this in 3.7b3?
--
___
Python tracke
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Thank you, Ned!
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Here is the situation for 3.6 and before:
Generic classes are all actual class objects, so they are pickled as immutable.
However this creates a problem, parameterized generics, such as `List[int]`
_cannot_ be pickled in 3.6 and
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 3fb813d2c67fe28cc98ae51e53a6890294b6e423 by Ivan Levkivskyi
(Terry Jan Reedy) in branch 'master':
bpo-31333: Fix typo in whatsnew/3.7.rst (GH-5744)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 0442de5ad7835814d60f46c22a22942abb101aef by Ivan Levkivskyi in
branch '3.7':
bpo-25988: Emit a warning when use or import ABCs from 'collections'. (GH-5734)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 38928992885d8a04b7188abdba3b04f350bde32d by Ivan Levkivskyi in
branch '3.7':
bpo-31333: Re-implement ABCMeta in C (GH-5733)
https://github.com/python/cpython/commit/38928992885d8a04b7188abdba3b04f350
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +5515
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25988>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +5514
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31333>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
FWIW, this is fixed in 3.7 by PEP 560, providing a separate fix for 3.6 is not
easy, and you have a good workaround, so I propose to close this issue.
--
resolution: -> fixed
stage: -> resolved
status: op
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
FWIW, this is fixed in 3.7 by PEP 560. I don't think we will be able to get rid
of `sys._getframe` workaround on 3.6, so I propose to just close this.
--
dependencies: -Provide a way to check for *real* typing.Union ins
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 03e3c340a0156891a036d6dbdb9e348108826255 by Ivan Levkivskyi in
branch 'master':
bpo-31333: Re-implement ABCMeta in C (#5273)
https://github.com/python/cpython/commit/03e3c340a0156891a036d6dbdb9e348108
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Isn't 800 lines of C code too high price for speeding up ABCs creation?
800 lines of C code is not something hard to notice, so I suppose the answer is
obvious for all people involved in the work on PR :-)
> ...this c
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I wanted to say implicitly that I like the idea, and that we should figure out
details in a PR. But of course if someone is against this, then we should wait
with a PR.
--
nosy: +gvan
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
There is a third party library on PyPI called typing_inspect that provides thin
wrappers around internal APIs to get lots of useful information about generics
and other special types in typing.
If there will be more request
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
This is a rather small change, so probably it would be easier to discuss it in
a PR.
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> Do you think it should be added to the What's New? page for 3.7?
I leave this up to Łukasz.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Ivan Levkivskyi <levkivs...@gmail.com>:
This should include:
* Short documentation PR for `__mro_entry__` and `__base_subclass__` methods.
* The `__class_getitem__` C API calling convention (with motivation, many
classes are implemented in C but are generic in nature
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
OK, I will close this issue, and open separate issues for documentation, Union,
etc.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pyth
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
https://github.com/python/typing/issues/512 and
https://github.com/python/typing/issues/511 are first issue (they are closely
related to each other). This is not directly related to PEP 560, but changes in
typing b
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I think all the critical things have been implemented/fixed. There are
unfortunately no docs yet (my fault), also there are two bugs related to PEP
560, but they are not new, they also exist in Python 3.6.
I am however m
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +5117
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I have not seen this for quite some time so I'm closing this as fixed.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset d911e40e788fb679723d78b6ea11cabf46caed5a by Ivan Levkivskyi in
branch 'master':
bpo-32226: PEP 560: improve typing module (#4906)
https://github.com/python/cpython/commit/d911e40e788fb679723d78b6ea11cabf46
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> BTW, would you update the PEP status to Final?
Good point, here is the PR https://github.com/python/peps/pull/554
--
___
Python tracker <rep...@bugs.python.org>
<https
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
There is also another corner case to consider:
class C:
exec('x: int')
assert C.__annotations__ == {'x': int}
assert __annotations__ == {}
I am not sure this one will be covered correctly.
But the main argument here is s
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
There are several corner cases. For example consider this code:
>>> class C:
... del __annotations__
... x: int
Currently this correctly raises NameError, with your replacement it will
instead stick {'x': int
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Serhiy,
I am sorry for a delay, I have recently moved to another country, this is why I
have not much time. I will try to work on this weekend. Here are some points
where you can be helpful:
* Make a short documentat
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32513>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
@Eric
> I'm closing this, and will open another issue to raise an error for: ...
I think we also need a separate issue for not overriding __repr__ etc, if
'__repr__' in cls
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32471>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32473>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so
> the type checker can be made to understand. PEP 557 allows omitting ClassVar
> in case you don't care about type checkers. So I think
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Just to clarify the previous comment, I still think that flagging this
@dataclass
class C:
x = field()
is important, since simply ignoring a ``field()`` will be too confusing
(especially for ``attrs`` users).
The previous c
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> I liked the original design better, where things without annotations would
> just be ignored. What changed?
With the original proposal the ignored variables without annotations will
behave as class variables. Thi
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> I'm not sure I understand the distinction.
Initially I thought about only flagging code like this:
@dataclass
class C:
x = field()
But not this:
@dataclass
class C:
x = 42
Now I think we should probably flag both
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
A possible question here is should we give an error for any non-callable name
in `__dict__` which is not in `__annotations__` or only for `Field`s?
After some thinking I am actually leaning towards the first option.
-
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
I have also noticed this problem and I like the idea. It appeared some time ago
on python-ideas, but no one has written a patch.
--
nosy: +levkivskyi
___
Python tracke
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Stefan, your last example is formally speaking OK, if one reads the "Execution
model" literally. The original example is however too ambiguous, so it is good
that it triggers an error.
I think there is a chance to i
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +4800
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32226>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32320>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Interesting. I have noticed similar when I tried to add a fast loop proposed by
Serhiy. It should save at least one pointer comparison for base class, but
sometimes it actually led to slow-downs (although very small). How can one
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 2b5fd1e9ca9318673989e6ccac2c8acadc3809cd by Ivan Levkivskyi in
branch 'master':
bpo-32226: Implementation of PEP 560 (core components) (#4732)
https://github.com/python/cpython/
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Travis build on master successful, so I am closing this issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep.
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
New changeset 5364b5cd7571f2dfa75acd37b388c14ac33fef73 by Ivan Levkivskyi in
branch 'master':
bpo-32225: Implementation of PEP 562 (#4731)
https://github.com/python/cpython/commit/5364b5cd7571f2dfa75acd37b388c14ac3
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Guido, what is your preference for the implementation of ``__class_getitem__``:
``PyObject_GetItem`` (current one) or ``type.__getitem__`` (old one)? Can we
just go ahead with the version you like and then re-consider if some obje
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
> As for __class_getitem__, why not implement type.__getitem__ instead of
> hacking PyObject_GetItem()?
This question was raised by Mark Shannon on python-dev. Actually, my initial
implementation did exactly this, but I
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32284>
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
nosy: +levkivskyi
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32216>
___
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Idea looks interesting (like a basic runtime @overload). My expectation is that
some changes are necessary in mypy for this to work properly.
Another (minor) problem is that this creates a circular dependency functools
<
Ivan Levkivskyi <levkivs...@gmail.com> added the comment:
Oops something wrong happened.
--
nosy: +gvanrossum
stage: patch review ->
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +4635
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Ivan Levkivskyi <levkivs...@gmail.com>:
As discussed before, there will be two PRs. One for the core components, and
the second one (large) for typing updates. I will open the first PR shortly.
--
nosy: +gvanrossum
___
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: levkivskyi
components: Interpreter Core, Library (Lib)
nosy: levkivskyi
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement PEP 560: Core support for typing module and generic type
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
keywords: +patch
pull_requests: +4634
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
assignee: levkivskyi
components: Interpreter Core
nosy: levkivskyi
priority: normal
severity: normal
stage: patch review
status: open
title: Implement PEP 562: module __getattr__ and __dir__
type: enhancement
versions: Pyth
Change by Ivan Levkivskyi <levkivs...@gmail.com>:
--
pull_requests: +4621
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28556>
___
301 - 400 of 680 matches
Mail list logo
