Guido van Rossum added the comment:
New changeset 09eb81711597725f853e4f3b659ce185488b0d8c by Sebastian Rittau in
branch 'main':
bpo-38291: DeprecationWarning when importing typing.{io,re} (#26719)
https://github.com/python/cpython/commit/09eb81711597725f853e4f3b659ce185488b0d8c
Guido van Rossum added the comment:
I'm currently not very interested in philosophizing about why we allow one
syntax but not the other.
--
___
Python tracker
<https://bugs.python.org/issue23
Guido van Rossum added the comment:
Closing in favor of issue20115.
--
nosy: +gvanrossum
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/
Guido van Rossum added the comment:
Looks like Terry accidentally removed Serhiy. Adding him back.
--
nosy: +Guido.van.Rossum, serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue23
Guido van Rossum added the comment:
Well, it seems we're stuck -- we can't make the grammar more restrictive (at
least, I don't think we should, since it is a backwards incompatibility), so
we'll have to live with the exception. Since it is now clear what the rule is,
we can update the docs
Guido van Rossum added the comment:
> "The one exception is in function calls with *expression after a keyword
> argument: f(x=expr2, *expr1)."
So the question before us is whether to add this phrase to the docs, or to
tweak the compiler to fix it. It is certainly conv
Guido van Rossum added the comment:
Yeah, null bytes should just be rejected. If someone comes up with a fix for
this we'll accept it.
--
___
Python tracker
<https://bugs.python.org/issue20
Guido van Rossum added the comment:
Does it need a backport to 3.9 too, since GenericAlias was introduced there?
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
New changeset 6773c3eaa735b5061b4a97f2c730703a32d8c9ff by Ken Jin in branch
'main':
bpo-44392: Add Py_GenericAlias to C API docs (GH-26724)
https://github.com/python/cpython/commit/6773c3eaa735b5061b4a97f2c730703a32d8c9ff
Change by Guido van Rossum :
--
pull_requests: +25334
pull_request: https://github.com/python/cpython/pull/26749
___
Python tracker
<https://bugs.python.org/issue43
Guido van Rossum added the comment:
Maybe the docs then should contain a more-or-less complete example showing how
a 3rd party type should use this?
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Hm, but is that what they are doing? I assume that they use stub files, since
static type checkers don’t introspect the runtime API.
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Hm, maybe it was a mistake to expose this? Remind me what use is made of this
from C code? Can we remove this from the stable API during beta? It was never
exposed before.
--
nosy: +Guido.van.Rossum
___
Python
Guido van Rossum added the comment:
New changeset 8a76683cfb842e12b57f6d276839f6c68fd94e1a by Sebastian Rittau in
branch 'main':
bpo-38291: Remove mention of typing.io and typing.re again (GH-26113)
https://github.com/python/cpython/commit/8a76683cfb842e12b57f6d276839f6c68fd94e1a
Guido van Rossum added the comment:
New changeset 8a76683cfb842e12b57f6d276839f6c68fd94e1a by Sebastian Rittau in
branch 'main':
bpo-38291: Remove mention of typing.io and typing.re again (GH-26113)
https://github.com/python/cpython/commit/8a76683cfb842e12b57f6d276839f6c68fd94e1a
Guido van Rossum added the comment:
(From PSRT list, Sebastian:)
Please note that the vulnerability fix also added two new functions to
the API that would be great to have xml.parsers.expat expose to the
users for full control
Guido van Rossum added the comment:
Lysandros and Pablo, this *only* occurs when the lexer is reading directly from
a file, not when it's reading the same source code from a (bytes) string. All
examples are syntax errors (some raise ValueError in the parser
Guido van Rossum added the comment:
Yeah, the more I think about it, the more it looks like we should add the
special methods -- even if they won't necessarily be called *if the type is
exactly 'complex' or 'bytes'*.
Now, until we've written and released the code we won't know for sure
Guido van Rossum added the comment:
Sorry, this tracker is not for getting help, only for submitting changes to
Python itself.
Try https://discuss.python.org/c/users/7 instead.
--
resolution: -> rejected
stage: -> resolved
status: open -&g
Guido van Rossum added the comment:
Okay, I trust that this can be closed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
Instead of introspecting types, use this library:
https://github.com/ilevkivskyi/typing_inspect
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Since these are new forms (list[int] previously was an error), does it actually
matter? Especially since these are primarily used in annotations.
@Joseph Perez, is there a specific library or pattern that is broken by this?
FWIW I did think rather
Guido van Rossum added the comment:
> What is/was the initial reason to not preserve the MRO for a TypedDict?
Hm, I can't say for sure. I believe it had something to do with TypedDict
instances being instances of dict at runtime, but I can't actually reconstruct
the reason. Maybe i
Guido van Rossum added the comment:
Also at this point it's too late to get this into 3.10 (given that we're still
debating this it's clearly not a simple bugfix).
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43693>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I withdraw my objection against Hypothetlsis per se. Others should debate
whether the 3rd party dependency is okay. --
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue42
Guido van Rossum added the comment:
Ah, okay. So we're not on the hook to decide this today. :-)
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
I think we're waiting here for the release manager to decide, right? Should we
roll back the change to PyCode_NewWithPosOnlyArgs() or keep it?
Presumably the requested docs aren't the (beta) release blocker
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue44218>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Having read the parts of the paper that explain shortening, things are making
more sense now. I have also successfully contributed type annotations to
minithesis! :-)
--
___
Python tracker
<ht
Guido van Rossum added the comment:
Could we implement something in the REPL where it refuses to read another
line when asked for a token in an error recovery rule?
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Guido van Rossum :
--
nosy: +lys.nikolaou, pablogsal
___
Python tracker
<https://bugs.python.org/issue44201>
___
___
Python-bugs-list mailing list
Unsub
Change by Guido van Rossum :
--
keywords: +3.10regression
___
Python tracker
<https://bugs.python.org/issue44201>
___
___
Python-bugs-list mailing list
Unsub
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 syntax error is in line 1 and yet
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 tracker
<ht
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'll get back
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
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:
I don't recall anything about that, sorry.
--
___
Python tracker
<https://bugs.python.org/issue40452>
___
___
Python-bug
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 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:
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/issue38
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/cpython/commit
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:
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:
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:
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
out invalid
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:
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:
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:
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:
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/859577c24981d6b36960d309f99f7fc810fe75c2
Guido van Rossum added the comment:
Doesn't the pdb prompt use the builtin input()?
--
___
Python tracker
<https://bugs.python.org/issue43955>
___
___
Python-bug
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:
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:
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:
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 the tests.
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/99fdd782007db86f20aeb302b2ceaf79ce1ae2ba
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 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/05ab4b60ab3dae61ee75692b6624537d4f3fdf85
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:
No, I want the *default* not to raise when eval() fails.
--
___
Python tracker
<https://bugs.python.org/issue43817>
___
___
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:
So keep cutting in half until the error disappears?
--
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Pytho
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 "3rd pa
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:
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
<https://bugs.python.
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/1b1f9852bda85c01ef124858f293e9c13e04ffce
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 care of __
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:
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'd
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/issue43
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 the language
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://bu
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'll
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 equivalent
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:
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
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 tracker
<ht
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 call
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 the list we
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:
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 we're
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:
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:
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 o
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
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43901>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue43908>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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?
--
___
Python
Change by Guido van Rossum :
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +Guido.van.Rossum
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Unsub
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
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's possible
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:
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:
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:
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 annotations
601 - 700 of 5393 matches
Mail list logo