Ivan Levkivskyi 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 for 3.7
Ivan Levkivskyi 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 provisional, this
will likely happen
Change by Ivan Levkivskyi :
--
resolution: -> not a bug
stage: -> resolved
___
Python tracker
<https://bugs.python.org/issue33075>
___
___
Python-bugs-
Change by Ivan Levkivskyi :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33075>
___
___
Python-bugs-list mailing list
Unsubscrib
Ivan Levkivskyi 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 appeared in https://github.com
Ivan Levkivskyi 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 those use it with
the class syntax. I
Ivan Levkivskyi 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 inspecting `__annotations__` and `
Change by Ivan Levkivskyi :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue33061>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ivan Levkivskyi :
This is clearly a bug. Would you like to make a PR?
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33
Ivan Levkivskyi 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/commit/4573820d2a9156346392
Ivan Levkivskyi 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 details.
--
nosy
Ivan Levkivskyi 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 n
Ivan Levkivskyi added the comment:
I think it makes sense to also fix this in 3.7. I will prepare a backport now.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Ivan Levkivskyi :
--
pull_requests: +5918
___
Python tracker
<https://bugs.python.org/issue33061>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi 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 account that attrs behave in
the
Ivan Levkivskyi 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 in the PR.
--
___
Python trac
Ivan Levkivskyi 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/commit/40472dd42de4f7265d456458cd13ad
Ivan Levkivskyi 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/commit/5d8bb5d07be2a9205e7059090f0ac5
Ivan Levkivskyi 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/commit/5d8bb5d07be2a9205e7059090f0ac5
Ivan Levkivskyi 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
___
Python tracker
<https://bug
Ivan Levkivskyi 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 flagging this a
Ivan Levkivskyi 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/commit/ac5602746ed39ca6591e
Ivan Levkivskyi 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: open -> closed
___
Python tracke
New submission from Ivan Levkivskyi :
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
https://github.com/pyt
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +5961
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32873>
___
___
Py
Ivan Levkivskyi 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
<https://bugs.python.org/issue33
Ivan Levkivskyi 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/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:
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 should
be at least one way to
Ivan Levkivskyi 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 `type` but the s
Ivan Levkivskyi added the comment:
https://devguide.python.org/ will help you.
--
___
Python tracker
<https://bugs.python.org/issue33190>
___
___
Python-bug
Ivan Levkivskyi 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
dataclasses use c
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +6035
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33188>
___
___
Py
Ivan Levkivskyi 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 example when this breaks so that
I can
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +6066
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33207>
___
___
Py
Change by Ivan Levkivskyi :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ivan Levkivskyi added the comment:
Apparently there is another type with a similar problem -- DefaultDict.
Will fix this now.
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Ivan Levkivskyi :
--
pull_requests: +6088
___
Python tracker
<https://bugs.python.org/issue32873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi 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/commit/2a363d2930e29ec6d8a774973ed5a4
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33211>
___
___
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:
> 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
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:
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:
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:
See https://bugs.python.org/issue33346 for yet another example where implicit
function scope complicates life.
--
___
Python tracker
<https://bugs.python.org/issue3
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue7>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
Change by Ivan Levkivskyi :
--
assignee: -> levkivskyi
___
Python tracker
<https://bugs.python.org/issue33315>
___
___
Python-bugs-list mailing list
Unsubscrib
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 :
--
keywords: +patch
pull_requests: +6419
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
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 :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Ivan Levkivskyi :
--
pull_requests: +6423
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Change by Ivan Levkivskyi :
--
pull_requests: +6445
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
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 :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue33421>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
Yes, all this also applies to 3.6.
--
___
Python tracker
<https://bugs.python.org/issue32769>
___
___
Python-bugs-list mailin
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:
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:
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:
You can use Iterator type, for example this works in mypy (didn't test in other
type checkers):
def f() -> Iterator[int]:
yield 42
In case you want annotate something specifically as Generator[int, None, None]
(for example to use it
Change by Ivan Levkivskyi :
--
pull_requests: +4068
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue28936>
___
___
Python-bugs-list mai
Ivan Levkivskyi added the comment:
OK, I made a PR with the fix and a test that checks the line number for syntax
error (so that the original purpose test_global_err_then_warn is preserved).
--
___
Python tracker
<https://bugs.python.
Ivan Levkivskyi added the comment:
> Am I needed here?
As I understand, Serhiy is going to review the PR, so I think no.
--
___
Python tracker
<https://bugs.python.org/issu
Ivan Levkivskyi added the comment:
> Is it correct that the parameter can be annotated in the function body?
I agree with Guido, this is rather a task for type checkers.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue27051>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue23551>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Levkivskyi added the comment:
Since there is no response for few weeks I assume this works for you.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Ivan Levkivskyi :
The string representation of a function signature with annotations is currently
like this:
>>> def __init__(self, x: int = 1, y: int = 2) -> None: pass
...
>>> import inspect
>>> str(inspect.signature(__init__))
'(self,
New submission from Ivan Levkivskyi :
PEP 530 is not very clear about `await` in generator expressions. But when I
try it, the error is a bit confusing:
>>> async def g(i):
... print(i)
...
>>> async def f():
... result = list(await g(i) for i in range(3))
..
Ivan Levkivskyi added the comment:
A first simple idea that comes to my mind is special-case async
generators/iterators in PyObject_GetIter to say something like:
TypeError: asynchronous iterable can't be used where an iterable is expected
If it is possible to detect that an async gene
Change by Ivan Levkivskyi :
--
assignee: levkivskyi ->
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscrib
Ivan Levkivskyi added the comment:
Nick,
> Yury took all this into account when designing the interaction between
> `await` and comprehensions (which is why that's in a better state), but for
> `yield` we inherited the existing behaviour of any other nested function.
Actually
Ivan Levkivskyi added the comment:
> Remind me what happens when you use `await` in a generator expression that
> survives the async function's scope?
Awaiting on f([1, 2]) will result in an async generator (even though yield
never appears here). Yury explained why this happen
Ivan Levkivskyi added the comment:
(Of course there should be not [1, 2] in the argument, but a list of some
awaitables, otherwise there will be an error later.)
--
___
Python tracker
<https://bugs.python.org/issue10
Ivan Levkivskyi added the comment:
... but [await x for x in xs] is still valid _only_ inside async def.
--
___
Python tracker
<https://bugs.python.org/issue10
Ivan Levkivskyi added the comment:
Well, after all I am thinking maybe it is indeed makes sense to ban `yield`
inside both sync/async and both comprehensions/generator expressions. Since we
already have a smörgåsbord of intuitive behaviors.
This, _together_ with extensive clarification to
Ivan Levkivskyi added the comment:
> Do you understand the difference?
Yury, sorry, but what is your problem? Have I said something about that this is
bad. Your tone is clearly insulting, and this is not the first time. Maybe it
makes sense to have some resp
Ivan Levkivskyi added the comment:
Yury OK, sorry then this is a misunderstanding from my side.
--
___
Python tracker
<https://bugs.python.org/issue10
Ivan Levkivskyi added the comment:
Guido, I am not sure about the complete removal, this is probably to radical.
What I think we are missing more detailed docs that would be clear about the
corner cases. (I already mentioned this in https://bugs.python.org/issue32113
Ivan Levkivskyi added the comment:
> How about not posting about this topic for 24 hours.
OK, makes sense :-)
--
___
Python tracker
<https://bugs.python.org/issu
Change by Ivan Levkivskyi :
--
nosy: -levkivskyi
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +4501
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue29879>
___
___
Py
Change by Ivan Levkivskyi :
--
nosy: +levkivskyi
___
Python tracker
<https://bugs.python.org/issue32162>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
pull_requests: +4621
___
Python tracker
<https://bugs.python.org/issue28556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Levkivskyi :
--
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: Python 3.7
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +4634
___
Python tracker
<https://bugs.python.org/issue32225>
___
___
Python-bugs-list mailin
Change by Ivan Levkivskyi :
--
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 types
type: enhancement
versions
New submission from Ivan Levkivskyi :
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
___
Python tracker
<ht
Change by Ivan Levkivskyi :
--
keywords: +patch
pull_requests: +4635
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Ivan Levkivskyi added the comment:
Oops something wrong happened.
--
nosy: +gvanrossum
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Ivan Levkivskyi 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
<-> typing.
-
301 - 400 of 681 matches
Mail list logo
