Tim Peters added the comment:
@pacosta, if Mark's answer is too abstract, here's a complete session showing
that the result you got for gcd(2.7, 107.3) is in fact exactly correct:
>>> import fractions
>>> f1 = fractions.Fraction(2.7)
>>> f2 = frac
Tim Peters added the comment:
There's actually enormous backtracking here. Try this much shorter regexp and
you'll see much the same behavior:
re_utf8 = r'^([\x00-\x7f]+)*$'
That's the original re_utf8 with all but the first alternative removed.
Looks like passing s
Tim Peters added the comment:
Yes, if you remove the first "+", the example quickly prints None (i.e.,
reports that the regexp cannot match the string).
--
___
Python tracker
<http://bugs.python.o
Tim Peters added the comment:
[Senthil Kumaran]
> I am unaware of the optimization technique you refer to as
> well, it will helpful if you could point to any resource.
It's an old trick since the very first Pythons: global lookups are
much slower than local lookups (the difference
Tim Peters added the comment:
Here with 2.7.5 on Windows (Vista):
C:\Python27>python.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more infor
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 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
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 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:
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:
-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 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 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 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: +
Tim Peters added the comment:
Think this is related to why the FreeBSD default buildbot is always failing now?
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/5619/steps/test/logs/stdio
Like:
File
"/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib
Tim Peters added the comment:
Use
-0x7FFF-1
Nobody should complain about that, because it's standard C ;-)
On Sun, Oct 27, 2013 at 3:20 PM, Tim Golden wrote:
>
> Tim Golden added the comment:
>
> I don't think it will, given MS description of the comp
Tim Peters added the comment:
@Serhiy, nope, pressed for time today :-(
--
___
Python tracker
<http://bugs.python.org/issue19418>
___
___
Python-bugs-list mailin
Tim Peters added the comment:
Yes, it should be taken care of already, because of this in PC/pyconfig.h:
#ifdef MS_WIN32
...
#define SIZEOF_LONG_LONG 8
That defines the symbol triggering the PY_UINT64_T define shown in the original
message in this issue.
--
nosy: +tim.peters
Tim Peters added the comment:
Just another data point: runs fine on Vista, 32-bit box, Python 2.7.5. Python
is consuming about 320MB when the dict is done building.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
The decision to omit microseconds when 0 was a Guido pronouncement, back when
datetime was first written. The idea is that str() is supposed to be friendly,
and for the vast number of applications that don't use microseconds at all,
it's unfriendl
Tim Peters added the comment:
I don't know, Skip. Since `.isoformat()` and `str()` have *always* worked this
way, and that was intentional, it's probably going to take a strong argument to
change either.
--
___
Python trac
New submission from Tim Peters:
This showed up on StackOverflow:
http://stackoverflow.com/questions/19749757/print-is-blocking-forever-when-printing-unicode-subclass-instance-from-idle
They were using 32-bit Python 2.7.5 on Windows 7; I reproduced using the same
Python on Windows Vista. To
Tim Peters added the comment:
Do we have a theory for _why_ IDLE goes nuts? I'd like to know whether the
patch is fixing the real problem, or just happens to work in this particular
test case ;-)
--
___
Python tracker
<http://bugs.py
Tim Peters added the comment:
"Special cases aren't special enough to break the rules." ;-)
--
nosy: +tim.peters
___
Python tracker
<http://bugs.pyt
Tim Peters added the comment:
Sure looks like the bug where virtually _any_ two lines entered in the shell
cause a segfault.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Betting this is a duplicate of:
http://bugs.python.org/issue18458
--
___
Python tracker
<http://bugs.python.org/issue19516>
___
___
Tim Peters added the comment:
[@haypo]
> http://python.dzone.com/articles/diagnosing-memory-leaks-python
> Great job! Using mmap() for arenas is the best solution for this issue.
? I read the article, and they stopped when they found "there seemed to be a
ton of tiny little obj
Tim Peters added the comment:
Reassigned to Barry, since he wrote this module ;-) FWIW, I wouldn't change
it. It wasn't intended to be educational, but a newbie could learn quite a bit
by figuring out how it works.
--
assignee: tim.peters -> barry
Tim Peters added the comment:
Nice catch! That's insane. `start` and `stop` should indeed be swapped, *and*
the `return` should be `continue`. I didn't write the test, but these things
are obvious to my eyeballs ;-)
--
nosy: +
Tim Peters added the comment:
Yup, the patch is semantically correct. But I'd also swap the order of the
`start =` and `stop =` lines - *everyone* expects `start` to be set first ;-)
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
Goodness. Name it
_Py_DOWNCAST_AND_IN_DEBUG_MODE_ASSERT_UPCASTING_THE_RESULT_COMPARES_EQUAL_TO_THE_ORIGINAL_ARGUMENT
;-)
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
FYI, the test fails on my box (32-bit Windows Vista) about 1 time in 3. Here's
the latest failure:
AssertionError: 1385160333.612968 not greater than or equal to
1385160333.6129684
And here's another:
AssertionError: 1385160530.348423 not greater tha
Tim Peters added the comment:
Here's a failure with the patch:
self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
AssertionError: 1385161652120374900 not greater than or equal to
1385161652120375500
And another:
AssertionError: 1385161754170484000 not greater than or equ
Tim Peters added the comment:
[MvL]
> One "obvious" conversion error is this code from
>
> http://hg.python.org/cpython/file/4101bfaa76fe/Python/pytime.c#l35
>
> microseconds = large.QuadPart / 10 - 116444736;
>
> This discard the 100ns part of the curr
Tim Peters added the comment:
Steve, I'm afraid sleeping 100ns wouldn't be enough. The more data I collect,
the more bizarre this gets :-(
Across 300 runs I recorded the difference, in nanoseconds, between the "old"
and "new" timestamps. A negative difference
Tim Peters added the comment:
I have a different theory about this. As explained all over the place, on FAT
file creation times are good to 10 milliseconds but modification times only
good to 2 seconds. But I can't find one credible word about what the various
precisions are for NTFS.
Tim Peters added the comment:
Martin, I don't see how:
> What *can* happen is that ts1 > T(ts2)
_in this test_. As shown in many failure examples *both* nanosecond timestamps
had non-zero nanoseconds. Like:
AssertionError: 1385161652120374900 not greater than
Tim Peters added the comment:
Antoine, FYI, with the current code test_pathlib passed 500 times in a row on
my box. Success :-)
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Tim Peters:
1>..\Modules\_pickle.c(710): warning C4293: '>>' : shift count negative or too
big, undefined behavior
1>..\Modules\_pickle.c(711): warning C4293: '>>' : shift count negative or too
big, undefined behavior
1>..\Modules\_p
Tim Peters added the comment:
Just noting for the record that a C double (time.time() result) isn't quite
enough to hold a full-precision Windows time regardless:
>>> from datetime import date
>>> d = date.today() - date(1970, 1, 1)
>>> s = int(d.total_secon
New submission from Tim Peters:
With current default branch, test_asyncio always fails on my 32-bit Windows
Vista box, in test_wait_for_handle:
test test_asyncio failed -- Traceback (most recent call last):
File "C:\Code\Python\lib\test\test_asyncio\test_windows_events.py", lin
Tim Peters added the comment:
I agree overall with Martin, although time.time() could be made a little better
on Windows by getting the Windows time directly (instead of "needlessly" losing
info by going thru pygettimeofday).
--
___
Pyth
Tim Peters added the comment:
@sbt, this is reproducible every time for me, so if there's anything you'd like
me to try, let me know. I don't know anything about this code, and gave up
after half an hour of trying to find out _where_ `False` was coming from - too
convolut
Tim Peters added the comment:
[MvL]
> A. t1=t2=1385161652120375500
> B. pygettimeofday truncates this to 1385161652.120375
> C. time.time() converts this to float, yielding
> 0x1.4a3f8ed07b439p+30 i.e.
> (0.6450161580556887, 31)
> 1385161652.120375 (really .120
New submission from Tim Peters:
With the current default branch, test_venv fails every time for me:
[1/1] test_venv
Traceback (most recent call last):
File "C:\Code\Python\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File
Tim Peters added the comment:
Ah, I didn't even notice the "S" in "HTTPS"! I'm not building the SSL cruft on
my box, so it's not surprising that anything requiring it would fail. It is
surprising that this is the on
Tim Peters added the comment:
FYI, here's the new output:
[1/1] test_venv
test test_venv failed -- Traceback (most recent call last):
File "C:\Code\Python\lib\test\test_venv.py", line 289, in test_with_pip
self.run_with_capture(venv.create, self.env_dir
Tim Peters added the comment:
[Alexandre Vassalotti]
> I've finalized the framing implementation in de9bda43d552.
>
> There will be more improvements to come until 3.4 final. However, feature-wise
> we are done. Thank you everyone for the help!
Woo hoo! Thank YOU for the hard
New submission from Tim Peters:
Alexandre, this started after your latest checkin (to finish the framing work):
==
FAIL: test_framing_large_objects (test.test_pickletools.OptimizedPickleTests)
(proto=4
Tim Peters added the comment:
OK! This went away after a68c303eb8dc was checked in.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
@sbt, success! With the patch, test_asyncio passed 10 times in a row on my
box. Ship it :-)
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Possibly related: the successful test runs occurred running test_asyncio in
isolation on a quiet machine. Then I fired off a full run of the test suite
and used the machine for other things too. Then it failed:
[ 23/387] test_asyncio
... various unclosed
New submission from Tim Peters:
Worked OK yesterday, using current default branch in all cases.
C:\Code\Python\PCbuild>.\\python_d -Wd -E -bb ../lib/test/regrtest.py
test_concurrent_futures
[1/1] test_concurrent_futures
Fatal Python error: Segmentation fault
Current thread 0x0590 (m
Tim Peters added the comment:
Hmm. Looks like it's dying in gcmodule.c's visit_decref(), here:
if (PyObject_IS_GC(op)) {
So it may or may not trigger depending on the vagaries of when cyclic gc runs.
For op, op->_ob_next, _ob_prev, ob_refcnt, and ob_type are all 0xddd
Tim Peters added the comment:
BTW, I believe 0x is what MS's debug libraries use to overwrite memory
that's already been free()'d - akin to PyMalloc's "DEADBYTE".
--
___
Python tracker
<
Tim Peters added the comment:
Zach, after pulling again and rebuilding, still failing in what looks like the
same way.
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Zach, that could be - my box is *really* screwed up now - going to reboot and
try again.
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Yup, a reboot & rebuild fixed it. I think stray processes left over from older
test runs were preventing a rebuild from replacing my debug DLL. Gotta love
Windows ;-)
--
resolution: -> fixed
stage: -> committed/rejected
status: open ->
Tim Peters added the comment:
Zach, I'll try the patch soon. Will this kill _all_ Python processes? I often
have some unrelated Python program(s) running when waiting for a development
build to finish, so that could create real havoc.
BTW, I'm sure you're right that zombie P
Tim Peters added the comment:
OK, looked at the code and sees that it tries to kill only pythons created by
the build process - I feel batter now :-)
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Done. I wasn't able to provoke the failing test into leaving behind rogue
processes, so I eventually just ran some python_d processes of my own. Of
course that stopped the build from replacing the executables, so
test_concurrent_futures kept failing.
But
New submission from Tim Peters:
Using current default branch:
FAIL: test_find_mac (test.test_uuid.TestUUID)
--
Traceback (most recent call last):
File "C:\Code\Python\lib\test\test_uuid.py", line 378, in tes
Tim Peters added the comment:
Seeing the same failure on a buildbot:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3474/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue19
Tim Peters added the comment:
Is it _documented_ that MEMOIZE and PUT can't be used together? If not, it
should be documented; and pickletools dis() and optimize() should verify that
this restriction is honored in their inputs.
--
___
P
Tim Peters added the comment:
I agree this is a bug, and at a first scan your fix looks good. I'll make it a
priority to pay more attention to it now ;-)
--
assignee: -> tim.peters
___
Python tracker
<http://bugs.python.org
Tim Peters added the comment:
On second thought, I don't want to use a regexp for this. The mandatory colon
_was_ a kind of absolute wall, and the various instances of "[^:]" exploited
that to avoid unintended matches.
But "possibly dotted name followed pos
1001 - 1100 of 1332 matches
Mail list logo
