Tim Golden added the comment:
I'm at best +0.25, but I don't have a problem with Ctrl-D exiting on
Windows, as it doesn't do anything else!
The thing is, though, that this is all handled within
myreadline.c:my_fgets which is a call into the system fgets which errors
out
Tim Golden added the comment:
Nope. Looks like a mistake. Confusingly, the header refers to VC++ 10.0
which is VS 2010 (I think). AFAICT a global s/2008/2010/ would be the
thing to do.
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Good catch! Would like to hear from Raymond what the intent of these tests was
- looks like "the real" test_get_only (which hasn't been executing) has
multiple failures.
--
nosy: +tim.peters
___
Python
Tim Golden added the comment:
I'll try to pick this one up over the next few days. Feel free to ping me if it
drops into silence!
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org
Tim Golden added the comment:
In reality (as I'm sure you can guess) it's just that no-one's got to
the point of fixing it. I did start off, but it's not a trivial fix and
clearly it got sidelined (with no-one shouting). Sometimes that's just
the way it is.
I'll
Tim Peters added the comment:
The possible use cases are so varied & fuzzy it seems better to use an object
for this, rather than funk-ify `fsum`. Say, class Summer. Then methods could
be invented as needed, with whatever state is required belonging to Summer
objects rather than pa
New submission from Tim Peters:
This question:
http://stackoverflow.com/questions/19128219/detect-windows-8-1-in-python
reports that Python is returning incorrect version info under Windows 8.1.
Alas, it appears MS is "deprecating" `GetVersionEx()`:
http://msdn.microsoft
Tim Golden added the comment:
I was surprised that GetVersionEx would lie. But sure enough. Here:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200
(Including a heartfelt comment by long-time Python
Tim Golden added the comment:
I've just installed a Win 8.1 VM and can (unsurprisingly) confirm the
report: The "ver" command shows 6.3.9600 while GetVersionEx and
consequently sys.getwindowsversion report 6.2.9200
We do use GetVersionEx in a few other places (timemodule.c,
Tim Golden added the comment:
platform.platform & platform.uname are also affected although they already use
"ver"-parsing in some circumstances so could presumably fallback to that
approach here as well.
--
nosy: +lemburg
___
Python
New submission from Tim Peters:
I'm sure this flaw exists on more than just the current default branch, but
didn't check.
BoundedSemaphore.release() doesn't quite do what it thinks it's doing. By
eyeball, the code obviously suffers from a small timing hole: multiple t
Tim Peters added the comment:
Richard, that's a strange argument ;-) Since, e.g., a BoundedSemaphore(1) is
semantically equivalent to a mutex, it's like saying some_mutex.release()
usually raises an exception if the mutex isn't held at the time - but maybe it
won't. If
Tim Peters added the comment:
Good idea! The patch looks almost ready to me: the comment block before the
code block should be updated, since recomputing `base` is no longer being done
_just_ to force `base` to a non-negative value.
--
nosy: +tim.peters
stage: -> patch rev
Tim Peters added the comment:
A bit of history: last time I fiddled that code, I didn't worry about this,
because for large enough exponents all internal numbers _eventually_ become
less than `base`. But the patch can speed up the _startup_ costs by an
arbitrary amount (for sm
Tim Peters added the comment:
Grr: should be: "all internal numbers _eventually_ become less than
`modulus`", not "less than `base`".
--
___
Python tracker
<http://bug
Tim Peters added the comment:
New patch changes the comments to match the new code.
--
Added file: http://bugs.python.org/file31969/pow.diff
___
Python tracker
<http://bugs.python.org/issue19
Changes by Tim Peters :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
I'm old, but I liked the docs better when they didn't mention "the int
argument" at all. The "int=int" - or "_int=int" - argument is a CPython
implementation detail. It has nothing to do with the API. And _of course_
Tim Peters added the comment:
Attached patch, which closes the timing hole, and adds a new basic sanity test.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31979/boundsem.patch
___
Python tracker
&l
Tim Peters added the comment:
New patch makes the test case do what I intended it to do ;-)
--
Added file: http://bugs.python.org/file31981/boundsem2.patch
___
Python tracker
<http://bugs.python.org/issue19
Tim Golden added the comment:
This was implemented after discussion in issue1115886:
http://bugs.python.org/issue1115886
and python-dev:
https://mail.python.org/pipermail/python-dev/2007-March/071557.html
In short, it could have gone either way and it went this way.
--
nosy
Changes by Tim Golden :
--
resolution: -> wont fix
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue19191>
___
___
Python-bugs-
Tim Peters added the comment:
I'll revert the 2.7 change if people agree that's a good thing. I'm fine with
it as-is. Armin pulled the idea from timing a Python public-key crypto project
(see the original message in this report), where he found a 14% improvement.
I don't
Tim Peters added the comment:
This is the "right" way to do it: the subclass wants to extend the behavior of
the base class .release(), not to replace it. Calling the base class
.release() is the natural and obvious way to do that. It's also utterly normal
for a lock u
Tim Peters added the comment:
I'm glad you pointed it out, Mark! You're right about unintended consequences,
and I confess I didn't think at all about the exponent == 0 case.
I didn't remind myself that 2.7 was a bugfix branch either: I read Armin's
"(which ca
Tim Peters added the comment:
Antoine, how strongly do you feel about this? I confess I don't get it.
Copy+paste code duplication doesn't help any of readability, correctness, or
ease of future maintenance, so I guess it's some micro-efficiency concern.
Really?! ;-)
Note
Changes by Tim Peters :
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue19199>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Peters :
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue19199>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Tim Heaney:
I love the 'x' mode open in recent versions of Python. I just discovered that
lzma.open doesn't support it. It seems there's an elif that explicitly checks
the modes allowed. I added "x" and "xb" to the c
Changes by Tim Heaney :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue19201>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Peters :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Tim Heaney:
This is analogous to issue19201, but for gzip. Recent versions of Python have
an 'x' mode for open, but gzip doesn't support it. It looks like everything is
passed to builtins.open eventually, so if we just allow the 'x' option to pass
New submission from Tim Heaney:
This is analogous to issue19201, but for bz2. Recent versions of Python have an
'x' mode for open, but bz2 doesn't support it. It looks like everything is
passed to builtins.open eventually, so if we just allow the 'x' option to pass
Tim Heaney added the comment:
Okay, I just made similar issues for gzip (issue19222) and bz2
(issue19223). It's weird how different these three patches are! We're
essentially doing the same thing: "please allow the x option to pass
through to builtins.open." Why don't
Tim Peters added the comment:
-0.
Since hash(None) is currently based on None's memory address, I appreciate that
it's not reliable (e.g., use different releases of the same compiler to build
Python, and hash(None) may be different between them).
The docs guarantee little
Tim Peters added the comment:
Here on 32-bit Windows Vista, with Python 3:
C:\Python33>python.exe
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
Tim Peters added the comment:
haypo, there would only be a million ints here even if the loop had completed.
That's trivial in context (maybe 14 MB for the free list in Python 2?). And
note that I did my example run under Python 3.
Besides, the OP and I both reported that Task Ma
Tim Peters added the comment:
Do what's best for the future of the module. A PEP is more of a starting point
than a constraint, especially for implementation details. And making a private
thing public later is one ginormous whale of a lot easier than trying to remove
a public thing
Tim Peters added the comment:
@haypo, this has nothing to do with PyMalloc. As I reported in my first
message, only 7 PyMalloc arenas are in use at the end of the program, less than
2 MB total. *All* other arenas ever used were released to the OS.
And that's not surprising. The vast
Tim Peters added the comment:
@Esa.Peuha, fine idea! Alas, on the same box I used before, uglyhack.c
displays (it varies a tiny amount from run to run):
65198 65145 99.918709%
So it's not emulating enough of Python's malloc()/free() behavior to trigger
the same kind
Tim Peters added the comment:
@pitrou, maybe, but seems very unlikely. As explained countless times already
;-), PyMalloc allocates few arenas in the test program. "Small objects" are
relatively rare here. Almost all the memory is consumed by strings of
ever-increasing length.
Tim Peters added the comment:
Just to be sure, I tried under current default (3.4.0a3+). Same behavior.
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
@sbt, excellent! Happens for me too: trying to allocate a 1MB block fails
after running ugly_hack() once. That fits the symptoms: lots of smaller,
varying-sized allocations, followed by free()s, followed by a "largish"
allocation. Don't know
Tim Peters added the comment:
@haypo, I'm not sure what you mean by "the low fragmentation allocator". If
it's referring to this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx
it doesn't sound all that promising for this failing
Tim Peters added the comment:
BTW, everything I've read (including the MSDN page I linked to) says that the
LFH is enabled _by default_ starting in Windows Vista (which I happen to be
using). So unless Python does something to _disable_ it (I don't know),
there's noth
Tim Peters added the comment:
Please read this:
http://docs.python.org/2/tutorial/floatingpoint.html
A web search will lead you to thousands of discussions of alternatives.
Probably best to use the `decimal` module if you're working heavily with
decimal values.
--
nosy: +tim.p
Tim Peters added the comment:
Just wondering: why is the timeout-to-failure set to a whole hour? Based on
all the messages I've seen this weekend, we could save the buildbots countless
years of time by reducing it to - say - 59 minutes ;-)
--
nosy: +tim.p
Tim Golden added the comment:
*cough* Somehow that didn't actually get pushed. Rebased against 2.7, 3.3 & 3.4
and pushed.
--
assignee: -> tim.golden
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
v
Tim Golden added the comment:
I don't feel strongly about this. However, ISTM that we work reasonably
hard to work with the vagaries of *nix toolchains so I don't see why an
unintrusive change like this shouldn't go in to support some corner
cases on th
Tim Golden added the comment:
Ok by me: build and tests all ok.
--
___
Python tracker
<http://bugs.python.org/issue17791>
___
___
Python-bugs-list mailin
Tim Golden added the comment:
Just picking this up. Considering testing... My current proposal is to add
junction point support to _winapi, initially for the sole purpose of testing
this change, but with a view to possibly supporting it formally via the os
module. Any better ideas
Tim Peters added the comment:
See the 4th comment on this post:
http://stackoverflow.com/questions/18158381/python-crashing-when-running-two-commands
Let us know whether it fixes your problem!
--
nosy: +tim.peters
___
Python tracker
<h
Tim Peters added the comment:
Oops! Now it' the 5th comment ;-) The one starting "running the following
command, I got it working ...".
--
___
Python tracker
<http://bugs.pyt
Tim Golden added the comment:
Sounds like a decent plan to me. Good luck with the buffer sizing!
--
___
Python tracker
<http://bugs.python.org/issue18314>
___
___
Tim Peters added the comment:
@Larry, you seem to be misreading this. They're not saying 3.4 can't be
released until this feature is added. It's _already_ been added. They're
saying 3.4 possibly can't be released until this feature is _removed_ - but
whether
Changes by Tim Peters :
--
priority: normal -> release blocker
title: Add SHA-3 (Keccak) support -> SHA-3 (Keccak) support may need to be
removed before 3.4
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
Just revisited this to see if I could close off. One thing occurred to me which
should have come up before: this situation will be aggravated by WOW64 file
redirection.
If I run 64-bit Python on 64-bit Windows I can successfully stat links in
%windir%\system32
Tim Golden added the comment:
I've looked this over and, basically, +1. We could argue the toss back and
forth over changes, but I think the changes do the right amount of
cruft-clearing and avoid the danger of being a mere reflection of one person's
aesthetic choices over another
Tim Golden added the comment:
Retargetted patch against current tip. If no-one objects I'll commit this in
the next day or two.
--
assignee: -> tim.golden
Added file: http://bugs.python.org/file32326/pcbuild.diff.2
___
Python tracke
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue11566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue6839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue14112>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue6335>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue6672>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue16472>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
Just housekeeping some Windows calls: Antoine, your last comment suggests that
this is no longer an issue. I don't have a VirtualBox install to test, so can
you confirm whether this can be closed?
--
___
Python tr
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue949667>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10179>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Golden :
--
resolution: -> out of date
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue10179>
___
___
Pyth
Tim Golden added the comment:
I'm running Win7 and have the same problem, with a fresh checkout and the eol
extension disabled. The attached (updated) patch does solve the issue. I can't
see any reason not to apply it, even if it's not needed in many cases.
--
A
Changes by Tim Golden :
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
I'm going to close this as won't fix: the underlying implementation is simply
calling GetFullPathName and removal of trailing spaces doesn't seem too
surprising a result. It is possible to manipulate such files using Windows'
special \\?\C:\
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue16632>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
normpath doesn't really buy anything here as abspath already has the same
effect (plus more). Patch attach removes normcase|path leaving only abspath.
--
___
Python tracker
<http://bugs.python.org/is
Tim Golden added the comment:
If no-one objects, I'll commit in a day or two.
--
Added file: http://bugs.python.org/file32328/issue14255.diff
___
Python tracker
<http://bugs.python.org/is
Tim Golden added the comment:
Santoso Wijaya: sorry for the delay. If you'd like to retarget your patch
against the tip, I'm happy to apply. At this stage, 3.3 and 3.4 seem the
appropriate branches.
--
assignee: -> tim.golden
versions: -Python 2.
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue14208>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue16353>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue18199>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue14027>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue4905>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Golden :
--
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue4905>
___
___
Python-bugs-list mailing list
Unsub
Tim Golden added the comment:
Thanks, Zachary. Do you see this going against just tip, or should it be
backported to 3.3 / 2.7? (I'm not sure how well the latter would be
received, truth be told).
--
___
Python tracker
<http://bugs.py
Changes by Tim Golden :
Removed file: http://bugs.python.org/file32328/issue14255.diff
___
Python tracker
<http://bugs.python.org/issue14255>
___
___
Python-bugs-list m
Tim Golden added the comment:
Added, including a slightly surprising change needed to test_zipimport_support
(which arguably should have been there from the start for robustness).
--
assignee: -> tim.golden
Added file: http://bugs.python.org/file32338/issue14255.2.d
Tim Golden added the comment:
Fine. I'll commit it later. (Probably tomorrow at this point)
--
___
Python tracker
<http://bugs.python.org/issue19273>
___
___
Tim Golden added the comment:
Had a to-and-fro on IRC with RDM who highlighted that an inconsistency between
os.listdir and os.path.exists (the case here) is, at least, undesirable. As it
stands, our os.exists on os.stat mechanism will fail because any attempt to get
any kind of handle via
Tim Golden added the comment:
Done. Thanks for the patch.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
Fixed on tip. Thanks for the issue and the original patch.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
This is, in principle, a backwards-incompatible change as any code will stop
working which relies on exec* running useful tools in c:\bin. (I have a
c:\tools which is basically the same thing).
Frankly, I'm -0 on changing it; it does no real harm that I ca
Changes by Tim Golden :
Removed file: http://bugs.python.org/file32338/issue14255.2.diff
___
Python tracker
<http://bugs.python.org/issue14255>
___
___
Python-bugs-list m
Tim Golden added the comment:
New patch, tested on Windows & Linux
--
Added file: http://bugs.python.org/file32362/issue14255.3.diff
___
Python tracker
<http://bugs.python.org/iss
Tim Golden added the comment:
Applied. Thanks for the patch.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
Well, when a timeout is specified, .join() passes exactly the timeout passed to
_it_ to ._wait_for_tstate_lock(), which in turn passes exactly the same timeout
to .acquire(). So the negative value must be coming from _communicate() (the
Tim Peters added the comment:
BTW, if subprocess did check the return value, it would see that the timeout
already expired, and the test would pass.
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
I think I'll change Thread.join() to just return if a timeout <= 0 is passed.
The docs don't say anything about what Thread.join() does with a negative
timeout, but at least in 2.7.5 it happened to just return. No point being
gratuitously m
Changes by Tim Peters :
--
assignee: -> tim.peters
___
Python tracker
<http://bugs.python.org/issue19399>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Peters :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Tim Peters added the comment:
@cantor, this is a Python issue tracker, not a help desk. If you want advice
about Python programming, please use the Python mailing list or any number of
"help desk" web sites (e.g., stackoverflow).
--
nosy: +
1601 - 1700 of 2346 matches
Mail list logo
