Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2268>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1503>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Did Alexander ever present his case to python-dev?
--
___
Python tracker
<http://bugs.python.org/issue1733184>
___
___
Pytho
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue8743>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1466065>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1487481>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue1397>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Guido van Rossum :
--
nosy: -gvanrossum
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue1397>
___
___
Python-bugs-list mai
Guido van Rossum added the comment:
That would be too hard-headed. A complaint I often hear about Interfaces in
Java is that classes have a hard time if they choose not to implement a certain
method. It also would not be enough -- there are tons of ways you would be able
to satisfy such a
Guido van Rossum added the comment:
Just jumping in here with commentary from the side bench... I noticed you say
"this does not always return the same results as dir(x)". But since dir(x)
exists, perhaps it would make sense to match dir(x) as closely as possible?
I.e. if dir(x) do
Guido van Rossum added the comment:
> Would it be useful to provide a separate function to perform the check, which
> could be used by lint-style tools as well as automated tests?
>
> It would be great if every call to .register in the standard library had a
> corresponding tes
Guido van Rossum added the comment:
> Since the addition of __dir__, dir(obj) can return arbitrary values.
> Typically (I guess) this will be used to add dynamically created attributes
> that this function will fail to find - so it is *more* likely that we will
> fail to find
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1856>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue5404>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue8654>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue9732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1677872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1731717>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Given this explanation, of course I am +1 on an explicit release() method. But
I'm still skeptical that a context manager adds much (not sure if that counts
as -0 or +0 :-).
I suppose after release() is called all accesses through the memoryview o
Guido van Rossum added the comment:
I'm still against collecting all types in one module. Closing.
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Guido van Rossum added the comment:
So has anyone got an idea on how to fix this without solving the halting
problem?
--
___
Python tracker
<http://bugs.python.org/issue1
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1865>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg117114
___
Python tracker
<http://bugs.python.org/issue766910>
___
___
Python-bug
Changes by Guido van Rossum :
--
Removed message: http://bugs.python.org/msg117113
___
Python tracker
<http://bugs.python.org/issue766910>
___
___
Python-bug
Guido van Rossum added the comment:
IMO converting turtle.py into a package, unless that's already planned anyway,
is not a good project to undertake right now. (OTOH the demo itself already is
a package, less an __init__.py file.) Note that the turtle module already runs
some demo
Guido van Rossum added the comment:
I would like Gregor Lingl's approval of turning turtle.py into a package. It
might make some things harder for novices, e.g. trackebacks and just browsing
the source code.
Also many people don't expect to find any code in a file named __init
Guido van Rossum added the comment:
I could imagine separating the state into two parts:
- a three-valued enum distinguishing created, active, or exhausted
- a bool (only relevant in the active state) whether it is currently running or
suspended
The latter is just g.gi_running so we don&#
Guido van Rossum added the comment:
I take it back. The 4-value state looks better.
My initial hesitance was that if you ever see GEN_RUNNING you are
probably already in trouble, since you can't call send, next, throw or
even close on a running generator (they all throw ValueError), so wh
Guido van Rossum added the comment:
I think the idea is reasonable. (I haven't checked the patch.)
--
assignee: gvanrossum -> ncoghlan
___
Python tracker
<http://bugs.python.org
New submission from Guido van Rossum :
The security list received a report about SimpleHTTPServer's list_directory().
It needs to add a charset parameter to the Content-type header. This is already
done in Python 3 (where this code lives in http/server.py) but not in any
Python 2 versi
Guido van Rossum added the comment:
>> It needs to add a charset parameter to the Content-type header.
>
> What is the rationale?
Without a charset parameter, IE7 engages in encoding-sniffing and can
be enticed to interpret the output as UTF7. This allows an attacker to
hide e.g.
Guido van Rossum added the comment:
This should not reuse DeprecationWarning but instead introduce a different
warning, e.g. CompatibilityWarning.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue11
Guido van Rossum added the comment:
Looks good, this should be committed to the 2.5 branch first, then
merged to 2.6, then to 2.7.
--
___
Python tracker
<http://bugs.python.org/issue11
Guido van Rossum added the comment:
Closing. We now have a context manager based solution for saving, changing and
restoring warning filters.
http://docs.python.org/library/warnings.html#testing-warnings
(I just came across this issue looking for such a solution. :-)
--
nosy
New submission from Guido van Rossum :
We received the following on the security list. With the OP's permission I am
now filing a public bug with a patch, with the intent to submit the patch ASAP
(in time for MvL's planned April security release of Python 2.5).
The OP's descr
Changes by Guido van Rossum :
--
keywords: +patch
Added file: http://bugs.python.org/file21372/dd852a0f92d6.diff
___
Python tracker
<http://bugs.python.org/issue11
Guido van Rossum added the comment:
Please review the patch that I created. (Now why doesn't it have a "review"
link?) Note that the patch currently only allows http and https.
--
___
Python tracker
<http://bugs.pyt
Guido van Rossum added the comment:
Oddly, I now see a review link for my own diff but not for orsenthil's. Maybe
there's a delay?
I could use help with the tests.
I suppose orsenthil's patch is for Python 3?
--
___
Python
Guido van Rossum added the comment:
> Which patch should be reviewed? They seem to be different.
Both. Mine's for the Python 2 line while Senthil seems to deal with
Python 3. (However the presence of Senthil's patch somehow overrode my
patch in Rietveld. It looks like Martin di
Guido van Rossum added the comment:
I am okay with adding FTP to the list.
I still don't think we should raise URLError on the bad redirect; we should
treat it the same as a missing URI/Location header, and it will raise HTTPError.
--
___
P
Changes by Guido van Rossum :
Added file: http://bugs.python.org/file21377/ca3b117c40f3.diff
___
Python tracker
<http://bugs.python.org/issue11662>
___
___
Python-bug
Guido van Rossum added the comment:
Is there any reason to assume this is not a bug? I think it should be fixed in
all versions.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue11
Changes by Guido van Rossum :
Added file: http://bugs.python.org/file21441/9d06d5eb1a7e.diff
___
Python tracker
<http://bugs.python.org/issue11662>
___
___
Python-bug
Guido van Rossum added the comment:
Aha. I now see the point of raising an exception instead of just returning
None. I have backported Senthil's patch to the 2.5 branch. Please review.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
Added file: http://bugs.python.org/file21442/f03e2acb9826.diff
___
Python tracker
<http://bugs.python.org/issue11662>
___
___
Python-bug
Changes by Guido van Rossum :
Removed file: http://bugs.python.org/file21441/9d06d5eb1a7e.diff
___
Python tracker
<http://bugs.python.org/issue11662>
___
___
Python-bug
Guido van Rossum added the comment:
This issue was first reported by Niels Heinen from the Google Security Team.
--
___
Python tracker
<http://bugs.python.org/issue11
Guido van Rossum added the comment:
I have the final version of the patch for Python 2 in the 2.5, 2.6 and 2.7
branches in my repo (http://hg.python.org/sandbox/guido).
What's the next step? Just push this to the central repo? There are a few
separate changes:
summary: Merge u
Guido van Rossum added the comment:
Also for the Python 3 family it's best to backport Senthil's patch. I will try
that in my tree as well.
--
___
Python tracker
<http://bugs.python.o
Guido van Rossum added the comment:
The fix is now also in the 3.1, 3.2 and default branches of my repo
(http://hg.python.org/sandbox/guido).
Maybe I should just merge the whole bunch into the root repo and be
done with it?
--
___
Python tracker
Guido van Rossum added the comment:
Ok, merged into the central repo. Let me know where I screwed up.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Guido van Rossum added the comment:
class X(metaclass=func) should definitely continue to work; that is a
long-standing (if relatively unknown, and very advanced) feature. In fact,
metaclasses have their origins in this, via the "Don Beaudry hook" -- see
http://python-history.bl
Guido van Rossum added the comment:
Thanks for diving deep! How much of this can we claim as a bug and how much as
a feature?
--
___
Python tracker
<http://bugs.python.org/issue1294
Guido van Rossum added the comment:
Let me confirm that. Since it is a security patch the entire point of it is to
be placed in the release.
I don't want to question the reasons for doing the release from svn instead of
from hg, but I do want to emphasize that the hg branch ought
Guido van Rossum added the comment:
Yes please.
On Mon, Nov 22, 2010 at 7:44 AM, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> Temporarily reopening to remind me to switch from using integer constants to
> strings (which are much friendlier for deb
Guido van Rossum added the comment:
I think it is definitely wrong the way it works in 3.x. (Especially since it
works as expected in 2.x.)
I agree with Inyeol's preference of fixes: (1) make it work properly for
listcomps as well as genexps, (2) if that's not possible, forbid
Guido van Rossum added the comment:
PS. Wasn't there a similar issue with something inside a genexp that raises
StopIteration? Did we ever solve that?
--
___
Python tracker
<http://bugs.python.org/is
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscri
Guido van Rossum added the comment:
Yes it is, but I was never asked about it back then.
--
___
Python tracker
<http://bugs.python.org/issue10544>
___
___
Pytho
Guido van Rossum added the comment:
> Why did the list implementation get changed in Py3.x?
Because we decided to get rid of the sq_slice and sq_ass_slice slots
in PySequenceMethods, and that in turn was because we got rid of the
slice-related opcodes and the separate __getslice__
Guido van Rossum added the comment:
> In the meantime, would it be reasonable to add the moral equivalent
> of `hasattr(type(op), 'items')` to PyMapping_Check()?
That all depends on what it is used for. Which is hard to say without someone
following more of the links tha
Guido van Rossum added the comment:
The question is, if PyMapping_Check() returns True, and a list is passed, will
the code segfault or raise an exception? A segfault would be unacceptable; an
exception would be acceptable assuming that the code would have raised an
exception anyway if
Guido van Rossum added the comment:
It looks like PyMapping_Check() already checks for the presence of a fairly
arbitrary special operation (mp_subscript). It sounds fine to replace that
with a check for the presence of a keys() or items() method (I'm not sure which
one is
Guido van Rossum added the comment:
Not sure why I've been added, but I agree that all fds should always be in
binary mode in Python 3.
--
___
Python tracker
<http://bugs.python.org/is
Guido van Rossum added the comment:
On Thu, Jan 6, 2011 at 11:56 AM, Eric Smith wrote:
> If we're going to take this on (re-writing strftime), I think the way to do
> it is to have it take the locale info as a parameter, and if that parameter
> is NULL then look up the info
Guido van Rossum added the comment:
On Thu, Jan 6, 2011 at 1:20 PM, STINNER Victor wrote:
> I don't know the effect of _setmode(stderr, O_BINARY) on calls to
> fputs(stderr, ...) in Py_FatalError().
On Windows it will write lines ending in LF only instead of CRLF. Most
tools t
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue4953>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
On the one hand, I think that any framework that sets a convention for the
meaning of annotations needs to cope with the possibility of other code using a
different convention. So in that sense this could be deemed a test case for
the robustness of such a
Guido van Rossum added the comment:
On Wed, Jan 12, 2011 at 2:49 PM, Antoine Pitrou wrote:
> Could we simply state in PEP 8 that annotations have no official meaning and
> that anyone (including stdlib developers) can use it for whatever purpose
> they see fit?
No, that is less st
Guido van Rossum added the comment:
Yes, please add the lost info back to docstrings.
--
___
Python tracker
<http://bugs.python.org/issue10899>
___
___
Python-bug
Guido van Rossum added the comment:
IIRC:
The design started out this way because it predates new-style classes. When
this was put in one couldn't subclass extension types, and there were
plans/hopes to replace some of the lock types with platform-specific built-in
versions on
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Chester, this is your last warning. One more submission like this and
we will ban you from submitting new bug reports. You have to learn how
to use the bug tracker properly if you don't want to be ignored completely.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Thanks. I think this part is the main reason I see a start argument to
> enumerate as potentially problematic:
>
> """all variants can easily be misread as starting at the nth item in the
> s
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sure, fine.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2831>
__
___
Python-bugs-list mailin
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please keep them. They correspond to the (?x) and (?s) syntax that is
supported inside the regex.
Perl compatibility is a feature, not a bug for the re module.
--
nosy: +gvanrossum
resolution: -> wont fix
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm torn about the extra slot; I'd rather not add one, but I can't see
how to make this flexible enough without one.
It should definitely not be a built-in; the sys module is fine though
(e.g. sys.getrefco
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I see it differently. The rule is simply that if you use a bare * you
*must* follow it with at least one argument (that's not **k). This
makes sense since otherwise the * is redundant. Think about it; there
is nothing differ
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Since Pexpect is alive and well, doesn't it satisfy your needs? What's
the point of trying to push an alternative implementation that has
lingered for 7 years now?
--
n
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Whether the C API stuff and .isprintable() should be backported to 2.6
> is something for Guido to decide.
No way -- while all of this makes sense in Py3k, where all strings are
Unicode, it would cause no end of problems in
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks like you accidentally removed 2-arg __pow__ from the Complex ABC.
This should stay of course.
Also, please add the binary operators back in a new ABC called Binary
deriving from In
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Excuse me? Have you actually been following the thread?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks good. I like keeping the *View classes around so someone can use
them still.
--
assignee: gvanrossum -> georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Not really, see the reply I sent to the checkin mail.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The behavior observed is intentional. The docs should be updated.
--
nosy: +gvanrossum
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PR
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I want to make this "bypass getattr" behavior mandatory for those
operations that currently use it, forcing the issue for other
implementations of Python. That's a doc change (but an important one!).
There are probab
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I say let's go with the cleanup. Extensions that want to be compiled
under 2.x and 3.0 will need lots of #ifdef code anyway.
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
If it's only failing during the second run of "make test", typically
there's some implicit dependency on something that is disturbed by
running a test that's later in the suite of tests. This could be eith
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I should add this was in the trunk (2.6).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Submitted as r64281.
We still need a doc patch and changes to the exception printing (perhaps
also to traceback.py). Please open new issues for those.
--
resolution: -> fixed
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
N.B. Benjamin made a typo in the revision, it's r64284.
--
nosy: +gvanrossum
resolution: fixed ->
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Mostly, but I *really* want to see unittests for this.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
assignee: gvanrossum -> rhettinger
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Yeah, let's just reject this. There doesn't appear to be much demand.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Methinks this one is also better rejected. Please reopen if you feel
strongly.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Raymond, mind if we roll back your previous (incorrect) changes? They
really should not have been submitted in the first place.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks for your contribution!
To get this commmitted, please draw the attention of someone else on
python-dev (or if you're an IRC person try #python-dev at freenote,
IIRC). I'd recommend moving the tests into the exis
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Rejecting. Too much risk as well, based on experience in the past with
supposedly harmless optimizations.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
+1 on removing the trailing L from the repr.
+0 on trying to reduce the values to ints; that would be dead-end code
since in 3.0 it's a non-issue. And it doesn't solve the problem with repr.
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm going to have to ask someone else to look at this code. I am too
busy with too many things to be able to take on a detailed code review.
--
assignee: gvanrossum ->
___
801 - 900 of 5533 matches
Mail list logo
