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 Golden added the comment:
If you can put together a self-contained test case which fails on
3.3/3.4 I'm quite happy to re-open this. Given the nature of the issue,
you'll have to be quite precise as to Windows version, whether 32/64,
whether running as Administrator, and ex
Changes by Tim Golden :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue19273>
___
___
Python-bugs-list mai
New submission from Tim Golden:
Modules/audioop.c is giving compile warnings on Windows against lines 18 & 437.
..\Modules\audioop.c(18): warning C4146: unary minus operator applied to
unsigned type, result still unsigned
..\Modules\audioop.c(437): warning C4146: unary minus operator app
Tim Golden added the comment:
The attached patch appears to fix the problem.
--
keywords: +patch
Added file: http://bugs.python.org/file32390/audioop.diff
___
Python tracker
<http://bugs.python.org/issue19
Tim Golden added the comment:
I don't think it will, given MS description of the compiler warning:
http://msdn.microsoft.com/en-us/library/4kh09110%28v=vs.100%29.aspx
but I'll certainly give it a go.
--
___
Python tracker
<http://bu
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 Golden added the comment:
Good idea. I'll test against Win32/64 & Linux 32
--
___
Python tracker
<http://bugs.python.org/issue19418>
___
___
Python-bu
Tim Golden added the comment:
Fixed. Thanks for the report.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
Applied. Thanks for the patch.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Tim Golden :
Removed file: http://bugs.python.org/file32390/audioop.diff
___
Python tracker
<http://bugs.python.org/issue19418>
___
___
Python-bugs-list mailin
Tim Golden added the comment:
The attached patch (using Tim Peters' -1 trick) builds & tests ok on Win32/64 &
Linux 32.
--
Added file: http://bugs.python.org/file32400/issue19418.diff
___
Python tracker
<http://bugs.pytho
Tim Golden added the comment:
Good point. Updated patch.
--
Added file: http://bugs.python.org/file32401/issue19418.2.diff
___
Python tracker
<http://bugs.python.org/issue19
Changes by Tim Golden :
Removed file: http://bugs.python.org/file32400/issue19418.diff
___
Python tracker
<http://bugs.python.org/issue19418>
___
___
Python-bugs-list m
Tim Golden added the comment:
Fine by me
--
___
Python tracker
<http://bugs.python.org/issue19433>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 Golden added the comment:
Fixed in 3.3 / 3.4
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: -Python 2.7
___
Python tracker
<http://bugs.python.or
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue19464>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Golden :
--
assignee: -> tim.golden
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10197>
___
___
Python-
Tim Golden added the comment:
Patched according to Nick Coghlan's suggestion in
http://bugs.python.org/issue9922#msg150093. Ad hoc tests look ok on Windows.
I'll add tests & look at *nix later.
--
Added file: http://bugs.python.org/file32450/i
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 Golden added the comment:
Applied to 3.3 & 3.4. Thanks for the patch.
--
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.o
Changes by Tim Golden :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19464>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Golden added the comment:
Code & tests now work on Windows. Applied to 3.3 & 3.4.
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.p
Tim Golden added the comment:
This has nearly been fixed by the rewrite of the get[status]output code under
issue10197. There is an issue, though, with the use there of universal_newlines
mode, which forces check_output to return a string rather than bytes.
--
nosy: +tim.golden
Tim Golden added the comment:
The code I've just committed to issue10197 means that the get[status]output
functions now pass their (few) tests on all platforms. More by chance than
judgement, that change employed universal_newlines which has the effect of
forcing the output of check_outp
Changes by Tim Golden :
--
assignee: -> tim.golden
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/iss
Changes by Tim Golden :
Added file: http://bugs.python.org/file32483/issue9922.34.diff
___
Python tracker
<http://bugs.python.org/issue9922>
___
___
Python-bugs-list m
Tim Golden added the comment:
Good point. I've added the versionchanged tag.
The issue with bytes-string encoding goes all the way back to
Popen.communicate if universal newlines mode is used so I've simply put
in a reference to the existing notes on the subject higher up i
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
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Golden :
--
components: +Windows
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue13674>
___
___
Python-bugs-list m
Tim Golden added the comment:
Attached is a patch with tests
--
keywords: +patch
Added file: http://bugs.python.org/file32516/issue13674.diff
___
Python tracker
<http://bugs.python.org/issue13
Tim Golden added the comment:
On 06/11/2013 15:23, STINNER Victor wrote:
> +if (strchr("y", outbuf[1]) && buf.tm_year < 0)
>
> hum... why not simply outbuf[1] == 'y' ? It would be more explicit
> and less surprising.
Ummm. I have no idea what
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 Golden added the comment:
Thanks: final outdated comments removed
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10197>
___
_
Tim Golden added the comment:
Closing this as won't fix. The code has been reimplemented and additional
documentation has been added over at issue10197. Given that these are legacy
functions, I don't propose to do any more here.
--
resolution: -> wont fix
status: o
Tim Golden added the comment:
I've committed the changes with a variant of the pre-1900 test running on all
platforms. I think there's scope for more testing of the boundary conditions of
strftime but that would be for another issue. I want to get this one in now as
it's a cra
Tim Golden added the comment:
Only just been reminded of this one; it's possible that it's been superseded by
Issue15207. At the least, that issue resulted in a code change in this area of
mimetypes. I'll have a look later.
--
no
Tim Golden added the comment:
On 14/11/2013 00:21, Laurent Birtz wrote:
> Is it reasonable to believe that most Python programs don't care
> about the legacy shell API?
No more than it is to believe that most Python programs don't care about
MSys or Cygwin ;)
For informati
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 Golden added the comment:
marshal.c does a check that the 2nd arg is a subclass of the builtin file
class. On non-Posix platforms, TemporaryFile is a wrapper class providing
context manager support for delete-on-close. This fails the subclass test.
The docs for TemporaryFile:
http
Changes by Tim Golden :
--
resolution: -> wont fix
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue19630>
___
___
Python-bugs-
Tim Golden added the comment:
Thanks, guys; I'm afraid I only watched the stable buildbots when I committed -
the AIX doesn't seem to be included.
--
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
This, unfortunately, is the classic edge-case where intra-platform consistency
and inter-platform consistency clash.
I (on Windows) would certainly be surprised if a tree delete removed read-only
files without my specifying some kind of override. I understand
Tim Golden added the comment:
TBH I'm still fairly -0 and edging towards -0.5. If we didn't already
have two keyword args I might be convinced towards a jfdi=True flag.
But, as the OP described, the current params already allow for a
workaround of sorts and another param of the
Tim Golden added the comment:
Fine with your volumepathname patch. The core of the code was contributed and I
didn't check it too carefully as it clearly worked. (For some definition of
"worked").
--
___
Python tracker
<http
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
Changes by Tim Peters :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
We should adhere to the json spec, but there's no harm (and some real good!) in
the docs pointing out notable cases where json and Python syntax differ.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.py
Tim Peters added the comment:
Fil, here's the release schedule for Python 2.8:
http://www.python.org/dev/peps/pep-0404/
In short, 2.8 will never be released (well, never by us), and only bugfixes can
be applied to the 2.7 line. That's why 2.7 was removed. Regardless of its
me
Tim Peters added the comment:
I'd rather see `i.bits_at(pos, width=1)`, to act like
(i >> pos) & ((1 << width) - 1)
That is, extract the `width` consecutive bits at positions 2**pos through
2**(pos + width - 1) inclusive.
Because Python ints maintain the illusion of havi
Tim Peters added the comment:
Raymond, I expect they have overlapping - but not identical - audiences.
There's seem to be a quite capable bitarray extension here:
https://pypi.python.org/pypi/bitarray/
--
___
Python tracker
Tim Peters added the comment:
@serhiy, Mark certainly knows the proposed addition isn't _needed_ to pick
apart 64-bit integers. It's an issue there of clarity, not O() behavior. For
example, `i.bits_at(0, 52)` to get at a double's mantissa requires no thought
at all to w
Tim Peters added the comment:
[@anon]
> What should happen next?
1. Write docs.
2. Write a test suite and test a Python implementation.
3. Write C code, and reuse the test suite to test that.
4. Attach a patch for all of that to this issue (although a
Python implementation is no lon
Tim Peters added the comment:
The weakref.slice fix looks solid to me, although it appears to be specific to
2.7 (the methods are fancier on the current default branch, fiddling with
self._pending_removals too).
Does anyone know why the signature of pop is:
def pop(self, key, *args
1701 - 1800 of 2346 matches
Mail list logo
