Guido van Rossum added the comment:
Well, is cmd2 stabilizing, or is it still changing at a rate too fast for
inclusion in the stdlib? Does it perhaps have a mix of desirable and wacky
features? Or could we just copy much of it into the stdlib as 'cmd'?
I'm a bit concerned
Guido van Rossum added the comment:
Disagree strongly. More later.
On Sun, Apr 22, 2018, 18:41 Raymond Hettinger
wrote:
>
> Raymond Hettinger added the comment:
>
> > Another solution may be to add a simple `__class_getitem__` to `Queue`
> > that will just return `cls`
Guido van Rossum added the comment:
[Raymond]
> I don't think it makes sense to let typing considerations
> start to spill into the rest of the standard library.
> Either add support to typing or not.
We can't possibly add every stdlib class that's generic to typin
Guido van Rossum added the comment:
I'm glad you've rediscovered pgen2!
I'm in favor of unifying the tokenizers and of updating and moving pgen2
(though I don't have time to do the work).
I'm not sure if it's technically possible to give tokenize.py the ability
Guido van Rossum 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.
On Mon, Apr 23, 2018, 05:29 Semyon Proshev wrote:
>
> Semyon Proshev added the comment:
>
> I had been th
Guido van Rossum added the comment:
But lib2to3 is proof that the stdlib is just as much subject to stalling.
Maybe lib2to3 and pgen2 would have a livelier future if they weren't
limited to updates in sync with Python releases.
--
___
Python tr
Guido van Rossum added the comment:
Lukasz, pleased consider seriously to move to a 3rd party package. Even
pgen2.
On Mon, Apr 23, 2018, 21:12 Benjamin Peterson
wrote:
>
> Benjamin Peterson added the comment:
>
> The stdlib is a bad place for anything that needs to evolve at a
&
Guido van Rossum added the comment:
I think merging the tokenizers still makes sense. We can then document
top-level tokenize.py (in 3.8 and later) as guaranteed to be able to
tokenize anything going back to Python 2.7. And since lib2to3/pgen2 it is
undocumented I presume removing lib2to3/pgen2
Guido van Rossum added the comment:
I recommend opening a new issue (you can link to this one for past discussion).
--
___
Python tracker
<https://bugs.python.org/issue1692
Guido van Rossum added the comment:
So this issue doesn't occur when linked with a thread-aware Tcl/Tk, right?
Maybe we should just make sure that's the only configuration we ensure?
--
nosy: +gvanrossum
___
Python tracker
<https://bu
Guido van Rossum added the comment:
So it seems threads and Tkinter events don't mix. This doesn't surprise me
much. (Similar issues can occur when mixing threads and asyncio if you don't
follow the documentation's advice about how to send events across threads.)
Pe
Guido van Rossum added the comment:
I guess nobody gives a damn.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
There's a proposal for a fix currently in PEP 572. I'm linking to the commit
here because we're likely to remove it from PEP 572, but it may be proposed as
a separate PEP:
https://github.com/python/peps/commit/71fea57f19231b9917ce6a558c0b76
Guido van Rossum added the comment:
Perhaps you can start with the more important terms from PEP 484 (and
perhaps also PEP 483, and then PEP 526 and PEP 544). E.g. start with terms
from the ToC of those PEPs.
--
___
Python tracker
<ht
Guido van Rossum added the comment:
I'm okay with multiple PRs, but do beware that each PR requires a core dev
to open a browser window etc., so try to group them a bit. But no need to
wait for the perfect list!
--
___
Python tracker
&
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue33412>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I think represents a legitimate use case. There's another request for this on
python-ideas:
https://groups.google.com/d/msg/python-ideas/0jeftqQpm9c/yZ_uKO84BAAJ
--
nosy: +gvanrossum
resolution: later ->
status: closed
Guido van Rossum added the comment:
> I don't think this will need drastic changes.
IIRC LOAD_NAME loads from the *local* scope, which will be the synthetic
function created for the comprehension (whose scope contains the loop
control variables). We may need a new opcode similar to LOA
Guido van Rossum added the comment:
@Ivan: Please stop bringing up that we should drop the implicit scope for
comprehensions. I know you feel this way, but it's not going to happen.
@Serhiy: What does the PEP for async/await say? (Or is there a separate PEP for
allowing async/await i
Guido van Rossum added the comment:
Given that we don't feel it is worth the effort to support AIX in the CPython
source explicitly, I think it's right that we at least link to Michael's
efforts in the "other downloads" page.
I don't actually know if this shoul
Guido van Rossum added the comment:
> [f: [x async for x in f(x)] for f in fs]
Did you mean {} for the outer brackets intead of []?
I think it is reasonable that if the presence of 'async for' or 'await' in a
comprehension makes it async, then this should also apply if
Guido van Rossum added the comment:
Before we backport this to 3.7 and 3.6, let's iterate on the wording a bit.
I don't think the distinction between annotations and type hints is that
annotations are materialized at runtime while type hints aren't. I think
syntactically th
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue33475>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Is there any problem that is solved by allowing this example? The asymmetry
with using [...async for...] in the same position (which is not allowed)
worries me. Do you have a real use case where it's clearer to write an
async generator expression instead
Guido van Rossum added the comment:
I actually intended to say that annotations continue to be usable for
non-typing purposes (beyond ClassVar/InitVar). It may be deprecated but the
usage still exists. This is a glossary, not a manifesto.
I'm fine with adding that the main use of annota
Guido van Rossum added the comment:
Your phrasing still makes it sound like an annotation is a runtime concept
-- I think of it as a syntactic construct. (Otherwise fine.)
--
___
Python tracker
<https://bugs.python.org/issue32
Guido van Rossum added the comment:
(1) The word "stores" in this paragraph:
A metadata value associated with a global variable, a class attribute or a
function or method parameter or return value, that stores a type hint.
(2) The description of how annotations are stored in __ann
Guido van Rossum added the comment:
@rhettinger
> Guido, is this something you want?
I think it is useful given how much debate there has been around startup time
in various contexts (not just pure interpreter startup time but also startup
time when using specific libraries, packages
Guido van Rossum added the comment:
Is there anything here that requires my attention?
--
___
Python tracker
<https://bugs.python.org/issue31571>
___
___
Pytho
Guido van Rossum added the comment:
That's *really* old. Please clean up as you see fit!
On Sep 24, 2017 10:33 PM, "Serhiy Storchaka" wrote:
Serhiy Storchaka added the comment:
Guido, in 60f2f0cf8e10c94693dfea8937b7feabeffe5744 you added the phrase
"Note that numeric lit
Guido van Rossum added the comment:
It should be like 'if key in dct: del dct[key]'. It may fail when two
threads do this but the *internal* state of dct should not be compromised.
On Sep 25, 2017 2:45 AM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
Guido van Rossum added the comment:
While I understand the sentiment, having this warning pop up every time you
import a provisional module while developing code feels like harassment of the
very users we'd like to try out the provisional APIs.
It's also too course-grained -- m
Guido van Rossum added the comment:
I have no bandwidth for this discussion, but so far I am not convinced. What
happened to "consenting adults"?
> [...] the entire point of the proposed warning letting people know that they
> may be using something they are not fully educ
Guido van Rossum added the comment:
I think the cell type is pretty fundamental to Python's semantic model. IIRC
there once was a time when cells were entirely hidden from the user, but that's
no longer true. Third-party code that uses them might want to have type
annotations and t
Guido van Rossum added the comment:
I'm still trying to understand whether there's a specific event (or set of
events) that's triggered this issue. There is a lot of talk about people can be
misled but not a single specific example of someone who actually got in trouble
becaus
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Wow, nothing here is simple. :-( Even though the examples show that there's
obviously a bug, I would caution against fixing it rashly without understanding
how the current behavior may be useful in other circumstances. I've lost what I
recall fr
Guido van Rossum added the comment:
OK, so the Django and Twisted developers had to resist some pressure from their
users. These are mature projects and if they can't resist pressure from users
something is wrong with those projects, and just pointing users to PEP 411
would have b
Guido van Rossum added the comment:
I am at a loss for words.
On Oct 12, 2017 6:27 PM, "Nick Coghlan" wrote:
>
> Nick Coghlan added the comment:
>
> If a proposed standard library API is sufficiently stable that the folks
> proposing it are reluctant to emit a
Guido van Rossum added the comment:
Hm I may just be completely off here, but I thought that compilers could be
allowed to recognize the use of locals() in a particular function and then
disable JIT optimizations for that function. (In fact I thought we already had
a rule like this but I
Guido van Rossum added the comment:
I think this ought to be a new PEP which supersedes PEP 411. I think it should
simply *offer* the option of using a feature flag rather than prescribing it.
It could also explain that feature flags could cover an entire module or only
the unstable parts. I
Guido van Rossum added the comment:
@Armin:
> Guido: you must be tired and forgot that locals() is a regular function :-)
> The compiler cannot recognize it reliably.
I know, but we occasionally do make exceptions for builtins. In particular
super() is recognized by the compiler.
@Ev
Guido van Rossum added the comment:
> Moreover, if f_locals can be modified outside a tracing hook, then we have
> the same problem in a cross-function way, e.g. if function f1() calls
> function f2() which does sys._getframe(1).f_locals['foo'] = 42.
That's covered b
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Sounds like a plan, I will ignore the ticket then.
--
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Pytho
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue31742>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
OK, I'll wait for the new PEP and ignore the ticket.
--
___
Python tracker
<https://bugs.python.org/issue31742>
___
___
Guido van Rossum added the comment:
SGTM.
On Oct 19, 2017 11:05 AM, "Yury Selivanov" wrote:
>
> Yury Selivanov added the comment:
>
> I'm going to approve this unless there are any objections.
>
> --
> nosy: +gvanrossum
>
> __
Guido van Rossum added the comment:
I assume he means that a similar piece of code should be inserted elsewhere. I
am still waiting for Philip's PR though.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Am I needed here?
--
nosy: -Jeremy.Hylton
___
Python tracker
<https://bugs.python.org/issue28936>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
I think this is very minor but if you two can agree that the code is right I
think it's a nice little improvement, and I like that that particular test's
usefulness is restored.
PS. Long-term we should really build error recovery into our
Guido van Rossum added the comment:
> do we need a PEP to add aiter() and anext() builtins?
No, just this tracker issue, a PR and a reviewer. (Sorry, I can't review
CPython code myself any more.)
--
___
Python tracker
<https://bugs
Guido van Rossum added the comment:
SGTM.
--
___
Python tracker
<https://bugs.python.org/issue24954>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Those seem things that the type checker should complain about, but I don't
think Python should.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Agreed it's too subtle to change the behavior.
> We may also want to explicitly point out that using os.fsdecode(name) before
> passing it to open() will ensure that the name attribute is set to a string
> rather than a bytes object.
Not s
Guido van Rossum added the comment:
Agreed that this needs more clarification. Is something stopping you from
submitting a PR? Note that the thing about non-main-threads is mentioned in the
docstring for BaseDefaultEventLoopPolicy. I agree that the best way to create a
new policy is to study
Guido van Rossum added the comment:
> The response is "Yeah, python-dev decided years ago that they don't care
> about that".
That's a little harsh don't you think?
--
___
Python tracker
<
Guido van Rossum added the comment:
> Such a middle ground is just a wishy-washy decision-by-committee compromise.
Fine, but since *I* won't tolerate these warnings on for everything, this is
the best you can do. If you don't like it, the st
Guido van Rossum added the comment:
Yury do you agree this is a bug? Do you have any ideas on how to fix it?
--
nosy: +gvanrossum, yselivanov
___
Python tracker
<https://bugs.python.org/issue29
Guido van Rossum added the comment:
> the original rationale was about developer tools emitting unhelpful noise
(rather than general Python applications)
I don't recall that, and I'm not sure I agree (either that this is a good
reason or that that was the reason stated when
Guido van Rossum added the comment:
I simply don't think developer tools are the prime example of command line
tools (it's just that because we are Python developers here, *everything*
we use tends to be a developer tool). And "app" does not me
Guido van Rossum added the comment:
Those people who read and write annotations regularly are all using the
convention that was added to PEP 8, so let's make inspect follow that lead
rather than argue about it here. :-)
--
nosy: +gvanr
Guido van Rossum added the comment:
It's a (small) mistake that we didn't make the syntax for argument lists in
decorators the same as argument lists everywhere else, and that should be fixed
to allow exactly what's allowed in regular calls. (That syntax is weird because
we
Guido van Rossum added the comment:
The implementation is as intended and the language spec needs an update.
--
___
Python tracker
<https://bugs.python.org/issue32
Guido van Rossum added the comment:
Perhaps you can just dup() the socket? That's what the ref counter is for
IIRC.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
OK, then maybe socket objects should get a dup() method that just
increments the ref counter, and that would be the public API you're looking
for?
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
I would convert this to `callable()` -- the conversion to
collections.abc.Callable is more verbose and requires an extra import (that can
be slow).
--
nosy: +gvanrossum
___
Python tracker
<ht
Guido van Rossum added the comment:
Remind me what happens when you use `await` in a generator expression that
survives the async function's scope?
async def f(xs):
return (await x for x in xs)
--
___
Python tracker
<https://bugs.py
Guido van Rossum added the comment:
I honestly think we went too far here. Asynchronous generators are still
provisional. Though the PEP is silent about this, the acceptance notice is
clear:
https://mail.python.org/pipermail/python-dev/2016-September/146267.html. I
propose to rip them out
Guido van Rossum added the comment:
I think we all need to calm down a bit. How about not posting about this
topic for 24 hours.
--
___
Python tracker
<https://bugs.python.org/issue10
Guido van Rossum added the comment:
No to both. See python-dev.
--
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
No.
On Nov 25, 2017 18:01, "Nick Coghlan" wrote:
>
> Nick Coghlan added the comment:
>
> Serhiy's PR now implements the "Prohibit yield & yield from in generator
> expressions and comprehensions" approach di
Guido van Rossum added the comment:
To clarify, the outermost iterator is marked here:
[func(x, y) for x in for y in ]
and it is evaluated before the comprehension proper is started. This is
just part of how the language works (it's a similar rule as "in an
assignment
Guido van Rossum added the comment:
Great. It should be a DeprecationWarning, since we're planning to disallow
it completely, right? IIRC SyntaxWarning is for syntax that we can't
deprecate.
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
After the tiresome debate I am happy to see this just as a "what's new" entry
rather than soliciting more debate with a PEP. (However there may be some
existing PEP that suggests it should work? That PEP should be amended with a
note tha
Guido van Rossum added the comment:
I think I'm cool with this (even though it will make blame-finding on
GitHub a tad harder -- what's the magic URL appendage again?)
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
Maybe we also need (in a separate PR) a git pre-commit hook that prevents tabs
in the source (except in the few exceptions you left alone).
--
___
Python tracker
<https://bugs.python.org/issue32
Guido van Rossum added the comment:
Yeah, some editors don't clean up trailing ws. Even with Emacs it occasionally
happens to me.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
OK, great.
--
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
OK, so I think you can go ahead with this. I was fine with the state of the
patch yesterday, so whatever you added today is also fine.
--
___
Python tracker
<https://bugs.python.org/issue32
Guido van Rossum added the comment:
Yeah, I am in favor of this. How will we guarantee that clients using the old
`@coroutine`/`yield from` idiom still work? We need to have separate tests for
that.
--
___
Python tracker
<https://bugs.python.
Guido van Rossum added the comment:
Yeah, the original reasoning was that threads were something esoteric and
not used by most code, and at the time we definitely felt that always using
the GIL would cause a (tiny) slowdown and increase the risk of crashes due
to bugs in the GIL code. I'
Guido van Rossum added the comment:
For 2.7 I hesitate to OK this, who knows what skeletons are still in that
closet. It doesn't sound like a security fix to me. For 3.6 I'm fine with
it as a bugfix.
--
___
Python tracker
<https://bu
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue32251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue26414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
This doc bug should be fixed before 3.6.4 final goes out.
--
nosy: +gvanrossum, ned.deily
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issu
Guido van Rossum added the comment:
I like the current approach (PyObject_GetItem). I agree with both of your
reasons to prefer it.
--
___
Python tracker
<https://bugs.python.org/issue32
Guido van Rossum added the comment:
> This adds an overhead to every indexing.
I'm not doubting your results, but I'm curious how that happened. The extra
code in PyObject_GetItem is right before the point where it would otherwise
raise TypeError -- I presume you benchmark never
Guido van Rossum added the comment:
I think the best thing to do is not to panic! Also maybe PGO could help?
On Dec 14, 2017 15:43, "Ivan Levkivskyi" wrote:
>
> Ivan Levkivskyi added the comment:
>
> Interesting. I have noticed similar when I tried to add a fast loo
Guido van Rossum added the comment:
I liked the original design better, where things without annotations would
just be ignored. What changed?
On Dec 27, 2017 5:19 PM, "Ivan Levkivskyi" wrote:
>
> Ivan Levkivskyi added the comment:
>
> > I'm not sur
Guido van Rossum added the comment:
I think this should be accepted once the code is reviewed.
--
___
Python tracker
<https://bugs.python.org/issue32489>
___
___
Guido van Rossum 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. This "confli
Guido van Rossum added the comment:
I don't recall what I meant to use tp_cache for, but everything I can find
about it says it's unused, so let's kill it if we can. I guess the ABI requires
that we keep the slot around until we find a
Guido van Rossum added the comment:
If we were to take the docs literally then PySequence_{Size,Length} should just
be aliases for PyObject_Size. But I'm reluctant to change something that has
been like this for ages.
In fact maybe we should deprecate them, together with other PySequ
Guido van Rossum added the comment:
Since docs and implementation disagree let's call it undefined. I really
can't comment on what PyPy should do.
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
Ah, I like dropping "For objects that do not provide sequence protocol". Go for
it!
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
I agree with Yury, this feels too risky to consider. The "except Exception:
" code is at fault.
--
___
Python tracker
<https://bugs.python.o
Guido van Rossum added the comment:
I find it a satisfying outcome that we decided *not* to remove this in the last
week before rc1. While it's true that dataclasses are a new feature in 3.7.0,
considerable effort went into stabilizing the betas.
Let's close
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue19251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<https://bugs.python.org/issue26819>
___
___
Python-bugs-list mailing list
Unsubscribe:
3601 - 3700 of 5563 matches
Mail list logo
