Jim Jewett added the comment:
On Tue, Mar 6, 2012 at 1:05 PM, Guido van Rossum
Jim Jewett:
>>... If they're just adding new keys, or even deleting other
>> (==> NOT the one being looked up) keys, why should that
>> keep them from finding the existing, unchang
Jim Jewett added the comment:
On Tue, Mar 6, 2012 at 3:07 PM, Stefan Krah
> Jim Jewett wrote:
>> (1) I think this module would benefit greatly from a map explaining
>> what each file does, and perhaps from some reorganization.
> Just MAP.txt in the top level direc
Jim Jewett added the comment:
I think the latest patch is indeed cleaner.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue13897>
___
___
Jim Jewett added the comment:
On Wed, Mar 7, 2012 at 5:28 AM, Stefan Krah
added the comment:
> OK, as a basis for discussion I've added:
> http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt
That is indeed very helpful. So helpful that now I unde
Jim Jewett added the comment:
On Thu, Mar 8, 2012 at 7:43 PM, STINNER Victor wrote:
> Python < 3.3 retries the lookup an unlimited number of times which
> lead to a crash, that's the issue fixed by my change.
How does it lead to a crash? I think it just leads to an infinite
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 st
Jim Jewett added the comment:
On Fri, Mar 9, 2012 at 12:13 PM, Jim Jewett
> So to get beneath 2/3 without lots of reallocation
> probably requires knowing when the key set is likely
> to be complete, and that is indeed more complex than
> the current changes. (That said, you ha
Jim Jewett added the comment:
So the risk is that descr may be given garbage memory that just happens to look
like an object with 1 reference, so that it really does a decref and tries to
re-deallocate whatever was there before.
I would rather see the change at the top of the function; just
Jim Jewett added the comment:
If I understood correctly, that *is* the minimal case, which suggests some sort
of size problem.
That said, I could not duplicate on 2.6.2, nor with py_compile.compiler in
3.2.2; I am not currently sufficiently motivated to install another version
just for
Jim Jewett added the comment:
If I read that patch right, it ignores (and does not even reraise) SystemExit
(unchanged), but other Exceptions currently block the dump (and your patch
causes them to still dump).
(1) Why is SystemExit ignored?
(2) There should be tests to show that there
Changes by Jim Jewett :
--
assignee: docs@python
components: Documentation
nosy: Jim.Jewett, docs@python
priority: normal
severity: normal
status: open
title: clarify http://docs.python.org/dev/library/time.html#time.steady
type: enhancement
versions: Python 3.3
New submission from Jim Jewett :
http://docs.python.org/dev/library/time.html#time.steady
Current:
"""Return the current time as a floating point number expressed in seconds.
This clock advances at a steady rate relative to real time and it may not be
adjusted. The referen
Jim Jewett added the comment:
msvcrt.getwch has a similar failure, returning (2**16)-1.
Because of this, getpass.win_getpass (used as getpass.getpass on windows)
echoes the password when using Idle (even without a subprocess), but does not
echo passwords when from a command-line python
Jim Jewett added the comment:
Looking at http://sourceforge.net/projects/expat/files/expat/2.1.0/, so long as
XML_ATTR_INFO isn't defined at compile time, the changes are all considered
bugfixes, and the XML_SetHashSalt is the only other changed API.
Is a potential Denial of Service r
Jim Jewett added the comment:
gccallback4a.patch is a few changes to gccallback4.patch. Most are just
spelling or grammar in comments, but I did modify the test case so that the
Uncollectable loop had *multiple* objects with __del__ methods.
--
nosy: +Jim.Jewett
Added file: http
Jim Jewett added the comment:
> The problem is to reject sequence in dictproxy constructor.
Why? Just because you can't delegate in quite the same way? A sequence *does*
meet the (immutable) Mapping interface; it just won't happen to have any
non-integer keys.
Or are you
Jim Jewett added the comment:
(1) How does the user control (or even find out) which clock is used by
time.steady()?
If the answer is time.steady(clock=QueryPerformanceCounter) then there is no
need for strict=?, but then I'm not sure what the point of time.steady itself
is.
I had
New submission from Jim Jewett :
http://www.python.org/~gbrandl/build/html2/whatsnew/3.3.html#pep-393-flexible-string-representation
"The packaging module replaces the distutils module"
All other deprecation messages list the deprecated object first, such as
"platform.p
Jim Jewett added the comment:
Patch is doc-only, and looks good to me.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue14410>
___
___
Pytho
New submission from Jim Jewett :
Per the 3.3 WhatsNew:
"""issue 14205: A dict lookup now raises a RuntimeError if the dict is modified
during the lookup. If you implement your own comparison function for objects
used as dict keys and the dict is shared by multiple threads, acce
Jim Jewett added the comment:
It is now a useful function, as PyUnicode_AsUnicode defers to it.
It is still born-deprecated, but that may be unavoidable, as all use of the
wstr format is deprecated.
--
___
Python tracker
<http://bugs.python.
Jim Jewett added the comment:
See http://bugs.python.org/issue14417
--
___
Python tracker
<http://bugs.python.org/issue14205>
___
___
Python-bugs-list mailin
Jim Jewett added the comment:
>> A counter can be added to dictobject.c.patch to avoid
>> an infinite loop.
> But why bother?
Without a termination condition, how is this different from just reverting the
original change? Is it just the slightly improvemen
Jim Jewett added the comment:
I think the second patch is a fairly straightforward enhancement to the
existing situation. It still feels a bit like an awkward half-measure, though.
(1) If a class does have a finalizer, instances should still be able to say
"Go ahead and collect me, I
Jim Jewett added the comment:
At least put the information inside some disclaimers about "normally"; even the
stdlib has some fake locks that let you release a lock someone else holds. (I
think I found them in in workarounds for threading not being available, such as
the dummy
Jim Jewett added the comment:
On Thu, Apr 5, 2012 at 5:38 PM, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
> Not sure what you're talking about. The doc patch is about unacquired
> locks, not locks that someone else (another thread) holds.
Isn't one common r
Jim Jewett added the comment:
On Fri, Apr 6, 2012 at 5:57 AM, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>> > Not sure what you're talking about. The doc patch is about unacquired
>> > locks, not locks that someone else (another thread) holds.
>
Jim Jewett added the comment:
> I don't think 2 is important. Does the context of the call matter?
> It is merely a question of whether a finalizer will or will not do
> something trivial.
It would affect how I would write such functions. If I knew that it wouldn't
Jim Jewett added the comment:
@Jimbofbx: You are correct that a value has to be reserved to indicate that
the hash hasn't been (or can't be) computed, but python uses -1 instead of zero.
An integer can't return itself because a hash is an unboxed integer; that said,
there is
Jim Jewett added the comment:
> I have a lock that may or may not be currently held when I release it,
> and now I know I can just catch RuntimeError in that case.
Only if you're willing to make assumptions about the threading model and the
source of locks. And I fear the cur
Jim Jewett added the comment:
(1) Why did you change the name of the parameter from index to element? If
the underlying engine also accepts indices (e.g., self.activate(4) ) then the
name should stay. If it really is only meaningful to use the name of an
element -- maybe it should still
Jim Jewett added the comment:
On Fri, Apr 6, 2012 at 4:03 PM,
Daniel Stutzbach added the comment:
>> __del__ methods do run, even if an object was collected by the cycle
>> detector. And they can't do any harm that couldn't also be done by a C
>> finalizer
Jim Jewett added the comment:
On Fri, Apr 6, 2012 at 10:32 PM, R. David Murray wrote:
> R. David Murray added the comment:
> I, on the other hand, would prefer if it were made part of the API contract
> that an
> error is raised, and to fix any stdlib implementations *of th
Jim Jewett added the comment:
Vinay,
The current question is what contract locks should follow, and whether
all locks should follow it. Would it be acceptable for
logging._releaseLock to raise a RuntimeError if the lock hadn't
previously been acquired? In other words, would it be accep
Jim Jewett added the comment:
@Brian -- to clarify,
(1) Does issue3561.diff completely supersede prependpath_in-progress.diff?
(And should that be the one currently subject to review?)
(2) What happens with multiple installations? Do users have to manually unset
the path to avoid
Jim Jewett added the comment:
What do you think it should do?
My thought is that meta tags may or may not be void, but certainly should not
be nested. As XML, I would parse that as
*missing closing tag
But for html, there is more cleanup. The catch is that this module
Jim Jewett added the comment:
FWIW, doing a linear probe only within a cache line (changing the 1's bit)
before applying perturb might also be useful -- and the results may change if
the size of a dictentry were reduced. (Mark Shannon's now-integrated patch
doesn't actually
Jim Jewett added the comment:
Stefan Krah has a good point.
Since the only cost is an extra slot, and this is for users who have already
chosen to use Decimal instead of a more efficient (but possibly less accurate)
representation, even without the native speedups to Decimal ... I guess
Jim Jewett added the comment:
-1 on that particular patch.
(with only whitespace between "/" and ">") strikes me as obviously intending to
close the tag, and a reasonably common error.
I can't think of any reason to support nested meta tags while not supporti
Jim Jewett added the comment:
This issue is also marked for (bugfix-only) 2.7 and 3.2.
Unless there is a specification somewhere (or at least an editor's draft), I
can't really see any particular parse as a bugfix. Was the goal just to make
the parse finish, as opposed to sto
New submission from Jim Jewett :
The C linkage is guarded by WITH_THREAD. The 'extern "C" {' and '}'
declarations should be in effect regardless of threading.
Note that the bug can only be triggered by compiling without threads, but with
a C++ compiler; this
Jim Jewett added the comment:
http://hg.python.org/cpython/file/0f114b855824/Python/pystate.c#l25
#ifdef WITH_THREAD
#include "pythread.h"
static PyThread_type_lock head_mutex = NULL; /* Protects interp->tstate_head */
#define HEAD_INIT() (void)(head_mutex |
Jim Jewett added the comment:
On Thu, Apr 12, 2012 at 7:26 PM, Ezio Melotti wrote:
> If HTMLParser doesn't parse as the HTML5 specs say,
> then it's considered a bug.
I had thought that was the goal of the html5lib, and that HTMLParser
was explicitly aiming at a much reduced m
Jim Jewett added the comment:
It sounds like this is a case where the docs should mention an external
library; perhaps something like changing the intro of
http://docs.python.org/dev/library/html.parser.html from:
"""
19.2. html.parser — Simple HTML and XHTML parser
Source
Jim Jewett added the comment:
It would be helpful to have a testcase, so that it will stay fixed.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue14
Changes by Jim Jewett :
--
title: urllib2 maybe blocks too long -> urllib2 maybe blocks too long with
small chunks
___
Python tracker
<http://bugs.python.org/issu
Jim Jewett added the comment:
Any particular reason not to add those?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue14555>
___
___
Pytho
Jim Jewett added the comment:
I can't speak for GSoC or Gerhard, but it strikes me as a reasonable first
step. An alternatives woube be writing it with fallbacks (so older sqlite can
still be used, though less efficiently). It would also be nice to clean up at
least one call
Jim Jewett added the comment:
On Fri, Apr 13, 2012 at 6:19 AM,
Antoine Pitrou added the comment:
> I don't think you need anyone's permission to commit such a fix :)
Well, *I* would, since I don't have commit privs, and don't currently
have a C dev environment wit
Changes by Jim Jewett :
--
title: http.server query string handling incorrect and inefficient ->
http.server query string handling is incorrect and inefficient
___
Python tracker
<http://bugs.python.org/issu
Jim Jewett added the comment:
(Note that the two patches are not cumulative; both would need to be applied.)
--
nosy: +Jim.Jewett
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
New submission from Jim Jewett :
PEP 12 states:
"""
To get the source this (or any) PEP, look at the top of the HTML page and click
on the date & time on the "Last-Modified" line. It is a link to the source text
in the Python repository.
"""
New submission from Jim Jewett:
https://github.com/python/cpython/blob/master/Modules/xxlimited.c#L28
#define XxoObject_Check(v) (Py_TYPE(v) == Xxo_Type)
assumes that the type cannot be subclassed, but does not say so. Since this is
demo code, it would be better to use something like
New submission from Jim Jewett:
Per
https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter
Py_Initialize() "should be called before using any other Python/C API
functions; with the exception of Py_SetProgramName(), Py_SetPythonHome() and
Py_SetPath()."
Jim Jewett added the comment:
Do you have a test case that could be used to verify a patch?
(Or even a full patch?)
--
nosy: +Jim.Jewett
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Jim Jewett added the comment:
Serhiy -- do your last two messages mean that this is now resolved?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue30
Jim Jewett added the comment:
Then why not just call join as part of the default close method?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue30
Jim Jewett added the comment:
Could join be called in a background thread, or even asynchronously? That
seems like mixing paradigms, but ...
On Jun 12, 2017 3:15 AM, "Antoine Pitrou" wrote:
>
> Antoine Pitrou added the comment:
>
> That's a good question. close
Jim Jewett added the comment:
Ideally, use .startswith('.') Instead if find, but this is a clear UI fix.
First pull request fixes doc, second fixes code. OK to apply both.
--
nosy: +Jim.Jewett
stage: -> commit review
___
Python tr
New submission from Jim Jewett :
binhex defines a module-wide constant of
REASONABLY_LARGE = 32768 # Minimal amount we pass the rle-coder
Later on, in 5 locations it does either ifp.read(128000) or
ifp.read_rsrc(128000)
It isn't clear why a different constant is used, let alone
Jim Jewett added the comment:
(Note: I am talking only about the disclosure issue; file corruption would
ideally be fixed as far back as possible, though I would be somewhat
sympathetic to a "nah, that ain't security, too late" argument.)
My current UI shows this as re
Jim Jewett added the comment:
My current UI shows this as relevant *only* to 3.4 and 3.5. If it really has
been fixed in 3.6, and the fix can't be backported, I think the risk of
breaking backup programs is enough to argue for doing nothing more than a doc
change. Anyone still usin
Jim Jewett added the comment:
On Mon, Jul 8, 2013 at 3:30 AM, Nick Coghlan wrote:
> The key difference between them relates to the following different approaches
> to handling unknown types in __eq__:
> @functools.total_ordering
> class TotallyOrderedEqualsReturnsFalse:
...
>
Jim Jewett added the comment:
> Since this is such an incredibly niche edge case
> (the ordered comparison has to return NotImplemented
> while __eq__ returns True),
*and* the types are explicitly supposed to ordered,
based on what is being tested
> I remaining consistent with
Jim Jewett added the comment:
When does the performance hit occur?
If it is only when an exception has been raised, and its own class is not
listed by the except clause, then I personally wouldn't worry about it; tracing
the MRO *could* get arbitrarily long already; it just doesn
Jim Jewett added the comment:
Chris Lambacher
On Wed, Apr 25, 2012 at 10:50 AM, Martin v. Löwis added the comment:
> lambacck: I'm -1, but I'm willing to yield ...
> regular users won't have to deal with negative
> consequences that enabling this by default may have.
Jim Jewett added the comment:
On Thu, May 24, 2012 at 8:11 PM, Brian Curtin
added the comment:
> does anyone think something like this dialog http://i.imgur.com/18zPD.png be
> helpful?
yes.
> After choosing the directory to install to and before choosing
> the features, i
Jim Jewett added the comment:
Just saw this on the checkins list; where are the other options documented?
"""
PyDoc_STRVAR(compressobj__doc__,
-"compressobj([level]) -- Return a compressor object.\n"
+"compressobj([level[, method[, wbits[, memlevel[, strategy[
Jim Jewett added the comment:
Is this really only 3.4? Since it is security-related, it seems like it should
be at least considered for older versions as well.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue15
Jim Jewett added the comment:
I'm putting it back to release blocker, because 3.3 should decide whether to
fix it/call it security/remove itself from the list.
The patch contains several small changes. I like the spelling fix (gsip ->
gzip) in a test method, but otherwise, I pr
Jim Jewett added the comment:
What is the status here?
As best I can tell from a skim,
(a) It should be broken into at least three separate issues. (Though maybe
some can just be closed instead of separated?)
(b) None of them are security holes, so we missed 2.5 and 2.6, and should now
Jim Jewett added the comment:
I am changing this from "High" to "Release blocker", because I think 3.3 should
make an explicit decision about whether to remove itself from the Affected
Versions list.
3.4 probably should too, since it is now in bug-fix mode.
Then this
Jim Jewett added the comment:
This is an enhancement, so I am changing the affected version from 3.3 to 3.5.
It is python-only, which works well with the cheeseshop.
That said, the patch is truly short; if that is really sufficient, it could
almost go into the documentation as a recipe
Jim Jewett added the comment:
What is the status of this?
Have any of the changes been applied?
Are any of the other patches still appropriate?
Is this now dependent on any other issues/any non-doc updates?
--
nosy: +Jim.Jewett
___
Python tracker
New submission from Jim Jewett:
http://docs.python.org/3.4/library/email.html#package-history
The table ends with email version 5.1, distributed with Python 3.2, and
compatible with Python 3.0 to 3.2.
Since Python 3.3 and 3.4 also distribute 5.1.0, I'm betting that the actual
compatib
Jim Jewett added the comment:
OK, if I understand *that* correctly,
(1) The locking mechanism doesn't really work, and that is too complicated to
fix in this issue. A new issue would be fine.
(2) The locking failure messes up the Table Of Contents, but that is too
comprehensive a c
Jim Jewett added the comment:
I have now also looked at cgi-doc.patch, and it is not strictly documentation
changes. I have no informed opinion on the the additional changes, but I don't
think they should go in as "doc change".
--
___
Jim Jewett added the comment:
_check_closed sounds like you expect it to be closed, and might even assert
that it is closed, except that you want the check run even in release mode
and/or it might fail. Since being closed is actually the unexpectedly broken
state, I would prefer that you
Jim Jewett added the comment:
I think the requested timing regression was for the non-broken case. When the
database has NOT been closed, and keys() still works, will it be way slower
than before?
Note that I am not asking you to do that test (though the eventual committer
might); the
Jim Jewett added the comment:
Pinging Martin ... earlier comments seem to have been completed.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue19
Jim Jewett added the comment:
ProcessPoolExecutor already defaults to using cpu_count if max_workers is None.
Consistency with that might be useful too. (and a default of 1 to mean
nothing in parallel is sensible...)
--
nosy: +Jim.Jewett
Jim Jewett added the comment:
I confirm the bug.
The patch looks good.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue21362>
___
___
Pytho
Jim Jewett added the comment:
pinging David Watson: What is the status? If I understand correctly, (and I
may well not), you have already opened other issues for parts of this, and
(only) the final patch is ready for patch (and hopefully) commit review. Is
this correct
Jim Jewett added the comment:
I don't know for sure if the compatibility claims are correct, but the patch
looks good.
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org
Jim Jewett added the comment:
Trying to put bounds on the disagreements. Does anyone disagree with any of
the following:
(1) compileall currently runs single-threaded in a single process.
(2) This enhancement intends to allow parallelization by process.
(3) Users MAY need to express
Jim Jewett added the comment:
I'm leaving it as "needs patch" because it isn't clear exactly what a committer
should do.
I think the current intent is to make the changes listed in
zipfile_???_filename_mismatch_v2.patch (which are not listed as reviewable --
but th
Jim Jewett added the comment:
Presumably the stacklevel applies to all versions; verifying that it warns
about the right code location is important enough to require a test case.
--
___
Python tracker
<http://bugs.python.org/issue6
Jim Jewett added the comment:
On Wed, Apr 30, 2014 at 3:05 PM, Adam Polkosnik wrote:
> test.zip up there is the test case for this change. Is there any other test
> case needed?
ah; I see the confusion. test.zip is test *data*. When I asked for a
test *case*, I meant something that e
Jim Jewett added the comment:
On Wed, Apr 30, 2014 at 3:11 PM, Adam Polkosnik
> I've got some test cases where the zlib_forward_slash.patch doesn't cut it.
My recommendation (and I could be convinced otherwise) would be to replace
if fname_str != zinfo.orig_filename:
Jim Jewett added the comment:
On Fri, May 2, 2014 at 1:14 AM, Adam Polkosnik
> The problems documented here are related to two cases (both apparently
> arriving from world of windows):
Good! I had thought you had even more!
> 1. two relative paths with inverted slash in one of t
Jim Jewett added the comment:
Did you try 3.5 without the patch, in case the issue is not with his code?
On May 13, 2014 7:23 AM, "Serhiy Storchaka" wrote:
>
> Serhiy Storchaka added the comment:
>
> Claudiu, your benchmark is broken, it measure a no-op.
Jim Jewett added the comment:
I'm still not seeing why these changes are sufficiently desirable to justify
the code churn. Nor am I seeing test or doc changes that would explain the
advantages of the new way, and prevent future regressions.
I agree that the changes would make the signa
Jim Jewett added the comment:
I think the new wording is an improvement, but keeping the changes minimal left
it in an awkward in-between state.
Proposal:
A string is a sequence of Unicode code points. Strings can include any
sequence of code points, including some which are semantically
Jim Jewett added the comment:
And even my rewrite showed path dependency; a slight further improvement is to
re-order encoding ahead of bytes. I also added a paragraph that I hope answers
the speed issue.
Proposal:
A string is a sequence of Unicode code points. Strings can include any
Jim Jewett added the comment:
Following up on Mark Lawrence's comment: http://bugs.python.org/issue12572 is
collecting the patches required to compile under HP/UX, and the patch there
supersedes those on this issue. Closing.
--
nosy: +Jim.Jewett
resolution: -> duplicat
Jim Jewett added the comment:
Added version 3.5; is 3.4 somehow still correct?
Set stage to patch review as there are still comments to deal with, but it
looks pretty close to commit review.
--
nosy: +Jim.Jewett
stage: -> patch review
versions: +Python
Jim Jewett added the comment:
As best I can tell, this renames the original get_code to _get_code, and then
delegates to it after handling the imp.PY_FROZEN case ... why not just add
imp.PY_FROZEN to the if/elif chain in the original method?
I also note that the call to self._fix_name doesn&#
Jim Jewett added the comment:
I agree with R. David Murray, but it may be worth adding a clarification
sentence (or an example with sorted) to the documentation.
Changing status to Pending, in hopes that any doc changes would be quick.
--
nosy: +Jim.Jewett
resolution: -> not a
Jim Jewett added the comment:
(1) The patch is just to docs, not code, so I'm not entirely sure that I
understood it properly.
(2) The new semantics are a huge mess to explain. This might be because the
old semantics were bad, but the result is the same. I think it would be bette
New submission from Jim Jewett:
Inspired by https://mail.python.org/pipermail/python-dev/2014-June/135029.html
and the following thread.
"""
Normal Windows behavior:
>hg status --rev ".^1"
M mercurial\commands.py
? pysptest.py
>hg status --rev .^
101 - 200 of 261 matches
Mail list logo
