New submission from Stefan Krah stefan-use...@bytereef.org:
On Windows, test_compileall fails due to #10197:
==
FAIL: test_quiet (test.test_compileall.CommandLineTests
Stefan Krah stefan-use...@bytereef.org added the comment:
On Windows, test_compileall fails due to #10197. The patch uses
subprocess.check_output() instead. Technically, now byte strings
are compared instead of strings, but that should not matter for
the outcome.
--
nosy: +skrah
Added
Stefan Krah stefan-use...@bytereef.org added the comment:
Since I was the one who reopened this: The issues I found were fixed in
r85358 and #9047 seems to be ok now. Setting to pending.
--
resolution: - fixed
stage: - committed/rejected
status: open - pending
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: skrah
priority: normal
severity: normal
status: open
title: Build with --enable-shared fails
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10520
New submission from Stefan Krah stefan-use...@bytereef.org:
Building the modules fails if --enable-shared is used. The linker picks
up an existing library from /usr/local/lib, which has not been compiled
with -fPIC:
gcc -pthread -shared
build/temp.linux-x86_64-3.2/home/stefan/svn/py3k/Modules
Stefan Krah stefan-use...@bytereef.org added the comment:
Since I'm on Linux, I did a prior install into /usr/local. But I'm pretty
sure that BSD ports (which you might view as the system install) also use
/usr/local.
--
___
Python tracker rep
Stefan Krah stefan-use...@bytereef.org added the comment:
Yes, the patch is tested on Windows. Feel free to commit it if you have
a chance.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10453
Stefan Krah stefan-use...@bytereef.org added the comment:
Fixed original leaks in r86804, r86806 and r86804.
Fixed additional leaks in r86829.
--
components: +Extension Modules -Library (Lib), Windows
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions
New submission from Stefan Krah stefan-use...@bytereef.org:
On FreeBSD, the config variable LDSHARED contains the literal '${LDFLAGS}',
causing this failure in test_distutils:
'test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... gcc: ':
No such file or directory
ERROR
Changes by Stefan Krah stefan-use...@bytereef.org:
--
keywords: +buildbot -needs review, patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10547
New submission from Stefan Krah stefan-use...@bytereef.org:
C:\Users\stefan\svn\py3k_64PCbuild\amd64\python_d.exe Lib\test\regrtest.py -R
: test_concurrent_futures
[1/1] test_concurrent_futures
beginning 9 repetitions
123456789
.
test_concurrent_futures leaked [6912, 6912, 6912, 6912
Stefan Krah stefan-use...@bytereef.org added the comment:
posixmodule_listdir.patch fixes a leak in test_macpath. test_concurrent_futures
still leaks.
--
keywords: +patch
Added file: http://bugs.python.org/file19839/posixmodule_listdir.patch
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +bquinlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10550
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed posixmodule_listdir.patch in r86843. Unfortunately this
is unrelated to the test_concurrent_futures leak.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Anurag, could you check out #941346 and see if there is anything that
might help? I think this is AIX specific.
--
nosy: +sable
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Upgrading to critical, since I just verified that C extensions in
general don't build on FreeBSD due to this issue.
Sorry for bringing this up on the release day, it's a coincidence that
I discovered it today...
--
priority
Stefan Krah stefan-use...@bytereef.org added the comment:
Checked python-3.1.2.msi with f-prot, no viruses. Checked download
with firefox (which claims to do a short virus scan), no results.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Thinking about it, declaring PyMODINIT_FUNC as void would be a huge
step backwards. Using PyMODINIT_FUNC is the correct way of doing things.
The current situation punishes developers who actually read the docs.
If a C module stops
Stefan Krah stefan-use...@bytereef.org added the comment:
Right, Debian's solution is quite reasonable. Closing as wont_fix.
--
resolution: - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Stefan Krah stefan-use...@bytereef.org added the comment:
r86848: backported r85422, as required by the changes in r85358.
Antoine, there are some remaining {LDFLAGS}, two in the Darwin sections,
one in the OpenBSD section.
I think all of those should be removed as well. Do you agree
Stefan Krah stefan-use...@bytereef.org added the comment:
PyUnicode_EncodeDecimal() is either unnecessary or should be exposed
as a codec.
I'm depending on PyUnicode_EncodeDecimal in cdecimal. In fact, it saved
me quite a bit of trouble. I wouldn't be surprised if other extension
writers use
Stefan Krah stefan-use...@bytereef.org added the comment:
[Antoine]
I didn't want to mess with these things too much. I guess you can try
and we'll see.
You're right, it's better not to touch the Darwin stuff.
The 2.7 buildbots are green (including the FreeBSD ones!). I also
tested
Stefan Krah stefan-use...@bytereef.org added the comment:
(Anyone knows whether Arabic numbers are written right to left or left
to right? What is the proper decimal point character?)
Thousands separator: U+066C
Decimal point: U+066B
١٢٣٬١٢٣٫١٢ should be: 123,123.12
Wikipedia says
Stefan Krah stefan-use...@bytereef.org added the comment:
UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
Hmm, looks like a bug? I think U+066B is correct.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Alexander Belopolsky rep...@bugs.python.org wrote:
On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
..
* Please change the API _PyUnicode_NormalizeDecimal() to
PyUnicode_ConvertToASCIIDecimal
New submission from Stefan Krah stefan-use...@bytereef.org:
I'm not sure if this is a documentation issue or a bug. If watchexp=0,
quantize() also allows any number of digits:
x = Decimal(6885998238912213556789006667970467609814)
y = Decimal(1e2)
x.quantize(y)
Traceback (most recent call
Stefan Krah stefan-use...@bytereef.org added the comment:
NaNs, however, are decapitated:
x = Decimal(NaN5357671565858315212612021522416387828577)
y = 0
x.quantize(y, watchexp=0)
Decimal('NaN8315212612021522416387828577')
--
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
Before anyone does any further testing:
Tarek, can this go into distutils 2.7/3.2 (after 3.2 has been released)?
Due to the popularity of this issue I think it might be worthwhile to
make an exception and ignore the distutils freeze
Stefan Krah stefan-use...@bytereef.org added the comment:
[Alexander]
if sys.getenv('PYTHONSEGVHANDLER'):
import segvhandler
segvhandler.enable()
+1
If this doesn't find support, I'd name sys.setsegfaultenabled()
sys.setsegvhandlerenabled() or sys.enable_segvhandler
Stefan Krah stefan-use...@bytereef.org added the comment:
STINNER Victor rep...@bugs.python.org wrote:
Note: To avoid the signal-safe requirement, another solution is to use
sigsetjmp()+siglongjmp().
FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():
http
New submission from Stefan Krah stefan-use...@bytereef.org:
When CFLAGS are set, distutils drops -fno-strict-aliasing (among other
flags):
$ python2.7 setup.py build
...
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -I./src -I/usr/local
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9880
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
I narrowed this issue down to -ftree-vectorize, which is part of
-O3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9880
Stefan Krah stefan-use...@bytereef.org added the comment:
If OrderedDict is used, the test case quickly uses 8GB of memory. With
this change (I'm not suggesting this as a fix!), the timings are normal:
Index: Lib/ConfigParser.py
Stefan Krah stefan-use...@bytereef.org added the comment:
This seems to be a duplicate of #7424.
--
nosy: +skrah
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - segmentation fault in listextend during install
Stefan Krah stefan-use...@bytereef.org added the comment:
See also:
http://gnats.netbsd.org/42627
--
nosy: +H.Xu, haypo, loewis, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7424
New submission from Stefan Krah stefan-use...@bytereef.org:
Hi,
to_integral() should behave like quantize() for negative exponents:
Otherwise (the operand has a negative exponent) the result is the
same as using the quantize operation using the given operand as the
left-hand-operand, 1E+0
New submission from Stefan Krah stefan-use...@bytereef.org:
Another exciting corner case in plus/minus:
The operations are evaluated using the same rules as add and subtract;
the operations plus(a) and minus(a) (where a and b refer to any numbers)
are calculated as the operations add(’0
Stefan Krah stefan-use...@bytereef.org added the comment:
Éric, the Debian patch looks good to me and it solves my build problem.
The only question I have is why EXTRA_CFLAGS still go behind CFLAGS
and cannot be overridden via the environment.
But as it is, the patch is an improvement. I'm
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Why is OPT duplicated in get_config_vars(...)?
I missed that, thanks.
Why do OPT and BASECFLAGS environ vars override their Makefile values
instead of accumulating with them?
I think
Stefan Krah stefan-use...@bytereef.org added the comment:
EXTRA_CFLAGS were removed in r38848. Is it necessary to configure
OPT, BASECFLAGS and EXTRA_CFLAGS via the environment? I think it
might be sufficient to take CFLAGS from the Makefile and append
the environment CFLAGS.
Chris, would
Stefan Krah stefan-use...@bytereef.org added the comment:
For the record, I prefer Python's behavior. The quantize() definition
does not work well for arbitrary precision input and leads to situations
like:
Precision: 1
Maxexponent: 1
Minexponent: -1
tointegral 101 - 101
tointegral 101.0
Stefan Krah stefan-use...@bytereef.org added the comment:
The patch and the test cases look good, but the implicit context must
be looked up earlier now (see the altered patch).
I just realize that there aren't any regression tests for this sort
of situation, since for the main tests we
Stefan Krah stefan-use...@bytereef.org added the comment:
Chris Lambacher rep...@bugs.python.org wrote:
I was cross-compiling to a target architecture that does not support
the -march option so I would not be able to provide a different one
as override.
Just out of curiosity: You are cross
New submission from Stefan Krah stefan-use...@bytereef.org:
Due to an integer overflow in unicode_hash, the python interpreter
crashes if built with -ftrapv:
./configure --with-pydebug CFLAGS=-ftrapv
Starting program: /home/stefan/svn/py3k/python
[Thread debugging using libthread_db enabled
Stefan Krah stefan-use...@bytereef.org added the comment:
Ok, this is known, see #1621. Closing.
--
resolution: - duplicate
status: open - closed
superseder: - Do not assume signed integer overflow behavior
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1621
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
Marc-Andre Lemburg rep...@bugs.python.org wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Could you try the same in Python 2.7 ?
It's the same, just in stringobject.c. Many hash functions have this issue
Stefan Krah stefan-use...@bytereef.org added the comment:
Works fine for me (Windows 7, 64-bit, 32-bit Python-3.2). I do have the
plain US English version. Do you have localized versions?
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http
Stefan Krah stefan-use...@bytereef.org added the comment:
Python works fine with Notepad generated scripts. I think this is a
CGI issue. Try following this tutorial:
http://www.imladris.com/Scripts/PythonForWindows.html
If you still suspect a bug, you should provide the exact CGI script
Changes by Stefan Krah stefan-use...@bytereef.org:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1481
___
___
Python
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6419
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
Victor, I think one more skip is required in test_socketserver.
--
nosy: +skrah
resolution: fixed -
status: closed - open
Added file:
http://bugs.python.org/file17317/nothreads-socketserver-shutdown.patch
Stefan Krah stefan-use...@bytereef.org added the comment:
The same patch was applied to the Python port by OpenBSD developer Damien
Miller:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_kqueue_py
Mark, would it be ok in this situation to apply
Stefan Krah stefan-use...@bytereef.org added the comment:
Luckily, the OpenBSD failures are caused by issues in libpthread. This
means that some skips could be added (as for FreeBSD), but I'll open
a separate issue for that.
Thanks for the comments on the patch. I add two new patches
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file17335/issue8424-trunk-skiptest.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8424
New submission from Stefan Krah stefan-use...@bytereef.org:
When the system python does not have the Lib/test directory, the
compat tests are failing.
==
ERROR: test_attribute_name_interning
Stefan Krah stefan-use...@bytereef.org added the comment:
The EINTR issue should be fixed in trunk (issue1628205). Have you by
any chance run the test suite on trunk in the meantime?
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http
Stefan Krah stefan-use...@bytereef.org added the comment:
The compat tests check that pickling in the newly compiled Python
version is compatible with pickling in installed Python versions.
The installed versions may or may not have a test directory. For
example, the 2.6 port in OpenBSD does
New submission from Stefan Krah stefan-use...@bytereef.org:
[Added OpenBSD Python port maintainers to the nosy list.]
I've identified a number of tests that all pass when Python is compiled
without threads, but fail otherwise. The failures are probably caused
by libpthread issues in OpenBSD
New submission from Stefan Krah stefan-use...@bytereef.org:
On OpenBSD, SIGINT handling in the REPL is delayed until further input:
Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52)
[GCC 3.3.5 (propolice)] on openbsd4
Type help, copyright, credits or license for more information.
= here
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, thanks. - The patch is good on OpenBSD-4.5-i386-Celeron,
but I get additional failures on OpenBSD-4.7-beta-amd64-QEMU.
This could be the result of running a beta under qemu.
Henry, could you confirm if the patch works on amd64
Stefan Krah stefan-use...@bytereef.org added the comment:
I can't pinpoint the exact causes for each individual test failure. I assumed
that they are caused by threading/signal issues, because the tests pass when
Python is compiled --without-threads.
But here's a list of possible culprits
Stefan Krah stefan-use...@bytereef.org added the comment:
The FreeBSD-6.4-RELEASE-i386 buildbot has similar libpthread issues.
This is just in:
==
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase
Stefan Krah stefan-use...@bytereef.org added the comment:
The gentoo-3.x buildbot also shows the threading problems again:
test test_subprocess failed -- Traceback (most recent call last):
File
/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/test_subprocess.py,
line 770
Stefan Krah stefan-use...@bytereef.org added the comment:
I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
in sync, it would be nice to agree how they should be created.
Suggestions:
1) c = Decimal64Context
2) c = Context(Decimal64)
3) ?
I have a preference for 2
Stefan Krah stefan-use...@bytereef.org added the comment:
Some context from issue 8540:
[Stefan Krah]
I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
in sync, it would be nice to agree how they should be created.
Suggestions:
1) c = Decimal64Context
2) c
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
It's Table 3.6 (Decimal interchange format parameters) in the final version
of IEEE 754;
Thanks! I think this is not in the draft I have.
+1 for IEEEContext(n). Could we have module
Stefan Krah stefan-use...@bytereef.org added the comment:
The patch looks good, +1 for applying it. I'm not a native speaker, but
probably:
are subject to clamping this manner = are subject to clamping in this
manner
--
___
Python tracker rep
Stefan Krah stefan-use...@bytereef.org added the comment:
I agree with all points. Could you fix it directly if at all possible?
Of course eventually I'd do it, it might take some time until I get
around to it though.
--
___
Python tracker rep
Stefan Krah stefan-use...@bytereef.org added the comment:
On 2.6, the tests aren't skipped if test_support.verbose is 0.
David, if the fix looks good to you I can apply it.
test_itimer_virtual: timeout: likely cause: machine too slow or load too high.
test test_signal failed -- Traceback
Stefan Krah stefan-use...@bytereef.org added the comment:
I think it would be nice to get this into 2.7. I don't expect buildbot
failures, since the 2.7 patch is essentially the same as the py3k version,
which has been tested extensively.
--
Added file: http://bugs.python.org/file17528
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, thanks. Committed in r81669; I'll keep an eye on the buildbots.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7384
Stefan Krah stefan-use...@bytereef.org added the comment:
Thanks for looking at the patch! Committed in r81676.
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3864
Stefan Krah stefan-use...@bytereef.org added the comment:
I can't find buildbot failures related to this any longer, so I'm closing
this one.
--
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
New submission from Stefan Krah stefan-use...@bytereef.org:
test_capi fails when compiled --without-threads:
test test_capi failed -- Traceback (most recent call last):
File
/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py, line
49, in test_no_FatalError_infinite_loop
Stefan Krah stefan-use...@bytereef.org added the comment:
I ran a test --without-threads: test_runpy and test_exceptions passed,
test_sys was not reached:
test_sqlite
Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file
/usr/src/lib/libthr/thread/thr_init.c (errno
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k).
What to do with the releases? To recap, the fix is:
1) Detect if readline is already linked against ncurses and
if so, skip any further selection. This must
Changes by Stefan Krah stefan-use...@bytereef.org:
--
keywords: +patch
Added file: http://bugs.python.org/file17594/issue8932.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8932
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed in r81857. Blocked for release31-maint (requires additional fixes).
--
resolution: - accepted
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8947
___
___
Python-bugs-list
Stefan Krah stefan-use...@bytereef.org added the comment:
python version: 2.4.3
I'd suggest to try this with Python 2.6 or later. 2.4 and 2.5 are in
security-fix only mode.
--
nosy: +skrah
versions: -Python 2.5
___
Python tracker rep
Stefan Krah stefan-use...@bytereef.org added the comment:
FreeBSD/Qemu: ipv6 is ok, but this fails:
==
FAIL: testGetaddrinfo (__main__.GeneralModuleTests
Stefan Krah stefan-use...@bytereef.org added the comment:
Btw, socket.has_ipv6 documentation should be more clear about the fact
that having it == True doesn't necessarily mean IPv6 is actually
supported.
Strange indeed. socket.has_ipv6 checks whether ENABLE_IPV6 was defined at
compile time
Stefan Krah stefan-use...@bytereef.org added the comment:
But why is that an attribute of a socket object?
Please pretend I did not write this. ;)
Anyway, getaddrinfo() on FreeBSD/Qemu gives this:
socket.getaddrinfo('localhost', 21)
[(2, 2, 17, '', ('127.0.0.1', 21)), (2, 1, 6
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed a conservative version implementing part 1) in r82017 (2.6) and
r82019 (3.1). Part 2) can be enabled by uncommenting a couple of lines in
setup.py.
The buildbots look good, but I'm setting this to 'pending' in case
someone
Stefan Krah stefan-use...@bytereef.org added the comment:
Py_CHARMASK should return a non-negative integer. As I understand it:
tokenizer.c:tok_get around line 1368:
while (Py_ISALNUM(c) || c == '_') {
c = tok_nextc(tok);
}
1) tok_nextc(tok) returns EOF (correct
Stefan Krah stefan-use...@bytereef.org added the comment:
You can simulate this on Linux by compiling with:
BASECFLAGS=-funsigned-char
Then:
Index: Parser/tokenizer.c
===
--- Parser/tokenizer.c (revision 81682)
+++ Parser
Stefan Krah stefan-use...@bytereef.org added the comment:
Martin v. Löwis rep...@bugs.python.org wrote:
Of course, it is dubious why EOF is not tested separately rather than
passing it to Py_ISALNUM(). Micro-optimization? At least a comment
should be added.
No, I think this is an error
New submission from Stefan Krah stefan-use...@bytereef.org:
This feature request is extracted from issue 9020, where Py_CHARMASK(c)
was used on EOF, producing different results depending on whether
__CHAR_UNSIGNED__ is defined or not.
The preferred fix for issue 9020 is to check for EOF before
Stefan Krah stefan-use...@bytereef.org added the comment:
Reopening since test failures are reported on python-dev:
[...]
test_uuid
test test_uuid failed -- Traceback (most recent call last):
File /private/tmp/Python-2.7rc2/Lib/test/test_uuid.py, line 472, in
testIssue8621
Stefan Krah stefan-use...@bytereef.org added the comment:
It is disputed on http://openradar.appspot.com/radar?id=334401 that
this is an OS bug. If I understand correctly, the test program is
not guaranteed to work if threads are involved. See also:
http://webcache.googleusercontent.com/search
Stefan Krah stefan-use...@bytereef.org added the comment:
Bill, could you try to add this to the tests and see if they
also fail when you run them standalone?
Index: Lib/test/test_uuid.py
===
--- Lib/test/test_uuid.py
Stefan Krah stefan-use...@bytereef.org added the comment:
Ronald Oussoren rep...@bugs.python.org wrote:
Stefan: we already new that, see msg105018.
This issue was closed as fixed because the uuid module contains a workaround
for this issue (by not using the broken C API on OSX 10.6).
Ok
Stefan Krah stefan-use...@bytereef.org added the comment:
Re: EOF checking in Py_ISXXX() for consistency with C functions.
After reflecting on this a bit I think it's ultimately not a good
idea. While it is possible to do the EOF check, the macros would
then take either an int in [EOF, 0
Stefan Krah stefan-use...@bytereef.org added the comment:
Patch for ceval.c. If you agree with the macro indentation (starting
in line 815) I can commit it and port it to the other branches.
--
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file17752/trunk-ceval
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine, thanks. ceval.c fixes committed in r82177, r82179, r82181
and r82182.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8930
New submission from Stefan Krah stefan-use...@bytereef.org:
While investigating issue 9020, I noticed that there are several places
where the pyctype.h macros could/should be used.
--
messages: 108505
nosy: eric.smith, skrah
priority: normal
severity: normal
status: open
title: Use
Stefan Krah stefan-use...@bytereef.org added the comment:
Committed fix in r82191. Thanks Sridhar for tracking this down.
New issues emerging from this one:
1) Simplify Py_CHARMASK: issue 9036
2) Use macros from pyctype.h: issue 9067
Additionally, I noticed that the macros
1 - 100 of 3373 matches
Mail list logo
