Guido van Rossum added the comment:
Ok, the history of all that makes sense, except now I wonder if
ModuleNotFoundError is useful at all. I just reviewed a patch for 3.4 and in
the latest revision all ImportError checks were replaced with
ModuleNotFoundError checks. What purpose does that
Guido van Rossum added the comment:
[switching to gmail-powered account]
I'm sorry, but this seems like it should be an importlib internal affair. The
new exception is too much in everyone's face, because the exception name gets
printed on every traceback.
I like #4, #3 is also
Guido van Rossum added the comment:
Right. Outside importlib there shouldn't be a need to distinguish between the
cases (especially given that the exception works differently than its name
suggests).
--
___
Python tracker
<http://bugs.py
Guido van Rossum added the comment:
In terms of how much freedom you have about changing the internal, I'd check
how long ago they were changed. "Internal" APIs that have been stable for many
versions tend to have illicit external uses -- but internal APIs that were
introduce
New submission from Guido van Rossum:
I discovered that the Python 3 version of
the re module's Match object behaves subtly different from the Python
2 version when the target string (i.e. the haystack, not the needle)
is a buffer object.
In Python 2, the type of the return value of group
Guido van Rossum added the comment:
> Ezio Melotti added the comment:
[...]
> IIUC the advantage of changing the behavior is that it won't keep the target
> string alive anymore, but on the other hand is not backward compatible and
> makes things more difficult for people
Guido van Rossum added the comment:
This is mostly fine.
FWIW I disagree with MAL's assertion that we need to start adding internal
versioning; people who "lawyer" about which version of the PEP should apply are
focused on the wrong thing entirely. IIUC the occasional Python-3
Guido van Rossum added the comment:
OK, forget I said anything about exceptions. The language in Nick's patch is
fine.
Regarding "break is bad", while I agree with Terry's recommendation, I think
saying anything about this would be overreaching the scope of a style guide.
Guido van Rossum added the comment:
> Raymond Hettinger added the comment:
>
> Nick, +1 from me if you want to make your edits and wrap this one up.
+1 from me too.
--
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
[Guido]
>>- Regarding line length, I think it is reasonable to mention that many
>>- organizations are settling on 100 as a compromise. On newer laptops you
>>- can still fit two terminal windows (with a reasonable font size) side by
>
Guido van Rossum added the comment:
Thanks a bundle, Nick!
--
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
I think the current wording about line length makes it too easy to adopt 99
instead of 79. I propose to go back to 79 only, and add this before the
paragraph starting with "The preferred way of wrapping long lines ..."
"""
Som
Guido van Rossum added the comment:
See proposed patch at https://codereview.appspot.com/12269044/ .
--
___
Python tracker
<http://bugs.python.org/issue18
Guido van Rossum added the comment:
Patch applied.
--
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Sorry, I forgot the push. I had to do a little merge dance and also fixed one
typo (a redundant 'line') and now it's hopefully pushed.
--
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
Thanks! We should make sure this makes it into alpha 2. Could you also
prepare a patch for Tulip itself? That way I can make sure Tulip works with
either its own or the stdlib implementation.
One thought: would it be better if the selectors ended up in a
Guido van Rossum added the comment:
No time for a full review yet, but a comment on the timeout test failure you
are observing in Tulip. This particular test schedules a task that sleeps for
20 msecs, and first calls run_until_complete() with a timeout of 10 msecs, and
then calls it again
New submission from Guido van Rossum:
In Python 3.2 and earlier:
>>> def f(): pass
...
>>> f.__name__ = 'g'
>>> f
However in Python 3.3 and later, the last line shows 'f' instead of 'g'.
--
components: Interpreter Core
me
Guido van Rossum added the comment:
Sorry. The actual problem reported was that the traceback uses the wrong name.
I can still reproduce this in 3.4; attached is a repro.
--
Added file: http://bugs.python.org/file31160/functools_wraps_oddity.py
Guido van Rossum added the comment:
Yeah, the timeouts are a bad idea anyway. I've filed
http://code.google.com/p/tulip/issues/detail?id=49 to remind us to do something
about this.
I'll review your tulip patch next.
--
___
Python trac
Guido van Rossum added the comment:
Actually there is a misunderstanding underlying you Tulip patch. Tulip needs
to support Python 3.3 as well as Python 3.4, so it needs to do a little dance
trying to import BaseSelector (or some other key class) from select and if that
fails fall back to
Guido van Rossum added the comment:
Sorry, replying to some direct questions in the bug:
> I also made the following changes:
> - BaseSelector is an abstract base class (so one could imagine user code
> implementing its own selector on top of it)
Fine (though I had to work around this
New submission from Guido van Rossum:
>From glyph (in a particularly snarky mood):
"""
P.S.: I realize that this isn't really within the scope of this message, but as
I was reviewing Future's documentation while writing it, I realized what
Future.running() do
Guido van Rossum added the comment:
(Note that my change to PEP 3156 is somewhat separate -- Tulip's Future doesn't
have to follow all of the PEP 3148 API and its running() method did nothing
anyway. But concurrent.futures.Future has been released for several cycles and
we must co
Guido van Rossum added the comment:
Well aren't there other languages (Ruby, Coffeescript) that have the same
syntax? How do they do it? (Haskell does it too, but I don't think we can
learn from it -- but in Ruby and IIRC Coffeescsript it is syntactic sugar for a
regular call.)
Guido van Rossum added the comment:
I've lost track -- who is waiting for whom? I reviewed the patch
selector-12.diff and received zero response AFAICT. (Maybe the email from
Rietveld didn't make it?)
I'd like to get this into alpha2, even if the proactor won't make it
Guido van Rossum added the comment:
This all sounds fine to fix without waiting for anything else -- can you attach
a patch here?
--
___
Python tracker
<http://bugs.python.org/issue18
Guido van Rossum added the comment:
On Wed, Aug 21, 2013 at 2:37 AM, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I like the idea of renaming select to _select, and add Lib/select.py
> for the high-level wrapper (Selector). In my opinion, adding a module
>
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue18794>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
On Sat, Aug 24, 2013 at 5:04 AM, Charles-François Natali
wrote:
> Before I post it for final review, I have three more questions:
> 1) In the documentation, I don't know how to best refer to files
> object registered: is "file descriptor&qu
Guido van Rossum added the comment:
Looks good. Go ahead and convert the rest of the socket constants. Then we
can consider other modules, e.g. select and os.
--
___
Python tracker
<http://bugs.python.org/issue18
Guido van Rossum added the comment:
I prefer two prettier loops over one less pretty one in this case. No
opinion about _intenum_converter yet. (IMO refactoring can always be lazy,
i.e. after you have multiple copies of the same code there's time to
consider whether you should unify the
Guido van Rossum added the comment:
On Fri, Aug 30, 2013 at 6:34 AM, Charles-François Natali
wrote:
[Giampaolo Rodola']
> > - I'm not sure why in case of EINTR you retry with a different timeout;
> > can't you just return []?
>
> Because when I do:
>
Guido van Rossum added the comment:
> Charles-François Natali added the comment:
> Well, I'll change it, but:
> We have to change the select() docstring to "Wait until some
> registered file objects become ready, or for *at most* timeout
> seconds"
Doesn't
Changes by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue18885>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
On Sat, Aug 31, 2013 at 9:56 AM, Charles-François Natali
wrote:
>
> Charles-François Natali added the comment:
>
> Gregory, thanks, that's what I was planning to do.
>
> But since the recent discussions (mainly on selectors), there ar
Guido van Rossum added the comment:
Hm... I like the [] return just fine, it matches what Tulip's selector did.
The framework should be re-checking the clock anyway -- it's possible that
select() returned late too...
--
___
Python trac
Guido van Rossum added the comment:
Agreed, this was a great feat of implementation and API design.
Is there anything left to do or can we close this issue?
(I looked at the Proactor code in Tulip again and I think it is not quite as
easy to isolate it, so I'm not requesting that Proacto
Guido van Rossum added the comment:
Here's a combined patch. Hopefully it will code review properly.
--
nosy: +gvanrossum
Added file: http://bugs.python.org/file31680/statistics_combined.patch
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Nice docstrings, but those aren't automatically included in the Doc tree.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Still no progress on this bug. Should I just check in my simple patch? But
there's much more to do -- docs, and unittests. Volunteers? It's not hard, just
work.
--
___
Python tracker
<http://bu
Guido van Rossum added the comment:
I could check it in, but I probably would mess up something (which branches are
affected?). Let me know if you want me to.
The priorities after that would be:
1) update docs (the warning about RuntimeError needs to be moderated)
2) convert stress tests to
Guido van Rossum added the comment:
Actually my patch doesn't even apply cleanly. I suspect the dict refactoring
for shared keys interfered. Someone please help!
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I agree it's a bug and should be fixed. It's too confusing that there would be
two slightly different interpretations of isinstance/issubclass where the
isinstance() and issubclass() would be using the extended interpretation but
the except cl
Guido van Rossum added the comment:
Thanks Antoine!
--
___
Python tracker
<http://bugs.python.org/issue14417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I haven't read the code, but from Larry's description this looks great to me.
It's amazing how many extra functions were added to the os module since 3.2! I
also agree that the redundant functions that existed in 3.2 should stay and I
don&
New submission from Guido van Rossum :
This bug is still present in Python 3.3. Some people use urlsafe strings *a
lot*. And they find that the (obvious) implementation in base64.py is way too
slow. In fact, I found myself writing the following a few times in App Engine
libraries
Guido van Rossum added the comment:
Why would it be a feature? There is no change in semantics, only in speed. Do
we have a policy that forbids performance enhancements in bugfix releases? (It
doesn't really matter, I'm just curious. Also, if it really was a feature
request, i
Guido van Rossum added the comment:
Here's a patch. It makes urlsafe_b64{en,de}code about 4x faster on my machine.
The tests in base64_test.py still pass.
--
keywords: +patch
Added file: http://bugs.python.org/file26087/base64.patch
___
P
Guido van Rossum added the comment:
Heh. I'd forgotten about maketrans. Here's a patch that kills the _translate()
helper function completely.
--
Added file: http://bugs.python.org/file26088/base64.patch
___
Python tracker
<http://bu
Guido van Rossum added the comment:
I didn't touch that assert.
--
___
Python tracker
<http://bugs.python.org/issue15138>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
So, can I check this into 3.3?
--
___
Python tracker
<http://bugs.python.org/issue15138>
___
___
Python-bugs-list mailin
Changes by Guido van Rossum :
--
assignee: -> gvanrossum
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15138>
___
___
Guido van Rossum added the comment:
Submitted.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15138>
___
__
Guido van Rossum added the comment:
For posterity, according to the red hat tracker at
https://bugzilla.redhat.com/show_bug.cgi?id=803500 this issue has been assigned
a CVE number: CVE-2011-4940
--
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
The -t feature is not technically about rejecting all code that mixes tabs and
spaces. It is only about detecting code that mixes tabs and spaces IN SUCH A
WAY THAT THE TAB SIZE AFFECTS THE VALIDITY OR MEANING OF THE CODE.
The sample program is only
New submission from Guido van Rossum:
>From http://mail.python.org/pipermail/python-dev/2012-August/121364.html :
"""
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by turning
Guido van Rossum added the comment:
Note, the sort may fail if e.g. bytes and str are mixed in the keys. So this
should be caught and ignored.
An alternative would just be to fix the call site to pass in
sorted(query.items()) instead of sorted(query).
Still, I think that more predictable
Guido van Rossum added the comment:
I've come to see more downsides than upsides to this idea. I'm withdrawing it.
Good points, Greg! (And others.)
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<htt
Guido van Rossum added the comment:
In practice this is indeed how most users of met a classes do it. E.g.
Django. So, +1.
--Guido van Rossum (sent from Android phone)
On Sep 30, 2012 11:36 AM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> It looks s
New submission from Guido van Rossum:
I just noticed that StreamHandler contains the following fragment in its emit()
method:
try:
except (KeyboardInterrupt, SystemExit): #pragma: no cover
raise
except:
self.handleError(record)
Couldn't this be simplifi
Guido van Rossum added the comment:
TBH I don't think that using "yield from" in the docs makes things clearer at
all -- it just requires readers to understand a rather esoteric feature.
--
nosy: +gvanrossum
___
Python
Guido van Rossum added the comment:
I also don't think that this is a desirable feature.
--
___
Python tracker
<http://bugs.python.org/issue16150>
___
___
Guido van Rossum added the comment:
I am going to reject this unless at least one other core developer supports it.
Extensive discussion on python-ideas has found very few supporters besides
Serhiy Storchaka.
--
___
Python tracker
<h
Changes by Guido van Rossum :
--
nosy: +mhammond
___
Python tracker
<http://bugs.python.org/issue16175>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Tough choice. I'm not in favor of using either ctypes or Cython for this
purpose -- ctypes because it's brittle, and Cython because it is a huge
complicated system of its own that I would rather not depend on. Cython
already depends on CPython,
Guido van Rossum added the comment:
So do we need this ticket at all? It seems there's no code to write -- all we
need to do is make sure we can integrate IOCP in the future standard reactor
interface. That hardly seems a reason to keep a ticket
Guido van Rossum added the comment:
I would be happy with requiring that the user use pywin32 if they want to use
this.
Have you all read the docs for IOCP? It is not for the faint of heart. E.g.
it integrates with the thread scheduler
Guido van Rossum added the comment:
According to http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx
once you call GetQueuedCompletionStatus() your thread is managed by the IOCP
and only up to a given parameter of those threads are allowed to run. They
recommend setting that
New submission from Guido van Rossum:
I've noticed a subtle bug in some of our internal code. Someone wants to
ensure that a certain string (e.g. a URL path) matches a certain pattern in its
entirety. They use re.match() with a regex ending in $. Fine. Now someone
else comes alon
Changes by Guido van Rossum :
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue10836>
___
___
Python-bugs-list mailing list
Unsubscri
Guido van Rossum added the comment:
re.matchall() would appear to be related to re.findall(), which it isn't.
The re2 package has a FullMatch method:
http://code.google.com/p/re2/wiki/CplusplusAPI
--
___
Python tracker
<http://bugs.py
Guido van Rossum added the comment:
But my other argument stands.
--
___
Python tracker
<http://bugs.python.org/issue16203>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Wow. Someone edited that to be completely against my guidance. I'll fix it
according to my intentions.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
assignee: ezio.melotti -> gvanrossum
___
Python tracker
<http://bugs.python.org/issue16239>
___
___
Python-bugs-list mai
Guido van Rossum added the comment:
Corrected to:
Yes::
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
No::
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b
Guido van Rossum added the comment:
That example doesn't feel strong enough to me to include in the style guide. I
am fine with leaving that up to the individual contributor to decide.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
I actually prefer some code duplication in this case. Makes the review
easier.
On Mar 17, 2014 2:17 PM, "Giampaolo Rodola'" wrote:
>
> Giampaolo Rodola' added the comment:
>
> Sorry for not being able to rewrite the patch in t
Guido van Rossum added the comment:
review links are only generated for patches that apply cleanly (I don't
know to which branch)
On Tue, Mar 18, 2014 at 2:37 PM, Yury Selivanov wrote:
>
> Yury Selivanov added the comment:
>
> Why there is no 'review&#
Guido van Rossum added the comment:
LGTM, but I don't have a Solaris box to test. I suppose one of you has tested
this? Then okay to commit to the default (== 3.5) branch.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
OK, somebody please review this (not me).
--
___
Python tracker
<http://bugs.python.org/issue21076>
___
___
Python-bugs-list m
Changes by Guido van Rossum :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue21076>
___
___
Python-bugs-list mailing list
Unsubscrib
Guido van Rossum added the comment:
I think this is reasonable to also commit to the 3.4 branch so it will appear
in 3.4.1.
--
___
Python tracker
<http://bugs.python.org/issue20
Guido van Rossum added the comment:
No, I haven't changed my mind. Feel free to add a comment explaining this. :-)
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Why can't this be fixed in 3.4.1? It isn't an API change.
--
___
Python tracker
<http://bugs.python.org/issue18932>
___
__
Guido van Rossum added the comment:
How do you do that with the subprocess module, and why doesn't that work with
asyncio?
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
Oh, I see. Given that it is possible to do using event loop methods, why don't
you write up a complete implementation and then propose to add that to the
asyncio.subprocess module?
--
___
Python tracker
Guido van Rossum added the comment:
But how is the first call supposed to know that you don't want a StreamReader?
Or the second that you do want one? Maybe we need a new constant instead of
PIPE that means "leave it hanging"?
--
___
Guido van Rossum added the comment:
For anyone watching this still, the fix introduced in this issue caused a
security vulnerability, see http://bugs.python.org/issue21082 .
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue9
Guido van Rossum added the comment:
Ouch. That example is very obfuscated -- I fail to understand what it is trying
to accomplish. Running it I see that it always prints 100 for the count with
3.3 or DO_CG on; for me it prints 87 with 3.4 an DO_GC off. But I wouldn't be
surprised i
Guido van Rossum added the comment:
Most likely your program is simply relying on undefined behavior and the right
way to fix it is to keep strong references to all tasks until they
self-destruct.
--
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Thanks for understanding.
It's definitely subtle: there is also some code in asyncio that logs an error
when a Future holding an exception becomes unreachable before anyone has asked
for it; this has been a valuable debugging tool, and it depends on
Guido van Rossum added the comment:
I'll be darned. It appears that generator's send() method uses METH_O, which
means that it really expects a single argument, but if you pass it a tuple, it
assumes that you meant each item in the tuple as a separate argument. I think a
more corr
Guido van Rossum added the comment:
Heh. METH_O was *also* a red herring. But upstream (Tulip) issue 163 *was* a
good clue. I now believe that the real bug is that CoroWrapper.__iter__() has
"return self" rather than "return iter(self.gen)". That fix is in
Guido van Rossum added the comment:
Wow. So many fixes! :-) Are you going to be at the CPython sprint tomorrow?
I'll be there in the morning but my plane leaves in the afternoon.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
This is nice (a backport 3.3 would be even nicer) but at least for the PyPI
repo version of Tulip I'd like to have work-around so people won't run into
this when they are using a slightly outdated Python version. I'll think
about which of my
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue17009>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I think I have to add a work-around to Tulip anyway, because I don't want to
have to tell people "you must upgrade your Python 3.3 otherwise this problem
can happen" (if upgrading was easy for them they would be on 3.4 :-). So I
don't
Guido van Rossum added the comment:
Yuri, thanks for the test, but why would the patch need a version check?
Shouldn't the work-around work equally well in Python versions that don't need
it? Maybe all we need is a comment explaining that it is a work-around and a
hint that eve
Guido van Rossum added the comment:
OK, looks good. I tried your test with my earlier workaround and the wrapper
got deallocated too early, proving that my workaround was indeed wrong and your
test is useful. I am still concerned theoretically that the CoroWrapper.send()
signature is
3801 - 3900 of 5563 matches
Mail list logo
