Guido van Rossum added the comment:
Sounds like a fair feature request for Python 3.3, as long as the intention is
that users must import some module from the standard library and use functions
defined in that module. The operations and methods defined for str instances
(e.g. ==, <,
Guido van Rossum added the comment:
I presume this applies to builtin str methods like .lower(), right? I think it
is a good thing to do for Python 3.3.
We'd need to define what should happen in edge cases, e.g. when (against all
odds) a string happens to contain a lone surrogate or
Guido van Rossum added the comment:
We should at least get this fixed in 3.3. Then we can discuss the benefits of
backporting the fixes to 2.7 and 3.2 (though it sounds to me like the backports
will fix more than they will break, since it is pretty much impossible to do
the right thing in
Guido van Rossum added the comment:
Yeah, this should be fixed in 3.3 and probably backported to 3.2 and 2.7.
(There is already no guarantee that len(s) == len(s.title()), right?)
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Yeah, we should fix this. At least in 3.3, but (without knowing what exactly
is involved) I think backporting to 2.7 and 3.2 makes sense too.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
Really? The re module cannot be salvaged and we should add regex but keep the
(buggy) re? That does not make a lot of sense to me. I think it should just
be fixed in the re module. Or the re module should be *replaced* by the code
from the regex module
Guido van Rossum added the comment:
Again, I would be disappointed if the re (_sre) module could not be fixed. It
is a reasonable feature request.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue12
Guido van Rossum added the comment:
+1 on adding the feature to 3.3 in whichever way makes sense.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue12
Guido van Rossum added the comment:
+1 on the feature request.
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue12753>
___
___
Python-bug
Guido van Rossum added the comment:
I know I sound like NIH, but I'm always reluctant to add a big 3rd party lib
like ICU to the permanent dependencies of all future Python distros. If people
want to use ICU they already can. OTOH I don't have a b
Guido van Rossum added the comment:
To me, making (default) iteration deviate from indexing is anathema.
However, there is nothing wrong with providing a library function that
takes a string and returns an iterator that iterates over code points,
joining surrogate pairs as needed. You could
Guido van Rossum added the comment:
Thanks you very much. We should fix the behavior in 3.3 for sure. I'm
thinking that we may be able to backport the behavior fix to 2.7 and
3.2 as well, since it just makes the behavior generally "better" (and
for most folks it won't matt
Guido van Rossum added the comment:
[me]
>> But I really hope the re module (really: the _sre extension module)
>> can be fixed.
[Ezio]
> Start fixing these issues from scratch doesn't make much sense IMHO. We
> could "extract" the fixes from regex and
Guido van Rossum added the comment:
Thanks Tom for such a clear explanation! I hope someone will implement
this. (Matthew, does this affect regex? I am guessing it does, for
case-insensitive matching?)
--
___
Python tracker
<http://bugs.python.
Guido van Rossum added the comment:
> PEP-393 will take care of iterating by code points.
Only for CPython. IronPython/Jython will still need a separate solution.
> Where would you have other iterators go? The string module?
> Something else I have not thought of? Or something new?
Guido van Rossum added the comment:
I agree on the subdivision, but I think they should still be grouped together
somehow, since these all really *do* share some interfaces: __getitem__ (with
slicing), __iter__, __len__, at least; arguably __contains__; probably some
others (see collections
Guido van Rossum added the comment:
That sounds fine. Or list most of them at tier 2:
4.6 Sequence Types - list, tuple, range, str, bytes and friends
4.6.1 Sequence containers - list, tuple, range
4.6.2 Text Sequence Type - str
4.6.3 Binary Data Sequence Types - bytes, bytearray
Guido van Rossum added the comment:
How about "list, tuple, text and binary strings" ?
--
___
Python tracker
<http://bugs.python.org/issue12874>
___
___
Guido van Rossum added the comment:
> So the codec should allow for both public and private use.
IIUC we have (or are planning) codecs that support the private use.
They are not called "utf-8" though.
--
___
Python tracker
<http:/
Guido van Rossum added the comment:
As you figured out it is not yet supported.
I object to making changes to the classmethod implementation.
I expect the best thing to do is to add a new
@abc.abstractclassmethod
decorator defined in pure Python (maybe the definition of abstractproperty
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue504152>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue502236>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue616013>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue658749>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue667770>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue708007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue992389>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue9213>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue1943>
___
___
Python-bugs-list mailing list
Unsubscri
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
801 - 900 of 5563 matches
Mail list logo