Jim Jewett
added the comment:
On line 108 (new 104), spaces should probably be added on both sides of the
comparison operator, instead of only after the ">=".
The "%s" changes might end up gettin
New submission from
Jim Jewett
:
Under the http protocol, any 2xx response is OK.
urllib.py and urllib2.py hardcoded only response 200 (the most common).
http://bugs.python.org/issue912845 added 206 as acceptable to
Jim Jewett
added the comment:
Jafo: His fix is great for urllib2, but the same issue applies to the
original urllib.
The ticket should not be closed until a similar fix is made to lines 330 and
417 of urllib.py.
That
Jim Jewett
added the comment:
The change still missed
the httpS copy. I'm
attaching a minimal change.
I think it might be better
to just combine the
methods -- as was already
done in Py3K.
Unfortunately, the
New submission from
Jim Jewett
:
EnvironmentError (including subclass IOError) has special treatment when
constructed with a 2-tuple or 3-tuple. A four-tuple turns off this special
treatment (and was used by urllib for
Jim Jewett added the comment:
> But you said that #2 solution was more RFC compliant...
> Could you please quote the RFC part that describes this behaviour?
RFD2616
http://www.faqs.org/rfcs/rfc2616.html
section 4.3 Message Body ...
The presence of a message-body in a request is si
New submission from Jim Jewett:
http://docs.python.org/lib/typesnumeric.html contains a table listing the
mathematical operators. Please add a note to the final row (x ** y meaning
x to the power y) indicating that Python has chosen to define 0**0==1
Note 6: Python defines 0**0 to be 1
New submission from Jim Jewett :
The implementation has a larger state.kind
Clarified wording on wstr_length and surrogate pairs.
Clarified that the canonical "data" format doesn't always have a data pointer.
Mentioned that calling PyUnicode_READY would finalize a string, so that
Changes by Jim Jewett :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.3
Added file: http://bugs.python.org/file23961/pep-0393.txt
___
Python tracker
<http://bugs.python.org/issu
Changes by Jim Jewett :
Added file: http://bugs.python.org/file23968/pep-0393.txt
___
Python tracker
<http://bugs.python.org/issue13604>
___
___
Python-bugs-list mailin
Jim Jewett added the comment:
Updated to resolve most of Victor's concerns, but this meant enough changes
that I'm not sure it quite counts as editorial only.
A few questions that I couldn't answer:
(1) Upon string creation, do we want to *promise* to discard the UTF-8 and
Jim Jewett added the comment:
>> So even if a third party module uses the legagy Unicode API, the PEP
>> 393 will still optimize the memory usage thanks to implicit calls to
>> PyUnicode_READY() (done everywhere in Python source code).
> ... unless they inspect a given Uni
Changes by Jim Jewett :
Added file: http://bugs.python.org/file23971/pep-0393v20111215.patch
___
Python tracker
<http://bugs.python.org/issue13604>
___
___
Python-bug
New submission from Jim Jewett :
In reviewing issue 13604 (aligning PEP 393 with the implementation) Victor
Stinner noticed that PyUnicode_AsUnicodeAndSize is new in 3.3, but that it is
already deprecated (because it relies on the old PyUnicode type).
This born-deprecated function is just a
Jim Jewett added the comment:
>> Why is the utf-8 representation not cached when it is generated for
>> ParseTuple et alia?
My error -- I read something backwards.
>> When a string is created from a wchar_t array, who is responsible for
>> releasing the original wcha
Changes by Jim Jewett :
Added file: http://bugs.python.org/file23980/pep-0393_20111216.txt.patch
___
Python tracker
<http://bugs.python.org/issue13604>
___
___
Python-bug
New submission from Jim Jewett :
The current docstring for compile suggests that the flags are strictly for
selecting future statements. These are not the only flags.
It also suggests that the source must be source code and the result will be
bytecode, which isn't quite true.
I su
Jim Jewett added the comment:
I'm not sure we're looking at the same thing. I was talking about the
docstring that shows up at the interactive prompt in response to
>>> help(compile)
Going to hg.python.org/cpython and selecting branches, then default, then
bro
New submission from Jim Jewett :
http://docs.python.org/library/string.html#format-specification-mini-language
defines
fill::=
and the text also excludes '{'. It does not require that the fill character be
ASCII.
However, function parse_internal_render_format_
Jim Jewett added the comment:
The currently applied patch ( http://hg.python.org/cpython/rev/f7e05d205a52 )
left some dead code in unicodeobject.c
function fixup (
http://hg.python.org/cpython/file/f7e05d205a52/Objects/unicodeobject.c#l9386 )
has a shortcut for when the fixer doesn't
Jim Jewett added the comment:
I like the idea, but I do quibble with the signature. As nearly as I can tell,
you're assuming
(a) Only one callback. I would prefer a sequence of callbacks, to make
cooperation easier. (This does mean you would need a callback removal, instead
of
Jim Jewett added the comment:
Does anyone think that it is simpler to register two different
callbacks than one?
Moderately, yes.
Functions that actually help with cleanup should normally be run only in one
phase; it is just stats-gathering and logging functions that might run both
times
New submission from Jim Jewett <[EMAIL PROTECTED]>:
The str->Unicode change widened IDLE/batch discrepancy.
In python 2.x, bytes are printable.
>>> for i in range(256): print i, chr(i)
works fine. In python 3, chr has become (the old) unichr, and whether a
unicode char
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Were you using IDLE at the time?
When I try this (Windows XP SP2), the button and its window do not go away
(which is arguably a bug), but it does not crash.
If I then try to close the window using the little X (from the window
m
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Is there still disagreement over anything except:
(1) The type signature of quote and unquote (as opposed to the
explicit "quote_as_bytes" or "quote_as string").
(2) The default encoding (latin-1 vs UTF8), and (
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Matt pointed out that the email package assumes Latin-1 rather than UTF-8; I
assume Bill could patch his patch the same way Matt did, and this would
resolve the email tests. (Unless you pronounce to stick with Latin-1)
The cookiejar f
Jim Jewett <[EMAIL PROTECTED]> added the comment:
> http://codereview.appspot.com/2827/diff/1/5#newcode1450
> Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5",
> I'm guessing this test broke otherwise?
Yes; that is one of the breakages you found in Bill's patch. (He
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Matt,
Bill's main concern is with a policy decision; I doubt he would object to
using your code once that is resolved.
The purpose of the quoting functions is to turn a string (representing the
human-readable version) into bytes (t
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Is pyepoll a good prefix? To me, it looks a lot like the _Py and Py
reservered namespaces, but not quite...
--
nosy: +jimjjewett
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jim Jewett <[EMAIL PROTECTED]>:
feedparser defines four regexs for end-of-line, but two are redundant.
NLCRE checks for the three common line endings.
NLCRE_crack also captures the line ending.
NLCRE_eol also adds a $ to ensure it is at the end.
NLCRE_bol ... is identi
Jim Jewett <[EMAIL PROTECTED]> added the comment:
> These features are to bring the Regexp code closer in line with Perl 5.10
Why 5.1 instead of 5.8 or at least 5.6? Is it just a scope-creep issue?
> as well as add a few python-specific
because this also adds to the scope.
>
Jim Jewett <[EMAIL PROTECTED]> added the comment:
Python 2.6 isn't the last, but Guido has said that there won't be a 2.10.
> Match object is a C-struct with python binding
> and I'm not exactly sure how to add either feature to it
I may be misunderstanding --
Jim Jewett added the comment:
That sounds like a good idea, particularly since it is a bit different
from Perl. Please do write up the a clarification.
Typically, I have either attached a file with the suggested wording, or
included it in a comment from which a commiter could cut-and-paste
Jim Jewett added the comment:
I agree with Raymond. A comment *might* be sufficient, but ... in some
sense, that is the purpose of an assert.
The loop is reasonably long; it already includes macros which could
(but currently don't) change the value, and function calls which might
plau
Jim Jewett added the comment:
What is the status on this? If you are losing interest, would you like someone
else to turn your patch into a pull request?
--
___
Python tracker
<https://bugs.python.org/issue24
Jim Jewett added the comment:
It sounds like the fix is a configuration change already included in the next
version, so ... I think that counts as a fix.
--
nosy: +Jim.Jewett
resolution: -> fixed
status: open -> pending
___
Python tracker
Jim Jewett added the comment:
This was originally "can be reopened if a patch is submitted" and Hristo Venev
has now done so. Therefore, I am reopening.
--
resolution: rejected -> remind
stage: -> patch review
status: closed -> open
ver
Jim Jewett added the comment:
Based on Hristo's timing, it appears to be a clear win.
A near-wash for truly string-only dicts that shouldn't be effected; a near-wash
for looking up non-(exact-)strings, and a nearly 40% speedup for the target
case of looking up but not inser
Jim Jewett added the comment:
Raymond, did you replace the screenshot with a later one showing that things
are fixed now? The timestamp suggests it went up at the same time as your
comment, but what I see in the .png file is that the two are identical other
than addresses.
--
nosy
Jim Jewett added the comment:
@Ben Griffin -- Unicode has defined astral characters for a while, but they
were explicitly intended for rare characters, with any living languages
intended for the basic plane. It is only the most recent releases of unicode
that have broken the "most p
Jim Jewett added the comment:
Looks good to me.
--
nosy: +Jim.Jewett
___
Python tracker
<https://bugs.python.org/issue41217>
___
___
Python-bugs-list mailin
Jim Jewett added the comment:
Looks good to me.
I at first worried that the different function names were useful metadata that
was getting lost -- but the names were already duplicated in several cases.
*If* that is still a concern for the committer, then instead of repeating the
code
Jim Jewett added the comment:
Going back to Raymond's analysis, this is useful when at least some of the
parameters either do not change the result, or are not hashable.
At a minimum, you need to figure out which parameters those are, and whether to
drop them or transform them.
Is
Jim Jewett added the comment:
Is this a platform where 3.8 was working?
The curses test seems to think you have too many color-pairs defined, and this
might well be part of a semi-compatible curses library. I guess I would add
some output to the test showing how many (and which) color pairs
Jim Jewett added the comment:
It may well have been intentional, as deques should normally be mutated only at
the ends. But Raymond did make changes to conform to the ABC, so this should
probably be supported too. Go ahead and include docstrings and/or discouraging
it, though, except for
Jim Jewett added the comment:
The standard itself says that it only applies to content served over http; if
the content is retrieved by ftp or from a file system, then you should trust
that. I don't notice that in the code you pointed to.
So maybe filetype is the right answer if the
Jim Jewett added the comment:
I won't speak of nroff or troff in particular, but many programs had trouble
distinguishing the end of a sentence from an honorific abbreviation, such as
Mr. Spock or Dr. Seuss.
--
nosy: +Jim.Jewett
___
P
Jim Jewett added the comment:
Why would you raise StopIteration if you didn't want to stop the nearest
iteration loop? I agree that the result of your sample code seems strange, but
that is because it is strange code.
I agree with Steven D'Aprano that changing it would cause more
Jim Jewett added the comment:
Is it safe to say that there is an now intent to support VxWorks within the
main tree, with Wind River agreeing to be primary support?
And this ticket has become a tracking ticket for the status on getting it
there, small PR by small PR plus buildbot
Jim Jewett added the comment:
Looks Good To Me
--
nosy: +Jim.Jewett
___
Python tracker
<https://bugs.python.org/issue41391>
___
___
Python-bugs-list mailin
Jim Jewett added the comment:
There are a zillion reasons a filename could be wrong -- but the standard
says to trust the filesystem. So if it sniffs based on contents, it isn't
quite following the standard. It is probably still a useful tool, but it
won't be the One Right Way, an
Jim Jewett added the comment:
Then I suspect they also exist in even earlier versions, and are actually tied
to your development setup. That should still be fixed, but it is probably not
in Python's own code. It might be in python's build process, which is still on
us. Or it m
Jim Jewett added the comment:
Unicode probably won't make the correction, because of backwards
compatibility. I do support the sentence suggested in Thorsten's most
recent reply. Is expanding ligatures the only other normalization it does?
Ideally, we should also mention that it
Change by Jim Jewett :
--
stage: patch review -> commit review
___
Python tracker
<https://bugs.python.org/issue41246>
___
___
Python-bugs-list mailing list
Un
Jim Jewett added the comment:
Why was the delta-processing removed from the casing functions?
As best I can tell, the whole point of going through multiple levels of
indirection (courtesy splitbins) is to maximize compression and minimize the
amount of cache that unicode might occupy.
By
New submission from Jim Jewett :
The documentation for hasattr, getattr, and delattr state that they are
equivalent to object.attribute access; this isn't quite true, because
object.attribute uses a NFKC-normalized version of the string as only the
secondary location, while hasattr, ge
Jim Jewett added the comment:
Why is normalization in getattr unacceptable? I won't pretend to *like* it,
but the difference between two canonically equal strings really is (by
definition) just a representational issue.
Would it be OK to normalize in object's own implementatio
Jim Jewett added the comment:
The URL got mangled in at least my browser, so I'm repasting it on its own line:
http://svn.python.org/projects/sandbox/trunk/stringbench
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/is
Jim Jewett added the comment:
To be more explicit about Martin A. Lemburg's msg151121 (which I agree with):
Count the collisions on a single lookup.
If they exceed a threshhold, do something different.
Martin's strawman proposal was threshhold=1000, and raise. It would be just a
New submission from Jim Jewett :
http://docs.python.org/reference/lexical_analysis.html
Changed in version 2.5: Both as and with are only recognized when the
with_statement future feature has been enabled. It will always be enabled in
Python 2.6. See section The with statement for details
New submission from Jim Jewett :
Python identifiers are in NFKC form; string method .isidentifier() returns true
on strings that are not in that form. In some contexts, these non-canonical
strings will be replaced with their NFKC equivalent, but in other contexts
(such as the builtins
Jim Jewett added the comment:
My preference would be for non_NFKC.isidentifier() to return False, but that
may be a problem for backwards compatibility.
It *may* be worth adding an asidentifier() method that returns either False or
the canonicalized string that should be used instead.
At a
Jim Jewett added the comment:
@Benjamin -- the catch is, if it isn't already in NFKC form, then python won't
really accept it as an identifier. Sometimes it will silently canonicalize it
for you so that it seems to work, but other times it won't. And program
calling isident
New submission from Jim Jewett :
> http://hg.python.org/cpython/rev/0b5ce36a7a24
> changeset: 74515:0b5ce36a7a24
> + Casefolding is similar to lowercasing but more aggressive because it is
> + intended to remove all case distinctions in a string. For example, t
Jim Jewett added the comment:
Frankly, I do think that sample code is too long, but correctness matters ...
perhaps a better solution would be to add either a method or a unicodedata
function that does the work, then the extra note could just say
Note that most case-insensitive matches
New submission from Jim Jewett :
Parser/parsetok.c was recently changed (e.g.
http://hg.python.org/cpython/rev/2bd7f40108b4 ) to raise an error if multiple
statements were found in a single-statement compile call. It sensibly ignores
trailing whitespace and comments. Unfortunately,
(1) It
Jim Jewett added the comment:
Ignoring non-ascii whitespace is defensible, and I agree that it should match
the rest of the parser. Ignoring 2nd lines is still a problem, and supposedly
part of what got fixed. Test case:
s="""x=5 # comment
x=6
""
Jim Jewett added the comment:
Marc-Andre Lemburg:
>> So you get the best of both worlds and randomization would only
>> kick in when it's really needed to keep the application running.
Charles-François Natali
> The only argument in favor the collision counting is that
Jim Jewett added the comment:
On Fri, Jan 20, 2012 at 7:58 AM, STINNER Victor
> If the hash output depends on an argument, the result cannot be
> cached.
They can still be cached in a separate dict based on id, rather than
string contents.
It may also be possible to cache them in th
Jim Jewett added the comment:
On Mon, Jan 23, 2012 at 4:39 PM, Marc-Andre Lemburg
wrote:
> Running (part of (*)) the test suite with debugging enabled on a 64-bit
> machine shows that slot collisions are much more frequent than
> hash collisions, which only account for less than 0.0
Jim Jewett added the comment:
On Wed, Jan 25, 2012 at 6:06 AM, Dave Malcolm
added the comment:
> hybrid-approach-dmalcolm-2012-01-25-001.patch
> As per haypo's random-8.patch, a randomization seed is read at startup.
Why not wait until it is needed? I suspect a lot of scripts
Jim Jewett added the comment:
Sorry; hit the wrong key... intended message below:
On Wed, Jan 25, 2012 at 6:06 AM, Dave Malcolm
added the comment:
[lots of good stuff]
> hybrid-approach-dmalcolm-2012-01-25-001.patch
> As per haypo's random-8.patch, a randomization seed
Jim Jewett added the comment:
On Wed, Jan 25, 2012 at 1:05 PM, Antoine Pitrou
added the comment:
> It looks like that approach will break any non-builtin type (in either C
> or Python) which can compare equal to bytes or str objects. If that's
> the case, then I think the
Jim Jewett added the comment:
The wording in 138415 suggested this patch was changing socket to not support
timeouts -- which would be unacceptable.
But the actual patch only seems to touch multiprocessing/connection.py -- a far
more reasonable change.
Unfortunately, the patch no longer
New submission from Jim Jewett :
http://hg.python.org/cpython/file/fec45282dc28/Include/weakrefobject.h#l54
The comment makes sense -- but doesn't appear to be true, so perhaps it is the
macro that should change.
/* This macro calls PyWeakref_CheckRef() last since that can invo
Jim Jewett added the comment:
I like Nick Coghlan's suggestion in msg140493, but I think he was giving up too
soon in the "or" cases, and I think the confusion could be slightly reduced by
some re-spellings around return values and comments about short-circuiting.
def n
New submission from Jim Jewett :
http://hg.python.org/cpython/file/tip/Lib/collections/__init__.py#l37 states
that the prev/next links are weakref proxies; as of
http://hg.python.org/cpython/diff/3977dc349ae7/Lib/collections.py this is no
longer true of the next links.
It could be fixed by
New submission from Jim Jewett :
collections.namedtuple raises a ValueError if any of the field names are not
valid identifiers, or are duplicates.
It does not normalize the identifiers when checking for duplicates.
(Similar issue with the typename)
>>> namedtuple("dup_fie
Jim Jewett added the comment:
On Thu, Jan 26, 2012 at 8:19 PM, Antoine Pitrou wrote:
> If I read your [Martin v. Löwis' ] patch correctly, collisions will
> produce additional allocations ... That's a pretty massive
> change in memory consumption for string dicts
Not in p
Jim Jewett added the comment:
Given PYTHONHASHSEED, what is the point of PYTHONHASHRANDOMIZATION?
Alternative:
On startup, python reads a config file with the seed (which defaults to zero).
Add a function to write a random value to that config file for the next startup
Jim Jewett added the comment:
On Mon, Jan 30, 2012 at 12:31 PM, Dave Malcolm
added the comment:
> It's useful for the selftests, so I've kept PYTHONHASHSEED.
The reason to read PYTHONHASHSEED was so that multiple members of a
cluster could use the same hash.
It would have been
Jim Jewett added the comment:
On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg
wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Antoine Pitrou wrote:
>>
>> The simple collision counting approach leaves a gaping hole open, as
>> demonstrated by Frank.
Jim Jewett added the comment:
On Mon, Feb 6, 2012 at 12:07 PM, Marc-Andre Lemburg
wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Jim Jewett wrote:
>> The problematic case is, roughly,
>> (1) Find out what N will trigger collision-counting countermeasures.
>
Jim Jewett added the comment:
On Mon, Feb 6, 2012 at 1:53 PM, Frank Sievertsen wrote:
>>> BTW: If you set the limit N to e.g. 100 (which is reasonable given
>>> Victor's and my tests),
>> So it would take around 3Mb to cause a minute's delay...
> How di
New submission from Jim Jewett :
Add a comment explaining why _PyUnicode_FromId can (and should) assume
ASCII-only identifiers.
/* PEP3131 guarantees that all python-internal identifiers
are ASCII-only. Violating this would break some supported
C compilers
Jim Jewett added the comment:
On Mon, Feb 6, 2012 at 4:25 PM, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
> This has nothing to do with PEP 3131. Python could (and does)
> support non-ASCII identifiers just fine, regardless of C compiler
> limitations.
I *t
Jim Jewett added the comment:
And is there a way to characterize the compilers that would break? Is
it a few specific compilers, or "compilers that do not implement UTF8,
which is not required by the C standard", or ...
--
___
Python trac
Jim Jewett added the comment:
After clarification, the original change was backed out.
These are C Identifiers, and nothing beyond ASCII is guaranteed, but other
characters are in practice possible.
--
resolution: -> fixed
status: open ->
New submission from Jim Jewett :
http://hg.python.org/cpython/file/aba513307f78/Lib/importlib/_bootstrap.py#l974
974 # The hell that is fromlist ...
975 if not fromlist:
976 # Return up to the first dot in 'name'. This is
complicated by the fact
977 #
Jim Jewett added the comment:
On Fri, Feb 10, 2012 at 6:02 PM, STINNER Victor
> - PYTHONHASHSEED doc is not clear: it should be mentionned
> that the variable is ignored if PYTHONHASHRANDOMIZATION
> is not set
*That* is why this two-envvar solution bothers me.
PYTHONHASHSEED ha
Jim Jewett added the comment:
Martin v. Löwis (loewis) wrote:
> Displaying a warning whenever the code has changed on disk is
> clearly unacceptable
As clarified, the request is only for when a traceback is being created (or
perhaps even only for when one is being printed).
I agre
New submission from Jim Jewett :
def reset(self):
""" Flushes and resets the codec buffers used for keeping state.
Calling this method should ensure that the data on the
output is put into a clean state, that allows appending
of
New submission from Jim Jewett :
Recent discussion on the mailing lists and in http://bugs.python.org/issue13997
make it clear that the best way to get python2 results for
"ASCII-in-the-parts-I-might-process-or-change" is to replace
f = open(fname)
with
f = open(fname
Jim Jewett added the comment:
See bugs/python.org/issue14015 for one reason that surrogateescape isn't better
known.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/is
Jim Jewett added the comment:
On Mon, Feb 13, 2012 at 3:37 PM, Dave Malcolm
added the comment:
> * added comments about the specialcasing of length 0:
> /*
> We make the hash of the empty string be 0, rather than using
> (prefix ^ suffix), since this slightly ob
Jim Jewett added the comment:
As long as the interpreter knows about about files that *it* wrote, no repeat
checks during startup seems utterly reasonable; sneaking in a new or changed
file is inherently a race condition.
I think it would also be reasonable for general use, so long as there
Jim Jewett added the comment:
As of Feb 28, 2012, the PEP mentions an additional optimization of storing the
values in an array indexed by (effectively) key insertion order, rather than
key position. ("Alternative Implementation")
It states that this would reduce memory usage for
Jim Jewett added the comment:
Can't this be triggered by non-malicious code that just happened to have a
python comparison and get hit with a thread switch?
I'm not sure how often it happens, but today it would not be visible to the
user; after the patch, users will see a sporad
Jim Jewett added the comment:
On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote:
> Jim Jewett:
>> Can't this be triggered by non-malicious code that just happened
>> to have a python comparison and get hit with a thread switch?
> So, they are writing to a dict in o
Jim Jewett added the comment:
(1) I think this module would benefit greatly from a map explaining what each
file does, and perhaps from some reorganization.
As best I can yet tell, there are about ~130 files, over a dozen directories,
but the only ones that directly affect the
1 - 100 of 261 matches
Mail list logo
