Guido van Rossum added the comment:
Yeah, I've received many warnings about benchmark hacking already, and we
won't fall to that.
For static statistics, it's easy enough to either download a thousand of
the most popular projects from GitHub or PyPI and just try to compile al
Guido van Rossum added the comment:
Go for it! I assume that this will be pretty simple, right? TypeGuard[X] should
show up in __annotations__ as exactly that. It can be implemented in pure
Python.
--
___
Python tracker
<https://bugs.python.
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue43739>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Guido van Rossum :
When building from scratch on Windows I get this warning:
c:\program files (x86)\windows kits\10\include\10.0.17763.0\um\winbase.h(103):
warning C4005: 'Yield': macro redefinition
[C:\Users\gvanrossum\cpython\PCbuild\pythoncore.vcxproj]
I kno
Guido van Rossum added the comment:
I assume the OP wants to have a class that doesn't allow positional patterns.
The right way to spell that is indeed to add
__match_args__ = ()
to the class, there's no need to add another flag to @dataclass.
--
resolution: -> r
Guido van Rossum added the comment:
Thanks! Dup of bpo-43244.
--
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Yes.--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue43772>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Just Don't Do This.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Guido van Rossum added the comment:
Do you need anything from me here?
--
___
Python tracker
<https://bugs.python.org/issue43761>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
So, should we reopen this ad add the flag to suppress __match_args__ generation
after all?
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
I don't think we need control at the field level here. Omitting one field
is just going to cause confusion.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Hm, reading the thread it's not 100% clear to me what you are proposing to do
in your patch, since different people seem to have proposed different things.
I think I'd be okay if `foo[bar]: baz` and `foo.bar: baz` (etc.) didn't
generate
Guido van Rossum added the comment:
Are there other cases where suppressing one thing affects others?
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
There may be other reasons why `__init__` is not desired, and there's no
absolute requirement that `__match_args__` must match the constructor --
only a convention. I'd say don't tie them together.
--
___
Guido van Rossum added the comment:
LGTM
--
___
Python tracker
<https://bugs.python.org/issue43764>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
New changeset ac05f82ad4983e3d3653ae7494c1ff62c4a265fc by DevilXD in branch
'master':
bpo-41974: Remove part of the note regarding complex.__float__ (GH-25197)
https://github.com/python/cpython/commit/ac05f82ad4983e3d3653ae7494c1ff
Guido van Rossum added the comment:
New changeset 522433601a5c64603dab3d733f41a5db39d237eb by Jelle Zijlstra in
branch 'master':
bpo-43783: Add ParamSpecArgs/Kwargs (GH-25298)
https://github.com/python/cpython/commit/522433601a5c64603dab3d733f41a5
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
New changeset 9045919bfa820379a66ea67219f79ef6d9ecab49 by Jelle Zijlstra in
branch 'master':
bpo-43772: Fix TypeVar.__ror__ (GH-25339)
https://github.com/python/cpython/commit/9045919bfa820379a66ea67219f79e
Change by Guido van Rossum :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Dominic, thanks so much for the backport!
--
___
Python tracker
<https://bugs.python.org/issue42059>
___
___
Python-bug
Guido van Rossum added the comment:
New changeset 852150ddfe68bc2696fc880175aeb855a0c16ae6 by Ken Jin in branch
'master':
bpo-42904: Fix get_type_hints for class local namespaces (GH-24201)
https://github.com/python/cpython/commit/852150ddfe68bc2696fc880175aeb8
Guido van Rossum added the comment:
Hi Ken Jin, you can close this issue now with your new permissions, right?
--
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
Batuhan, can you summarize the argument from the thread? What do you think
yourself? Myself, I'm not sure either way, but it seems okay to remove the
remnant bytecode.
--
___
Python tracker
&
Guido van Rossum added the comment:
It's fair that get_type_hints() does too much. But what does your proposed
function do besides this?
{k: eval(v) for k, b in x.__annotations__.items()}
?
--
___
Python tracker
<https://bugs.py
Guido van Rossum added the comment:
I'd say just submit the PR. Shouldn't be problematic. (Have you decided
what to do if the eval() fails?)
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
New changeset a9cf69df2e031d6157f01289f66ca9cf723ceb5c by Karthikeyan
Singaravelan in branch 'master':
bpo-41515: Fix KeyError raised in get_type_hints (GH-25352)
https://github.com/python/cpython/commit/a9cf69df2e031d6157f01289f66ca9
Guido van Rossum added the comment:
Thanks -- odd this didn't fail in CI. We'll get it fixed.
--
___
Python tracker
<https://bugs.python.org/issue41515>
___
__
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Hey Larry, it would seem that PEP 649 as currently specified would make it
impossible to access annotations via the inspect module in cases where
x.__annotations__ raises (because one of the annotations references an
undefined variable).
I really think
Guido van Rossum added the comment:
Also, for crosslinking, see issue43463.
--
___
Python tracker
<https://bugs.python.org/issue43817>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Putting it in inspect makes sense then.
--
___
Python tracker
<https://bugs.python.org/issue43817>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
If the NameError were to leave behind a marker wrapping the string, that might
allow the best of both worlds -- errors don't pass *silently* (an error value
is returned) and you can still inspect the other annota
Guido van Rossum added the comment:
I thought Jelle’s solution would avoid code bloat — a dedicated opcode. It can
do whatever is decided.
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
I defer to Raymond on this.
Honestly without looking at the website I don’t even recall whether “higher
precedence” means “binds more tightly” or the opposite. :-) So maybe we should
change the terminology while we’re at it.
--
nosy
Guido van Rossum added the comment:
Yeah, like this idea. Let’s get this in before beta 1.
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
Hi Kevin,
If you want to work on this, could you come up with some test cases that
try to explore edge cases for this behavior? Ideally some that already
pass, and some that currently don't pass (because of the limitation
mentioned by Ivan). It'
Guido van Rossum added the comment:
Actually I believe a real case was reported on python-dev. I think it is not
clean that the boundary between numbers and identifiers is so fluid.
--
nosy: +Guido.van.Rossum
___
Python tracker
<ht
Change by Guido van Rossum :
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Unsub
Change by Guido van Rossum :
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
So the question is, whether anyone actually writes `x: ' str'`. Does the fix
satisfy a real need?
If it does, why don't we change compile(x, ..., 'eval') as you suggested in
your second comment?
--
_
Guido van Rossum added the comment:
I like Serhiy’s idea.
BTW, what are the three POP_TOP op codes in a row popping?
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue40
New submission from Guido van Rossum :
Hi Victor,
Sorry for making this a deferred blocker. I recall that we had a brief
discussion somewhere about an accidental change to the array.array type -- this
is now a heap type (Py_TPFLAGS_HEAPTYPE is set), and as a consequence it is no
longer
Change by Guido van Rossum :
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43901>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Sounds like a plan, I agree that the original design misfired here (we were
probably worried about million-line code bases with tens of thousands of
classes having to pay the price of tens of thousands of empty dicts, but I now
think that was an
Guido van Rossum added the comment:
Hum, there seems to be an actual bug here: even with PEP 563, the annotations
for "complex targets" are evaluated. For example:
from __future__ import annotations
class C:
x.y: z.w
a: b.c
The relevant parts of the disassembly of the co
Guido van Rossum added the comment:
The same thing happens at the module level. However in functions all is well
(because inside functions annotations are never evaluated, apparently).
It may be as simple as the code forgetting to check the PEP 563 bit when
generating code for complex
Guido van Rossum added the comment:
I’d say that best practices for 3.9+ are more useful.
There seem to be several contradictions in your remarks, but we’ll get to those
in the review.
--
nosy: +Guido.van.Rossum
___
Python tracker
<ht
Guido van Rossum added the comment:
I haven't followed this precisely, but I recall that when we first made PEP 563
the default, we had to fix a number of bugs in various library modules (e.g.
inspect) that were only apparent when `from __future__ import annotations` was
used. I hope
Guido van Rossum added the comment:
Is there going to be a separate PR to actually *set* the IMMUTABLE flag on all
built-in type objects? There are many of those.
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
So shouldn't we just rule out some specific bits of syntax in annotations? That
can be done after the PEG grammar has accepted them, otherwise we'd end up
having a whole new expression-like grammar section that excludes them. I think
this is t
Guido van Rossum added the comment:
I don't like adding a flag. In the PEP-563-by-default world we didn't need a
flag. Perhaps once Larry implements inspect.get_annotations() (issue43817) we
can make inspect.signature() always
Guido van Rossum added the comment:
Does the test suite pass for apply-to-all.diff?
Also, quite a hornet's nest you've uncovered (about __class__ assignment).
Would that be fixed better with the IMMUTABLE flag?
--
___
Python track
Guido van Rossum added the comment:
I don’t really care how you do it, I just thought having a whole
“expr-without-walrus-or-yield” subgrammar would be tedious.
If there is a way to have the “in-an-annotation” flag set during parsing that
may be better, I don’t know.
Maybe Lysandros has an
Guido van Rossum added the comment:
And that’s a problem. There needs to be a recommendation on what to do for code
that spans 3.9 and 3.10. What should users do otherwise? Drop 3.9 as soon as
they introduce 3.10 support? Withhold 3.10 support until 3.9 reaches EOL?
IOW you can’t just break
Guido van Rossum added the comment:
Functions don't store __annotations__ in their __dict__, it is a separate slot
named func_annotations (see funcobject.c). I guess that's because the __dict__
is purely for user-defined function attributes.
But perhaps for classes the C equivale
Guido van Rossum added the comment:
So, honestly I don't understand what your concern with the lazy approach is.
Was your design based on having a bit in the class/module object (outside its
__dict__) saying "I already lazily created one"? Or am I missing something?
Also, I&#
Guido van Rossum added the comment:
I think "no user-visible changes" is a pipe dream. Deleting __annotations__
seems fairly pointless so I don't mind changes that are only visible when you
do that.
--
___
Python tracker
<https
Guido van Rossum added the comment:
My main concern is that types that were immutable in previous Python versions
shouldn't become mutable as a surprise side effect of making them heap types. I
don't know which types have become mutable this way though.
My other concern is that th
Guido van Rossum added the comment:
Let's post the list here and post a brief mention of this issue on
python-dev.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
I'm not a big user of the inspect module, but I always thought that its use was
so that you could look at a function (or other object) *produced by a 3rd
party* and learn something about it.
Asking for the signature is one such operation, and I
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
> > Could you please land the new flag and typeobject.c code now?
>
> I've only got two more questions before I mark it ready for review,
> and that's regarding Guido's comment in msg391756:
> Should the new flag also take c
Guido van Rossum added the comment:
New changeset 1b1f9852bda85c01ef124858f293e9c13e04ffce by Ken Jin in branch
'master':
bpo-42904: Change search order of typing.get_type_hints eval (#25632)
https://github.com/python/cpython/commit/1b1f9852bda85c01ef124858f293e9
Guido van Rossum added the comment:
PS. Don't wait for me. I'm going on vacation this Thursday and won't be
back until well after the 3.10b1 release is done, and before I go I'm
pretty busy already.
--
___
Python tracker
<
Guido van Rossum added the comment:
The solution would be bisection -- apply half of the changes from
apply-to-all, and see if you still get the errors. Etc.
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
There may be a (deliberate? :-) misunderstanding. When I wrote about "you"
inspecting code by a "3rd party" I meant that as a symmetric relationship --
the "you" could be a library and from the library's POV the "3
Guido van Rossum added the comment:
So keep cutting in half until the error disappears?
--
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Pytho
Guido van Rossum added the comment:
I want to be as short as possible.
The user may have annotations because they are using mypy. They may be
using a library that calls inspect.signature() on some of their functions
to retrieve the parameter names conveniently.
All this has worked for years
Guido van Rossum added the comment:
No, I want the *default* not to raise when eval() fails.
--
___
Python tracker
<https://bugs.python.org/issue43817>
___
___
Guido van Rossum added the comment:
Pablo, there seems to be some instability in the tests.
Shreyan, Erlend, maybe merging in master would help?
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
New changeset 05ab4b60ab3dae61ee75692b6624537d4f3fdf85 by Ken Jin in branch
'master':
bpo-43766: Implement PEP 647 (User-Defined Type Guards) in typing.py (#25282)
https://github.com/python/cpython/commit/05ab4b60ab3dae61ee75692b662453
Guido van Rossum added the comment:
Sure. What do you think is causing the failures for Shreyan then? (Are you
two collaborating?)
--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
New changeset 99fdd782007db86f20aeb302b2ceaf79ce1ae2ba by Ken Jin in branch
'master':
bpo-43766: Fix TypeGuard docs (#25660)
https://github.com/python/cpython/commit/99fdd782007db86f20aeb302b2ceaf
Guido van Rossum added the comment:
I don't think I've ever successfully managed to complete the test on my
Windows 10 box either (not even in "production" mode -- you seem to be
using debug mode). I recommend using creating a new PR and having the CI
machinery run
Guido van Rossum added the comment:
I wonder if these four tests do something that affects all threads? The test
driver module runs tests in parallel (if you ask it to run all or most tests,
like the default).
--
___
Python tracker
<ht
Guido van Rossum added the comment:
Can you submit a PR that fixes it?
--
___
Python tracker
<https://bugs.python.org/issue43955>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Yes, I also see that pdb prompt. I recommend looking at what different
configurations are used by test.libregrtest.main() when no tests are passed
on the command line.
--
___
Python tracker
<ht
Guido van Rossum added the comment:
Doesn't the pdb prompt use the builtin input()?
--
___
Python tracker
<https://bugs.python.org/issue43955>
___
___
Pytho
Guido van Rossum added the comment:
New changeset 859577c24981d6b36960d309f99f7fc810fe75c2 by Ken Jin in branch
'master':
bpo-41559: Change PEP 612 implementation to pure Python (#25449)
https://github.com/python/cpython/commit/859577c24981d6b36960d309f99f7f
Guido van Rossum added the comment:
Well, in the normal course of running multiple Python programs on the same
machine, pyc files may be rewritten, and this should not cause crashes. So
perhaps there’s a real bug here?
--
nosy: +Guido.van.Rossum
Guido van Rossum added the comment:
Thanks for your major contribution, Ken! Agreed, that bugfix can come later.
--
___
Python tracker
<https://bugs.python.org/issue41
Guido van Rossum added the comment:
That is as intended, right?
On Thu, Apr 29, 2021 at 07:59 STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> check_set_special_type_attr() is used to prevent setting the following
> attributes:
>
> * __name__
> * __q
Guido van Rossum added the comment:
I don’t think we’re waiting for more crazy hacks.
On Thu, Apr 29, 2021 at 07:27 STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> >
> https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403
>
Guido van Rossum added the comment:
I'm -0.5 on reusing Name(ctx=Store). The reason we're using that in assignments
is that in the past (before the PEG parser) the parser literally used the same
grammar for the LHS and RHS of assignments, and a second pass was used to rule
o
Guido van Rossum added the comment:
Honestly if someone manages to get a PR in I won’t be a spoilsport. So make
me +0.--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
Also, presumably most users don’t right click and look for options. They
just drag a selection and hit ^C (or cmd-C).--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue37
Guido van Rossum added the comment:
Moving the needle on the pyperformance benchmarks is really hard!
--
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
New changeset c55ff1b352f8b82184f80d9dea220e832691acfc by Miss Islington (bot)
in branch '3.10':
bpo-44098: Drop ParamSpec from most ``__parameters__`` in typing generics
(GH-26013) (#26091)
https://github.com/python/cpyt
Guido van Rossum added the comment:
I agree, these namespaces were a mistake. Let's start deprecating them (and
remove their mention from the docs again).
--
versions: -Python 3.10
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
I would like to have a more thorough discussion about the desirability of using
Hypothesis first, since I feel that there is a rather hard "sell" going on. I
brought this up in the SC tracker
(https://github.com/python/steering-council/issues
Guido van Rossum added the comment:
Thanks, I will look into that before stirring up more dust.
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
I don't recall anything about that, sorry.
--
___
Python tracker
<https://bugs.python.org/issue40452>
___
___
Pytho
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue40452>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Okay, well, I'm trying to understand minithesis.py, but I am despairing. The
shrinking code (really everything in class TestingState) is too much to grok.
You can tell from the amount of comments that this is the tour-de-force of the
code, bu
Guido van Rossum added the comment:
Few things incite me quite as much as being told that I'm not supposed to
understand something, so now I'm actually making an effort to follow the ECOOP
paper. Honestly, it's not too bad (a lot more readable than type theory papers
:-). I
Guido van Rossum added the comment:
It is important to me, because I don't like having a dependency on
third-party code that is a black box. Remember that in the end it's not me
you have to convince but the SC.
--
___
Python track
New submission from Guido van Rossum :
This seems a regression from 3.9.
>>> foo[x = 1
... ]
File "", line 1
foo[x = 1
^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?
>>>
Note how the synt
Change by Guido van Rossum :
--
nosy: +lys.nikolaou, pablogsal
___
Python tracker
<https://bugs.python.org/issue44201>
___
___
Python-bugs-list mailing list
Unsub
1901 - 2000 of 5563 matches
Mail list logo
