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:
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:
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:
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
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:
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
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:
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:
Looks Good To Me
--
nosy: +Jim.Jewett
___
Python tracker
<https://bugs.python.org/issue41391>
___
___
Python-bugs-list mailin
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:
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:
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:
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:
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:
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:
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:
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:
Looks good to me.
--
nosy: +Jim.Jewett
___
Python tracker
<https://bugs.python.org/issue41217>
___
___
Python-bugs-list mailin
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:
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:
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:
(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
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:
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:
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()."
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
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:
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:
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:
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:
When I see a message like that, it normally means there is a firewall getting
in my way.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue28
Jim Jewett added the comment:
https://mail.python.org/pipermail/python-ideas/2016-November/043539.html by
Chris Barker points out that a custom object (which doesn't ever store the
missing "keys") may be better still... though I'm not sure it is better enough
to
New submission from Jim Jewett:
One commonly needed string transformation is stripping out certain characters
(or only keeping certain characters). This is common enough that it might be
worth a dedicated method, except, that, as Stephen J. Turnbull wrote in
https://mail.python.org/pipermail
Changes by Jim Jewett :
--
title: gzip guessing of mode is ambiguilous -> gzip guessing of mode is
ambiguous
___
Python tracker
<http://bugs.python.org/issu
Jim Jewett added the comment:
Having to (re-)fill the cache once per interpreter seems like a reasonable
price to pay.
Why is 3.5 not included? Did this not cause problems before the import change,
or is it just that this bug is small enough that maybe it isn't worth
backpo
Jim Jewett added the comment:
In general, the rule is that micro versions (such as 3.4.4 to 3.4.5)
should not make any changes that are not clearly bug fixes. If users would
call the new API (or ABI) differently, it is almost certainly a change that
should be reserved for a development release
Jim Jewett added the comment:
On Sep 6, 2016 10:55 PM, Donald Stufft added the comment:
> In the hypothetical case we don't backport ChaCha20 support and 3DES and
AES constructs in TLS are no longer secure... what do you do? Do you just
plug your fingers in your ears and hope nobody att
Jim Jewett added the comment:
I think a python call is fine to require ... if they don't have the python
source they should have a support contract. I assume the advice followed is
intermediate, based on the earlier comment about xp and ie?
On Aug 26, 2016 9:46 AM, "Christian Heim
Jim Jewett added the comment:
Is there a way to document why certain warnings are being suppressed, in case
someone wants to revisit the suppression later?
--
nosy: +Jim.Jewett
___
Python tracker
<https://bugs.python.org/issue25
Jim Jewett added the comment:
I think if the test is ensuring one line-ending type, then there should be
another test ensuring the other... but I think it would be best if there were a
single test file that had both types of line-endings, just to ensure that the
code doesn't cheat by re
Jim Jewett added the comment:
What does overriding to put it back require?
Does it require a re-compile, or can it be done via a config file?
Taking it out of the default set sounds reasonable, but requiring a recompile
for people who want to retain backwards compatibility strikes me as too
Changes by Jim Jewett :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue27021>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Jim Jewett :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue27038>
___
___
Python-bugs-list mailing list
Unsubscrib
Jim Jewett added the comment:
Looks Good To Me
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue27032>
___
___
Python-bugs-list mailin
Jim Jewett added the comment:
The modulus fixes it for exact numbers. It doesn't produce exactly the same
result with floats, because of rounding. Is that a problem?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/is
Jim Jewett added the comment:
It feels a bit odd to say that I've performed a triage review given the three
people already involved -- but I did, and I think it is ready to commit.
I believe it is a bug fix, but too subtle a bug to justify backporting.
The only question is whether
Jim Jewett added the comment:
Even if Ethan's argument about an explicit start value were not convincing,
Mark + Raymond would count as authoritative for floats.
Anyone can reopen if needed; I just don't want the issue to languish forever if
there is at least grudging
Jim Jewett added the comment:
Does (did?) the utf8 special case allow for a much faster startup time, by not
requiring all of the codecs machinery?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue25
Jim Jewett added the comment:
I think the warning was helpful; it just had confusing wording.
Instead of: """
>>> def f():
... False
...
:2: SyntaxWarning: ignore constant statement
"""
perhaps: """
>>> def f():
... False
New submission from Jim Jewett:
https://docs.python.org/3/library/dis.html includes a section describing the
various opcodes.
Current documentation: """
Coroutine opcodes
GET_AWAITABLE
Implements TOS = get_awaitable(TOS), where get_awaitable(o) returns o if o is a
corout
Changes by Jim Jewett :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue25216>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jim Jewett:
warnings.warn(stacklevel=2) is a longstanding idiom.
It broke in 3.3 because python itself added some additional infrastructure
frames in between; now stacklevel should be 8 or 10 in some releases.
issue24305 adds a workaround for 3.5, to ignore internal frames
Jim Jewett added the comment:
On windows, when python is started from the command line without a GUI,
os.isatty(sys.stdin) raises an error, but os.isatty(sys.stdin.fileno()) returns
true.
Within IDLE, os.isatty(sys.stdin.fileno()) also raises an error, but
os.isatty(0), os.isatty(1), and
Jim Jewett added the comment:
Instead of using python directly in a subprocess, try calling a shell command
that in turns calls python. (Admittedly, this may look like the pipe
scenario...)
In theory, you could even drive another python interactively, using a GUI
runner, but I'm not
Jim Jewett added the comment:
Terry: Was removing the public attribute keys OK?
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue24
Jim Jewett added the comment:
I've changed the stage to "test needed".
At a minimum, an interactive test should be written and added to the
documentation. Better would be an automated test (perhaps via subprocess).
The documentation should also be updated; at a minimum, th
Jim Jewett added the comment:
Eric I realize that O (1) deletion is hard, and don't see a good way
around it without changing the implementation ... I just think that the
preserving the current C layout may be forcing an even more complicated
solution than neccessary. I am nervous
New submission from Jim Jewett:
The specialized lookdict_* variants replace themselves with the generic
lookdict as soon as a non-unicode key is looked up.
They could reasonably leave the replacement to insertdict (line 819, currently
assert rather than a replacement), when a non-unicode
New submission from Jim Jewett:
https://hg.python.org/cpython/file/2df7c958974e/Objects/dictobject.c#l451
The comments near lookdict suggest that specialized versions such as
lookdict_unicode and lookdict_unicode_nodummy cannot return NULL, as that would
indicate an Exception was raised
Jim Jewett added the comment:
Should dictobject.h get a bit more changes? In particular, should the
following be expanded?
#define PyDictKeys_Check(op) (Py_TYPE(op) == &PyDictKeys_Type)
#define PyDictItems_Check(op) (Py_TYPE(op) == &PyDictItems_Type)
#define PyDictValues_Check(op)
Jim Jewett added the comment:
(Just putting my review summary in the main ticket)
I'm going to echo the previous comment that maybe trying to emulate the
existing dict implementation too carefully just adds complexity.
The split-keys implementation shows that there is at least
Jim Jewett added the comment:
Eric, unless I'm misreading your debugging info, it is the other way around --
something is in the dict, but not in the list that you iterate over.
And since the list that you iterate over looks right, I have to wonder if it
was something intern
Jim Jewett added the comment:
Why does generated file Include/opcode.h show up as changed? It looks like
pure whitespace, but I wonder if a similar whitespace change might be making
something a space too long somewhere.
--
nosy: +Jim.Jewett
Jim Jewett added the comment:
OK, then how about
Current:
"""
When a generator function is called, it returns an iterator known as a
generator. That generator then controls the execution of a generator function.
The execution starts when one of the generator’s methods is called
New submission from Jim Jewett:
https://docs.python.org/3/reference/expressions.html#yield-expressions
Current:
"""
When a generator function is called, it returns an iterator known as a
generator. That generator then controls the execution of a generator function.
The execut
Jim Jewett added the comment:
I think that instead of application/zip, you want application/zipped-python (or
whatever the precise term was). This was one reason to register the MIME type.
That said, application/zip is probably not harmful; the worst it should do it
hand the archive to a
Jim Jewett added the comment:
That sounds like a bug magnet to me; my mental model is that the codec
is my output; flushing it will push things out, and resetting it will
erase anything pending. I don't care if some implementation detail
means that some other object technically owns the b
Jim Jewett added the comment:
I interpreted Issue 15's closure as being about the distinction between
Application/webm vs Video/webm, etc.
As far as I understand it, the python stdlib doesn't actually care what the
major Mime type is, or, frankly, even whether the definition makes
Jim Jewett added the comment:
I wish there were an APIMismatchError superclass to unify
(AttributeError, TypeError). But the wart probably isn't enough to
justify the surgery.
On Thu, Nov 6, 2014 at 8:48 AM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>
Jim Jewett added the comment:
If I know that a Counter (or any class X) can be updated in place, I will be
surprised to find out that I'm using a different instance after a successful
in-place operation.
I would even consider that (replacement of the original instance) a security
Jim Jewett added the comment:
Ah... "be the same object or compare equal" sounds much better.
I don't want "same" to sound like an informal wording for equal, because
getting rid of the confusion over NaN and similar objects is the whole
point of the revision. On the
New submission from Jim Jewett:
https://docs.python.org/3.5/reference/expressions.html#not-in
Containers are permitted to (and generally do) read "same as" as "is or
__eq__), which can be confusing -- particularly in the section defining __eq__.
Several suggested changes:
New submission from Jim Jewett:
https://docs.python.org/3.5/library/stdtypes.html
says "Objects of different types, except different numeric types, never compare
equal."
Despite the location, this seems to strong a statement, because of subclasses
and classes which define __eq__
Changes by Jim Jewett :
--
stage: -> needs patch
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue21800>
___
___
Python-bugs-list
Jim Jewett added the comment:
(The above concerns -- other than whether it is sufficient to work -- do not
apply to the change at
https://bitbucket.org/ironpython/ironlanguages/commits/b6bb2a9a7bc5/ )
--
___
Python tracker
<http://bugs.python.
Jim Jewett added the comment:
It would be good to have the library work unchanged on both implementations.
If subprocess only failed later, it would be less good, as the stdlib would
then set an example that doesn't actually succeed.
Note that the attached patch (by flox) does NOT impl
Jim Jewett added the comment:
On Jun 14, 2014 4:05 AM, "Aymeric Augustin"
> preserving the same behavior by default
That is a requirement, because of backwards compatibility.
> providing more control for users who need a different behavior, for
instance people who use SQLite a
Jim Jewett added the comment:
Removing the existing behavior will almost certainly not be accepted, because
of backwards compatibility.
Adding new functionality is generally acceptable.
Doing that through a new keyword that defaults to the old behavior is fairly
common, and generally better
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 .^
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
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:
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:
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:
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:
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:
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:
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:
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:
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:
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 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:
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:
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:
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 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:
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 confirm the bug.
The patch looks good.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue21362>
___
___
Pytho
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:
Pinging Martin ... earlier comments seem to have been completed.
--
nosy: +Jim.Jewett
___
Python tracker
<http://bugs.python.org/issue19
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
1 - 100 of 261 matches
Mail list logo