R. David Murray rdmur...@bitdance.com added the comment:
@AP: ran patched test on Freebsd (6.2) as requested. Result is:
test_fcntl_64_bit (test.test_fcntl.TestFcntl) ... skipped 'F_NOTIFY or
DN_MULTISHOT unavailable'
--
nosy: +r.david.murray
___
New submission from Thomas Reiter thom...@nikhef.nl:
On a 64-bit Linux machine the attached program generates the following
(shortened) output:
$ python bug.py
...
after 2145.49s:
after 2145.82s:
after 2146.14s:
after 2146.47s:
after 2146.80s:
after 2147.13s:
after 2147.45s:
after
Antoine Pitrou pit...@free.fr added the comment:
time.clock() is a simple wrapper around the C stdlib clock() function.
As the clock() man page says:
« Note that the time can wrap around. On a 32-bit system where
CLOCKS_PER_SEC equals 100 this function will return the same value
Antoine Pitrou pit...@free.fr added the comment:
It is very likely you have a 32-bit Python build because:
2**32/100.
4294.967295998
and 4294 is exactly the number of seconds by which your clock() value
wraps around.
--
___
Python tracker
sol simon.hen...@wiktory.org added the comment:
I totally agree.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3585
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
The following patch should do the trick.
--
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file14016/issue1983.patch
___
Python tracker rep...@bugs.python.org
Changes by Antoine Pitrou pit...@free.fr:
--
resolution: fixed -
stage: - patch review
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1983
Thomas Reiter thom...@nikhef.nl added the comment:
That version of Python is linked against 32-bit libc. Point of overflow
corresponds to
2^31 us.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6061
Antoine Pitrou pit...@free.fr added the comment:
Patch looks good here.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3585
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +lemburg, loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6058
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1602
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +pitrou
stage: - patch review
type: - behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
Antoine Pitrou pit...@free.fr added the comment:
I can't say anything about the simplification since I never use tracing,
but +1 at least on the doc cleanup.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6042
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
an immediate thing to do is to declare cp65001 as an encoding:
Index: Lib/encodings/aliases.py
===
--- Lib/encodings/aliases.py(revision 72757)
+++
Jesse Noller jnol...@gmail.com added the comment:
Well; I'm pretty tapped out right now - I think your idea of checking to
see if a timeout has been set elsewhere makes sense. If you have the time
to put together a patch (with a unit test or three :)) I can review it.
Might take me a bit of
Changes by Tristam MacDonald swiftco...@gmail.com:
--
nosy: +swiftcoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1761028
___
___
Tristam MacDonald swiftco...@gmail.com added the comment:
Is there any sign of a patch or workaround for this issue?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1761028
___
Antoine Pitrou pit...@free.fr added the comment:
@AP: ran patched test on Freebsd (6.2) as requested.
Thanks! For the record, did the rest of test_fcntl pass?
Is it a 32-bit or a 64-bit build?
--
___
Python tracker rep...@bugs.python.org
R. David Murray rdmur...@bitdance.com added the comment:
On Tue, 19 May 2009 at 16:24, Antoine Pitrou wrote:
Thanks! For the record, did the rest of test_fcntl pass?
Is it a 32-bit or a 64-bit build?
Yes and 32 bit.
--
___
Python tracker
R. David Murray rdmur...@bitdance.com added the comment:
PYTHONHOME is defined as 'prefix:exec-prefix'. Given that definition
the library must be resolved relatively by appending 'lib/pythonX.Y'.
Given the long standing nature of this interface, I doubt the meaning
can be changed.
It might be
R. David Murray rdmur...@bitdance.com added the comment:
It's not just on the buildbots, it passes fine on my Gentoo box. So the
question really is, what's different about your box that makes it fail?
Can you figure out what bit of code is not finding that library?
How do you run the tests?
New submission from Ronald Oussoren ronaldousso...@mac.com:
The package Lib/pydoc_data is not installed by Makefile.pre.in. Because
of this pydoc if won't work.
The attached patch fixes this issue. I've applied this patch to the
trunk (r72787) and py3k (r72788), and filed this issue because
Ronald Oussoren ronaldousso...@mac.com added the comment:
Closing as won't fix because you can use make altinstall.
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4554
New submission from Miki Tebeka miki.teb...@gmail.com:
It would be nice if threading.Thread constructor will have a daemon
argument as well.
This way we'll be able to write
Thread(target=some_function, daemon=1).start()
Instead of currently writing
t = Thread(target=some_function)
Ronald Oussoren ronaldousso...@mac.com added the comment:
Closing this issue because it was fixed a while back. The bsddb test
failure I rever to in my previous message turned out to be a non-issue:
these tests just take a very long time to finish.
--
status: open - closed
Ronald Oussoren ronaldousso...@mac.com added the comment:
make fullinstall is wrong, this will install a python executable as
well as the proper python3 and python3.1 executables.
I'll do a build of the 3.1 installer ASAP and fix any issues with that.
--
nosy: +ronaldoussoren
Ronald Oussoren ronaldousso...@mac.com added the comment:
The mac issue mentioned by karlcow is not relevant for this discussion
and refers to the system install of Python.
The python.org maintainers cannot influence the behaviour of that
installation, especially not w.r.t. the installation
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've recently fixed this for 3.1, and fixed this for 2.x a while back.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5769
Ronald Oussoren ronaldousso...@mac.com added the comment:
This might be useful for profiling. Debugging information is already
present in the default build of the framework.
A seperate binary for --with-pydebug won't be possible as AFAIK --with-
pydebug changes the ABI and hence having both in
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
+1
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6064
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6064
___
___
Ronald Oussoren ronaldousso...@mac.com added the comment:
Skip could you please answer the questions in msg83149?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4834
___
Ronald Oussoren ronaldousso...@mac.com added the comment:
Argh... The patch includes an update to configure.in, please ignore that
bit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6003
Index: bdist_msi.py
===
--- bdist_msi.py(revision 72507)
+++ bdist_msi.py(working copy)
@@ -141,6 +141,8 @@
bdist_base = self.get_finalized_command('bdist').bdist_base
self.bdist_dir =
Georg Brandl ge...@python.org added the comment:
It was my mistake -- anydbm is called dbm in py3k.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5942
___
Georg Brandl ge...@python.org added the comment:
Thanks for fixing! There's no need to backport; the pydoc_data package
is new in 2.7/3.1.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
George Sakkis george.sak...@gmail.com added the comment:
I don't remember the exact use case but it had to do with making a
decorator robust enough to work for different kinds of callables (and a
few common non-callables such as classmethod/staticmethod). It's not a
show stopper by any means but
Changes by Daniel Diniz aja...@gmail.com:
--
assignee: - tarek
components: +Distutils
nosy: +tarek
stage: - needs patch
type: - behavior
versions: +Python 3.1 -Python 2.5, Python 2.7, Python 3.0
___
Python tracker rep...@bugs.python.org
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I am all for exposing the __func__ directly but don't immediately see
how to do it.
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2690
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Looking back at the original thread, good reasons were expresses for not
documenting this code but just leaving it in as an example.
--
dependencies: -Regexp 2.7 (modifications to current re 2.2.2)
resolution: -
New submission from Collin Winter coll...@gmail.com:
Lib/pickletools.py incorrectly thinks POP_MARK was part of protocol 0;
POP_MARK was only added with the introduction of protocol 1 in r7753.
This mistake led me down a dead end while fixing another pickling issue.
Alexandre, can you
Alexandre Vassalotti alexan...@peadrop.com added the comment:
SHORT_BINBYTES needs to be corrected as well; pickletools lists it as
part of protocol 0 instead of protocol 3.
I doubt backporting this patch to 2.6 will cause any trouble. So, you
can go forward with this.
--
43 matches
Mail list logo
