Stefan Krah stefan-use...@bytereef.org added the comment:
However, the new binary is still not able to start a new thread from the
thread module.
Traceback?
mach/cthreads.h is only relevant for Hurd, as far as I can see.
configure:8572: cc +DD64 -I/home/r32813/local/include -o
Wong Wah Meng r32...@freescale.com added the comment:
Traceback?
$ python
Python 2.7.1 (r271:86832, Sep 28 2011, 17:31:02) [C] on hp-ux11
Type help, copyright, credits or license for more information.
import thread
def testing():
...print Hello World
...
thread.start_new_thread(testing,
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
stage: - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11457
___
___
New submission from Thomas Jarosch thomas.jaro...@intra2net.com:
Hi,
attached patch fixes a file descriptor leak on error.
Best regards,
Thomas Jarosch
--
components: Extension Modules
files: cpython-fix-file-descriptor-leak.patch
keywords: patch
messages: 144588
nosy: thomas.jarosch
New submission from STINNER Victor victor.stin...@haypocalc.com:
[ 62/359] test_multiprocessing
Warning -- threading._dangling was modified by test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by
test_multiprocessing
test test_multiprocessing crashed -- Traceback
New submission from Arne Babenhauserheide arne_...@web.de:
Hi,
I just stumbled over round() errors. I read the FAQ¹, and even though the FAQ
states that this is no bug, its implementation is less than ideal.
To illustrate:
round(0.5, 1)
0.0
and
round(5, -1)
0
This is mathematically
R. David Murray rdmur...@bitdance.com added the comment:
Note that a C accelerator for Decimal is in the works.
--
nosy: +mark.dickinson, r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13060
Arne Babenhauserheide arne_...@web.de added the comment:
Better comparision of decimal and float:
timeit(a+a, setup=from decimal import Decimal, getcontext;
getcontext().prec=17; a = Decimal(1.0))
21.125790119171143
timeit(a+a, setup=a = float(1.0))
0.05324697494506836
--
Arne Babenhauserheide arne_...@web.de added the comment:
If the C accelerator for decimal gets decimal performance close to floats
(which I doubt, because it has to do much more), it could be very useful for
me. What is its estimated time to completion?
Even when it is finished, it does not
R. David Murray rdmur...@bitdance.com added the comment:
It seems to me that saying floating point and mathematically correct in the
same breath is...optimistic :) But that's why I added Mark to nosy, he knows
far more about this stuff than I do.
As far as I know the accelerator is feature
Mark Dickinson dicki...@gmail.com added the comment:
This is mathematically wrong ...
No, it's not 'mathematically wrong'. There are many different rounding
conventions in use, and no single universally agreed convention for rounding
halfway cases. Python chooses to use unbiased
Changes by Mark Dickinson dicki...@gmail.com:
--
type: - feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13060
___
Mark Dickinson dicki...@gmail.com added the comment:
Classifying this as a feature request: the behaviour of round isn't going to
change here, but there might be community support for adding a mechanism for
round to allow other rounding modes. It might be worth taking this to the
Arne Babenhauserheide arne_...@web.de added the comment:
I did not know about rounding to even, so maybe there should be a warning in
the 2.7 documentation, that the behavior changed in python 3 (I just checked
that: python2.7 is in line with the documentation).
The first time I stumbled
Mark Dickinson dicki...@gmail.com added the comment:
maybe there should be a warning in the 2.7 documentation
Well, such a warning really belongs in the Python 3 documentation rather than
the Python 2 documentation. (Or at least, AFAIK that's the convention that's
been followed to date:
Stefan Krah stefan-use...@bytereef.org added the comment:
If the C accelerator for decimal gets decimal performance close to
floats (which I doubt, because it has to do much more), it could be
very useful for me. What is its estimated time to completion?
It is finished and awaiting review
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
title: Expose nanosecond precision from system calls - os.stat(): add new
fields to get timestamps as Decimal objects with nanosecond resolution
___
Python tracker rep...@bugs.python.org
New submission from Joshua Bleecher Snyder joshar...@gmail.com:
When Python is compiled on OS X with llvm, the decimal module behaves
erratically (simple calculations are wrong, most doctests fail). This was
originally reported here:
New submission from Nick Coghlan ncogh...@gmail.com:
Based on the python-ideas thread about closures, I realised there are two
features the inspect module could offer to greatly simplify some aspects of
testing closure and generator behaviour:
inspect.getclosure(func)
Returns a
Stefan Krah stefan-use...@bytereef.org added the comment:
BTW, what is the status of cdecimal?
I just wrote the same in another issue, but not everyone is subscribed
to that:
I think cdecimal is finished and production ready. The version in
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset dec00ae64ca8 by Charles-François Natali in branch '2.7':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/dec00ae64ca8
New changeset 160b52c9e8b3 by
Charles-François Natali neolo...@free.fr added the comment:
Patch applied, thanks!
--
nosy: +neologix
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4
___
Python tracker
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13060
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Issue fixed in Python 3.3 by Martin, changesets 40cf7204ca2b and 50f008019213.
--
nosy: +loewis
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
As said on IRC, unicodesize and character_size should be 1 before the test is
something like 'x'*1. Or you can just remove this constant, it's not very
useful to have a constant equal to 1 :-)
--
Changes by Meador Inge mead...@gmail.com:
--
components: +Library (Lib)
stage: - needs patch
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Changes by Yury Selivanov yseliva...@gmail.com:
--
nosy: +Yury.Selivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
See also issue #13059.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13063
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
See also issue #13063.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13059
___
New submission from STINNER Victor victor.stin...@haypocalc.com:
Re-running test 'test_concurrent_futures' in verbose mode
test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ...
5.79s ok
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok
Stefan Krah stefan-use...@bytereef.org added the comment:
Possibly related to http://bugs.python.org/issue11149?
Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.
--
nosy: +skrah
___
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
The PEP 393 has been accepted: strings are now stored as PyUCS1*, PyUCS2* or
PyUCS4*. The Py_UNICODE type still exist but is deprecated, and only used in
the legacy API. Py_UNICODE is now always the wchar_t type, it cannot be
Arne Babenhauserheide arne_...@web.de added the comment:
cdecimal sounds great! when is it scheduled for inclusion?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13060
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7652
___
___
Python-bugs-list
STINNER Victor victor.stin...@haypocalc.com added the comment:
The PEP 393 has been accepted. There is no more narrow or wide build,
Py_UNICODE is now always wchar_t.
We have also a stable ABI which doesn't depend on the internal stucture of
Unicode strings.
In Python 3.2, the name of
Ross Lagerwall rosslagerw...@gmail.com added the comment:
Updated patch based on Eric's comments:
Store _supports_safe_rmdir at the module level.
Move imports up to module level
Skip test on non-threading build
--
Added file: http://bugs.python.org/file23261/i4489_v4.patch
Antoine Pitrou pit...@free.fr added the comment:
I think there's no point in deprecating a function (or data) with a perfectly
valid definition.
As for test_bigmem, better keep character_size hardwired to 1 (if all tests
really use only ASCII chars, which I'm not sure they do).
--
Joshua Bleecher Snyder joshar...@gmail.com added the comment:
Possibly related to http://bugs.python.org/issue11149?
Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.
Apologies -- I didn't do enough homework on this one. Yes, I can
Daniel Stutzbach stutzb...@google.com added the comment:
Gladly. :-)
--
resolution: - out of date
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8654
Stefan Krah stefan-use...@bytereef.org added the comment:
To me this looks like stdio.h should be included as well. Could
you try the patch?
--
keywords: +patch
Added file: http://bugs.python.org/file23262/issue-13057.diff
___
Python tracker
STINNER Victor victor.stin...@haypocalc.com added the comment:
The PEP 393 changed the API:
#define _PyUnicode_AsString PyUnicode_AsUTF8
#define _PyUnicode_AsStringAndSize PyUnicode_AsUTF8AndSize
--
___
Python tracker rep...@bugs.python.org
Changes by Ned Deily n...@acm.org:
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13061
___
___
Python-bugs-list mailing list
STINNER Victor victor.stin...@haypocalc.com added the comment:
The PEP 393 is based on the idea proposed in this issue (use only one memory
block, not two), but also enhanced it to reduce more the memory using other
technics:
- use a different character type depending on the maximum
STINNER Victor victor.stin...@haypocalc.com added the comment:
Hum, the issue is still open, I will try to review it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7330
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
title: Unicode Fallback Encoding on Python 3.3 - TextIOWrapper: Unicode
Fallback Encoding on Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11574
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
title: Windows GPF with Code Page 65001 - Python 3 doesn't support cp65001 as
the OEM code page
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12632
Roumen Petrov bugtr...@roumenpetrov.info added the comment:
What is result is i use GNU compiler by example with name
arm-linux-androideabi-gcc ?
--
nosy: +rpetrov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12242
Changes by Eli Collins e...@assurancetechnologies.com:
Added file: http://bugs.python.org/file23263/ca53ff77ce6f.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12242
___
Eli Collins e...@assurancetechnologies.com added the comment:
Attached is a fourth revision (ca53ff77ce6f.diff). This covers the typos
identified in the last review, but I'm submitting a new patch because I ran a
quick proofreading regexp, and identified a few more formatting mistakes.
STINNER Victor victor.stin...@haypocalc.com added the comment:
The PEP 393 has been accepted and merge into Python 3.3. Python 3.3 doesn't
need the Py_UNICODE_NEXT macro anymore. But my macros (unicode_macros.patch)
are still useful.
--
versions: +Python 3.2 -Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment:
This issue has been fixed in Python 3.3 thanks to the PEP 393.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10521
Ezio Melotti ezio.melo...@gmail.com added the comment:
It can still be fixed on 2.7/3.2 though.
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10521
___
Ezio Melotti ezio.melo...@gmail.com added the comment:
Py_UNICODE_NEXT has been removed from 3.3 but it's still available and used in
2.7/3.2 (even if it's private). In order to fix #10521 on 2.7/3.2 the
_Py_UNICODE_PUT_NEXT macro attached to this patch is required.
--
versions:
STINNER Victor victor.stin...@haypocalc.com added the comment:
PEP 393 has been accepted and merged into Python 3.3.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12819
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
stage: patch review - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12819
___
Eli Collins e...@assurancetechnologies.com added the comment:
What is result is i use GNU compiler by example with name
arm-linux-androideabi-gcc ?
If the executable is named arm-linux-androideabi-gcc, the code would
currently call arm-linux-androideabi-gcc --version. If that resulted in
Meador Inge mead...@gmail.com added the comment:
I'll take a shot and writing a patch for this one. Nick, are the
elements in 'co_freevars' and '__closures__' always expected to match
up? In other words, is the 'closure' function below always expected to
work (simplified; no error checking):
Stefan Krah stefan-use...@bytereef.org added the comment:
It's more a straight duplicate of #12973, but the underlying cause
(signed integer overflow) is the same. For people who are finding
this via a search engine: A lot of bugs have been fixed in #12973,
but even if the test suite passes
Eric Snow ericsnowcurren...@gmail.com added the comment:
See:
http://hg.python.org/cpython/file/default/Include/funcobject.h#l34
http://hg.python.org/cpython/file/default/Objects/funcobject.c#l454
454 /* func_new() maintains the following invariants for closures. The
455closure must
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13061
___
___
New submission from STINNER Victor victor.stin...@haypocalc.com:
We really need a new API for error handlers, using Python objects instead of
Py_UNICODE* strings, and using code point indexes instead of UTF-16 unit
indexes (index in the Py_UNICODE* object). It's also inefficient to encode to
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
stage: - needs patch
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13064
___
Nick Coghlan ncogh...@gmail.com added the comment:
Yep, that looks right to me. The eval loop then references those cells from the
frame object during execution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Nick Coghlan ncogh...@gmail.com added the comment:
Huh, I didn't actually realise getclosure() could be written as a one liner
until seeing Meador's version above:
{var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars,
func.__closure__)}
--
Victor Semionov vsemio...@gmail.com added the comment:
Testing.
--
nosy: +vsemionov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
___
Victor Semionov vsemio...@gmail.com added the comment:
testing
--
Added file: http://bugs.python.org/file23266/test.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
Victor Semionov vsemio...@gmail.com added the comment:
adsfaf
--
hgrepos: +78
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
___
Changes by Victor Semionov vsemio...@gmail.com:
--
hgrepos: -78
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
___
Python-bugs-list
Ezio Melotti ezio.melo...@gmail.com added the comment:
RFC 4627 doesn't say much about lone surrogates:
A string is a sequence of zero or more Unicode characters [UNICODE].
[...]
All Unicode characters may be placed within the
quotation marks except for the characters that must be
New submission from Victor Semionov vsemio...@gmail.com:
ignore me
--
messages: 144647
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13065
Changes by Victor Semionov vsemio...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13065
___
___
New submission from Victor Semionov vsemio...@gmail.com:
ignore me
--
components: IO, Interpreter Core
messages: 144648
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2
___
Python tracker
Changes by Victor Semionov vsemio...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13066
___
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13065
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13066
___
New submission from Victor Semionov vsemio...@gmail.com:
ignore me
--
components: IO, Interpreter Core
files: backtrace
messages: 144651
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2
Added file:
Changes by Victor Semionov vsemio...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13067
___
___
Ned Deily n...@acm.org added the comment:
There is some confusion here, I think. As best as I can tell, the original
problem reported in the Stackoverflow question and to MacPorts involved using
the clang compiler, not llvm-gcc and the Decimal problem reported here was only
ever a problem
New submission from Victor Semionov vsemio...@gmail.com:
ignore me
--
messages: 144654
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13068
Changes by Victor Semionov vsemio...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13068
___
___
New submission from Ezio Melotti ezio.melo...@gmail.com:
Testing issue creation
--
hgrepos: 83
messages: 144655
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: test
___
Python tracker rep...@bugs.python.org
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13069
___
New submission from Victor Semionov vsemio...@gmail.com:
Hello,
I'm developing a multi-threaded TCP server and have been seeing segmentation
faults on 3.2 on Linux and 3.2.2 on Windows. This happens when using only
pure-Python libraries, so I believe the problem is in the interpreter. The
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13068
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13067
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3232
___
___
Python-bugs-list
New submission from STINNER Victor victor.stin...@haypocalc.com:
In Python 3.2, when you get a buffer from array.array('u'), u is used as
buffer format. The format is supposed to be a format from the struct module,
and u is an invalid struct format. w is used on wide mode.
I just upgraded the
New submission from jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal
christopherdar...@gmail.com:
I have tried all ways of opening IDLE and have uninstalled and reinstalled
Python, but when I try to open it it crashes before anything happens
--
components: IDLE
messages: 144657
nosy:
Ezio Melotti ezio.melo...@gmail.com added the comment:
Try to open cmd (win+r - type 'cmd' - press enter), cd in the Python
directory and do python.exe Lib\idlelib\idle.py.
If that doesn't work it should give you a traceback. Once you get the
traceback copy/paste it here, so we can figure out
Wong Wah Meng r32...@freescale.com added the comment:
Hello Stefan,
Hmm. how do I apply the patch? I download the issue-13057.diff file and
then.?
Regards,
Wah Meng
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti ezio.melo...@gmail.com added the comment:
After PEP 393 the result is still the same (I attached a slightly improved
version of the script):
titlecase of 'deme un cafe' should be 'Deme Un Cafe' not 'DeMe Un Cafe'
titlecase of 'istanbul' should be 'Istanbul' not
Ezio Melotti ezio.melo...@gmail.com added the comment:
patch -p1 issue-13057.diff in the directory where configure is should do
the trick.
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13057
Ezio Melotti ezio.melo...@gmail.com added the comment:
The failing re tests after PEP 393 are:
FAIL lib re found non alphanumeric string 'cafe'
FAIL lib re found non alphanumeric string 'Ⓚ'
FAIL lib re found non alphanumeric string ''
FAIL lib re found non alphanumeric string ''
FAIL lib re
Wong Wah Meng r32...@freescale.com added the comment:
I tried here is the outcome. It says it can't find a patch??
$ cat issue-13057.diff
diff -r f612b783bc17 configure
--- a/configure Thu Sep 29 07:52:46 2011 +0800
+++ b/configure Thu Sep 29 21:39:32 2011 +0200
@@ -8619,6 +8619,7 @@
Ezio Melotti ezio.melo...@gmail.com added the comment:
If that's a Mercurial clone of Python you can try hg import --no-commit
issue-13057.diff. Otherwise you could just edit configure manually -- the
attached patch is trivial. You could also install patch.
--
Wong Wah Meng r32...@freescale.com added the comment:
Mercurial clone of python? Haha I am not sure what that is. My unix also won't
recognize hg, and will ignore import --no-commit issue-13057.diff.
I went ahead to edit configure file. Partially understanding the content of
.diff file, I
Wong Wah Meng r32...@freescale.com added the comment:
Hello,
I tried rebuild but it is still the same. :( Attached is the extract of the
modified configure file, with line number at the side (from VI editor).
Basically my changes are added as from line 8620 through 8624. I am not sure if
Ezio Melotti ezio.melo...@gmail.com added the comment:
You just have to add:
#include stdio.h
just after:
#include pthread.h
The + in the diff only means that the line was added and shouldn't be included
in the file.
--
___
Python tracker
1 - 100 of 103 matches
Mail list logo
