[issue2065] trunk version does not compile with vs8 and vc6

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

I don't know why, but
/D "MODULE_NAME=\"sqlite3\""
is troublesome. VC6 IDE expands this to
#define MODULE_NAME " sqlite3".

To workaround this, I used
/D MODULE_NAME=\"sqlite3\"
instead in sqlite3.dsp.

Added file: http://bugs.python.org/file9946/ocean.zip

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2526] str.format() :n format does not appear to work

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

I'm looking into it.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1164742] Tkdnd.py crashes due to read-only attributes

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

This was fixed on rev 39219 (2 years and 8 months ago)
This surely could be closed by now.

--
nosy: +gpolo

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2546] Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The crash is because of an error in your C code:
in backend.c::
void backend(char *output_filename)
{
C2py("backend", 1, output_filename);
}

But your C2py function expects a variable number of PyObject*.

I found this by disabling the garbage collector: then the program
crashes in C2py.c at the instruction "Py_DECREF(pArgs);"

--
priority: release blocker -> normal
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2530] Document IO module

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Great!

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1164742] Tkdnd.py crashes due to read-only attributes

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> fixed
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

*testing stack overflow:* maybe?

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Don't change that line.  It is obviously clear already, if someone does 
read it.  I obviously did not.

/Jean

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2526] str.format() :n format does not appear to work for int and float

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

The same issue exists with floats:
# continuing the example

>>> locale.format("%g", 12345, True)
'12,345'
>>> "{0:n}".format(12345.0)
'12345'

The same issue exists in 2.6.

--
title: str.format() :n format does not appear to work -> str.format() :n format 
does not appear to work for int and float
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.  The 
only thing which can be done is avoid building the _ctypes module if the 
compiler is not gcc.  I did look at fixing that but have not found the 
proper way to do that.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2556] changing sys.dont_write_bytecode has not effect

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

According to the 2.6 docs, says you can set it yourself to control
bytecode generation. That doesn't work because the dont_write_bytecode
flag is set from command option and never looked at again. Either we
should remove this misleading information or use PySys_GetObject in
pythonrun.c where the flag is used.

--
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 64976
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: changing sys.dont_write_bytecode has not effect
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2557] \u and \U in raw strings have reverted

[Guido van Rossum]

New submission from Guido van Rossum <[EMAIL PROTECTED]>:

In 2.x, \u and \U are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a raw string should have no special meaning -- it's just a
backslash followed by 'u' or 'U'.

This was fixed in 3.0a3. It seems to have reverted to the old (2.x)
behavior in 3.0a4.

THIS MUST BE FIXED!

--
messages: 64977
nosy: gvanrossum
priority: release blocker
severity: normal
status: open
title: \u and \U in raw strings have reverted
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2557] \u and \U in raw strings have regressed in 3.0a4

[Guido van Rossum]

Changes by Guido van Rossum <[EMAIL PROTECTED]>:


--
title: \u and \U in raw strings have reverted -> \u and \U in raw strings have 
regressed in 3.0a4

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2557] \u and \U in raw strings have regressed in 3.0a4

[Guido van Rossum]

Changes by Guido van Rossum <[EMAIL PROTECTED]>:


--
components: +Interpreter Core

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Sorry, Guido said this is not allowed:
http://mail.python.org/pipermail/python-3000/2008-April/012952.html. I
reverted it in r62165.

--
resolution: fixed -> rejected

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2557] \u and \U in raw strings have regressed in 3.0a4

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

fixed in r62165.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2349] Py3K warn against assigning to True/False

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Brett, shall I apply?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

The docs still need to be updated!  An entry in what's new in 3.0 should
also be added.

--
assignee:  -> georg.brandl
components: +Documentation -Unicode
nosy: +georg.brandl, gvanrossum
status: closed -> open

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2548] Undetected error in exception handling

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Neal has the memory of an elephant or something.

Yes, I dealt with a similar issue where the recursion limit was hit, but 
then normalizing the exception just caused it to hit it again. I thought 
I changed it such that normalizing an exception actually turned off the 
depth check or to raise a pre-defined exception for the recursion depth 
limit.

I don't have time to look at this right now (still on holiday in 
Brussels), but if I remember correctly the last time this came up I 
liked the pre-allocated recursion limit exception.

--
assignee: brett.cannon -> 

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

How's this?

--
keywords: +patch
Added file: 
http://bugs.python.org/file9947/py3k_raw_strings_unicode_escapes.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Instead of "ignored" (which might be read ambiguously) how about "not
treated specially"?

You also still need to add some words to whatsnew.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

"not treated specially" it is!

Added file: 
http://bugs.python.org/file9948/py3k_raw_strings_unicode_escapes2.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2557] \u and \U in raw strings have regressed in 3.0a4

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

The was not a mistake, it was done on purpose since there would
otherwise have been no way to add non-ASCII Unicode code points to a raw
Unicode literal, rendering raw Unicode literals pretty useless.

Even if you use UTF-8 as source code encoding, there's no way to add
half a surrogate to a raw Unicode literal without the Unicode literals.

If you need to write a Unicode literal escape using the raw Unicode
escape encoding, you can use '\x1234'.

--
nosy: +lemburg

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2556] changing sys.dont_write_bytecode has not effect

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Sorry, I can't see what's wrong here. See import.c which indeed uses
PySys_GetObject to retrieve the value of dont_write_bytecode.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2556] changing sys.dont_write_bytecode has not effect

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2546] Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270

[George Verbitsky]

George Verbitsky <[EMAIL PROTECTED]> added the comment:

Thank you, Amaury, very much for helping me with this one.
George

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: 
Amaury Forgeot d'Arc  added the comment:

The crash is because of an error in your C code:
in backend.c::
void backend(char *output_filename)
{
C2py("backend", 1, output_filename);
}

But your C2py function expects a variable number of PyObject*.

I found this by disabling the garbage collector: then the program
crashes in C2py.c at the instruction "Py_DECREF(pArgs);"

--
priority: release blocker -> normal
resolution:  -> invalid
status: open -> closed

__
Tracker 

__

-
You rock. That's why Blockbuster's offering you one month of Blockbuster Total 
Access, No Cost.

Added file: http://bugs.python.org/file9949/unnamed

__
Tracker <[EMAIL PROTECTED]>

__Thank you, Amaury, very much for helping me with this 
one.GeorgeAmaury Forgeot d'Arc <[EMAIL 
PROTECTED]> wrote: Amaury 
Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:The crash is 
because of an error in your C code:in backend.c::void backend(char 
*output_filename){C2py("backend", 1, output_filename);  
  }But your C2py function expects a variable number of 
PyObject*.I found this by disabling the garbage collector: then the 
programcrashes in C2py.c at the instruction 
"Py_DECREF(pArgs);"--priority: release blocker -> 
normalresolution:  -> invalidstatus: open -> 
closed__Tracker <[EMAIL 
PROTECTED]>__ 

  You rock. That's why Blockbuster's offering you http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com";>one
 month of Blockbuster Total Access, No Cost.___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

The segment "use different rules for interpreting backslash escape
sequences." should be killed entirely, and the whole rule told here.

Also, a few paragraphs later there are more references to raw strings,
e.g. "When an ``'r'`` or ``'R'`` prefix is used in a string literal,"
which need to be fixed too.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thank you, fixed in r62171.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> gvanrossum
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.

So the proper fix for that would be to port it to SunPro, of course.

> The 
> only thing which can be done is avoid building the _ctypes module if the 
> compiler is not gcc.

I'm not sure whether that would be much better than the status quo,
though. People would continue to complain that the ctypes module is not
built.

Why do you consider the current behaviour incorrect?

> I did look at fixing that but have not found the 
> proper way to do that.

There are several ways. One is to skip compilation in setup.py, for
which you should then determine whether the compiler is gcc. For
that, you could look at ac_compiler_gnu in configure.in, and
set a variable in Makefile.pre.in if the compiler is GCC. Then,
in setup.py, you could look for that variable as parsed from
the Makefile, and skip _ctypes accordingly.

Alternatively, you could check for __GNUC__ when compiling
ctypes, and make the compiler produce a better-understandable
#error.

Regards,
Martin

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2558] Document pickle protocol 3

[Georg Brandl]

New submission from Georg Brandl <[EMAIL PROTECTED]>:

A new pickle protocol was added to Py3k; it needs to be mentioned in the
docs.

--
assignee: georg.brandl
components: Documentation
messages: 64993
nosy: georg.brandl
severity: normal
status: open
title: Document pickle protocol 3
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2558] Document pickle protocol 3

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> gvanrossum
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

For ctypes to compile with the SUN's C compiler, there is quite a bit of 
tricky asm code which needs to be ported (and tested).  Most of that is 
in libffi and that library is only supported with gcc, it seems.  But 
that is not mentioned explicitly anywhere either, see 
.

In any case, the _ctypes module does not compile with SUN C in the 
current situation.  And it is not obvious why.  Making that clear with 
some message that ctypes (rather _ctypes) requires gcc would help and 
might be sufficient.

However, leaving the _ctypes module out altogether would be better. Just 
like other modules which have environment-specific dependencies, for 
example _tkinter.  I'll take a look how that is handled.

/Jean

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2558] Document pickle protocol 3

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

There.

--
nosy: +gpolo
Added file: http://bugs.python.org/file9950/pickle_protocol3.rst

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2558] Document pickle protocol 3

[Guilherme Polo]

Changes by Guilherme Polo <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9950/pickle_protocol3.rst

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2558] Document pickle protocol 3

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Sent wrong file before, this is the correct one.

--
keywords: +patch
Added file: http://bugs.python.org/file9951/pickle_protocol3.rst.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I made the requested improvements and mentioned it in NEWS. Is there
worth putting in the tutorial, since it mentions Unicode strings and raw
strings?

Added file: 
http://bugs.python.org/file9952/py3k_raw_strings_unicode_escapes3.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

The setup.py module contains method  detect_ctypes on line 1546 which 
handles the ctypes module building and testing.  Would it be OK to not 
do any of that on Solaris, if the compiler is not gcc? 

Also, SUN Studio 12, the latest edition of the SUN C compiler has "... 
increased GCC __asm__ and __attribute__ compatibility ...", see 
 and 
.  Maybe 
that one could compile libffi as is, for x86[_64]?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2240] setitimer, getitimer wrapper

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Reopening. Apparently, the tests fail on FreeBSD; see

http://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/builds/77/step-test/0

Can you please look into this?

--
status: closed -> open

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Would it be OK to not 
> do any of that on Solaris, if the compiler is not gcc? 

That would be fine.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2559] atom sorting error when buiding ctypes

[Skip Montanaro]

New submission from Skip Montanaro <[EMAIL PROTECTED]>:

I recently started getting the following error when building the
trunk on Mac OS X Leopard:

  ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o

I tried rm'ing my build directory then rerunning configure.  Same
result.  Here's the make output after simply removing all '*ctypes*'
files from the build directory:

% find build -name '*ctypes*' | xargs rm -r
% make
running build
running build_ext
building '_ctypes_test' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
gcc -L/Users/skip/local/lib -L/opt/local/lib -bundle -undefined
dynamic_lookup
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
-L/Users/skip/local/lib -L/opt/local/lib -o
build/lib.macosx-10.3-i386-2.6/_ctypes_test.so
building '_ctypes' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callproc.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callproc.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/cfield.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/cfield.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes

[issue2240] setitimer, getitimer wrapper

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I'm investigating the problem loewis, thanks for reporting. But it would
be better if someone with running FreeBSD could help me there, in case I
find the cause for this.

Also some changes were made to the original patch:

neal.norwitz did a commit where he says:
"Using a negative time causes Linux to treat it as zero, so disable that
test."
That is not what I get here, maybe a very different kernel, anyway, I
believe he could have mentioned this here.

jeffrey.yasskin said:
".. fix some flakiness in test_itimer_prof, which could detect that the
timer had reached 0 before the signal arrived announcing that fact."

followed by these changes:

signal.setitimer(self.itimer, 0.2)(old)
signal.setitimer(self.itimer, 0.2, 0.2)   (new) -> not sure the reason
for this change

and added:
self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0)) -> this is
the same test I did for itimer_virtual, and it is a bit questionable it
is really useful at all. I don't understand how these changes matches
what he comments on his commit.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2240] setitimer, getitimer wrapper

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

FreeBSD's man page for setitimer/getitimer doesn't look different from
the one in Linux. 
But.. both tests assumes the computer is not so fast that it finishes
"for i in xrange(1)" before the timer expire, maybe it was not
the case in that machine. Both timers (virtual and prof) are set to
expire after 0.2 seconds, and for itimer_virtual it restarts the timer 3
times before setting it to 0.
If someone has a freebsd machine (a fast one apparently) that could run
some tests and help me on this, it would be very nice.

Also sorry for various typos in my last message.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

New patch. I added the new rule and changed the old behavior to be wrong
(a bit) less often. It may mess with code that depended on the previous
wrong results. Given the (AFAIK) exemplificative nature of this file,
this should not be a big problem.

I was going to add a complete table for US DSTs rules, but that is
already available in pytz (http://sourceforge.net/projects/pytz/ ) and
there are many special cases for different US states.

Changes:
Added a four periods approach (the three in my last msg plus "before
1967" -> no DST).
Added links to the Olson Database and pytz (which IMHO would be a great
addition to the std-lib).
Tried to explain the rules, but I think the resulting text is pretty bad.
Corrected a UnboundLocalError bug in my previous patch.

Added file: http://bugs.python.org/file9953/tzinfo-examples3.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2128] sys.argv is wrong for unicode strings

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

This is now fixed in r62178 for Py3k. For 2.6, I don't think fixing it
is feasible.

--
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Attached is one attempt to avoid building the _ctypes module if the 
compiler is not gcc: a patch for Python 2.6a2 with just 2 changes for 
setup.py based on the value of config variable CC.

--
keywords: +patch
Added file: http://bugs.python.org/file9954/setup.py.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I think this is incorrect; CC might also be "gcc -pipe" or
"/usr/local/bin/gcc", or some such, and would still be gcc (perhaps even
/usr/local/bin/cc).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

I'm curious:  Why do you insist on using the sun compiler?  Are there
political or technical reasons?

Another thing: in principle it should be possible to build a libffi
shared library with gcc, and use it in a sun-c compiled python build. 
At least this would avoid the need to port assembler code from gcc to sun c.

Python should be configured with './configure --with-systemffi' for that.

--
nosy: +theller

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2541] Unicode escape sequences not parsed in raw strings.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

What about the "raw-unicode-escape" codec?
Can we leave it different from raw strings literals?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

agreed, do not check to see if the string is == 'gcc'.  Instead,
actually execute the CC compiler with a -v flag and test if 'gcc
version' in output.

something like this (but split into a few statements for readability):

if 'gcc version' not in os.popen(sysconfig.get_config_vars().get('CC',
'gcc') + ' -v').read():
  # gcc is required for ctypes

--
nosy: +gregory.p.smith

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Well, so much for the first attempt.  I'll see what it takes to use 
something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
qualifies.

Also, I am using SUN's compilers on Solaris 10 for 'political' and some 
technical reasons.  And I am building alpha and beta Python releases 
mainly to help Python move forward.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

Updated patch: reworked some internals, and added generalization of
functioncalls after talking with Guido. *args is now considered just
another positional argument, and can occur anywhere in the positional
argument section. It can also occur more than once. Keyword arguments
now have to appear after *args, and **kwargs can now occur multiple
times at any position in the keyword argument list. test_extcall has
some examples.

(The opcodes are largely unaffected; just the order of '*args' and
keyword arguments is changed. Behind the scenes, anything after the
first '*args' argument is collapsed into a single *args, and everything
after the first '**kwargs' is likewise collapsed. The common case
(meaning any currently valid syntax, barring the 2to3 fix to swap *args
and keyword arguments) does not change in meaning or codepath, just the
complex cases are handled differently.)

This is still Work In Progress. To do: implement the dict unpacking
syntax (the mechanics are already there for keyword arguments to
functioncalls), make sure the precendence of * is correct, get more
complete test coverage, iron out the cosmetic bugs in the 2to3 fixer.

Bzr branch for this patch is
http://code.python.org/python/users/twouters/starunpack . There is also
a branch with just the functioncall changes (although the starunpack
changes are a small sprinkling on top of that branch, as it uses the
same new mechanics): http://code.python.org/python/users/twouters/funcargs .

Added file: http://bugs.python.org/file9955/starunpack.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Changes by Thomas Wouters <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9673/morestar.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753245] Add RegEnableReflectionKey and RegDisableReflectionKey

[Mark Hammond]

Mark Hammond <[EMAIL PROTECTED]> added the comment:

Been sitting here for a while without comment, so:
Sending_winreg.c
Committed revision 62180.

--
resolution:  -> fixed
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2560] removal of stale code from myreadline.c

[Joseph Armbruster]

New submission from Joseph Armbruster <[EMAIL PROTECTED]>:

This patch removes a stale for loop from myreadline.c:

http://svn.python.org/projects/python/trunk @ 62180

--
components: Interpreter Core
files: myreadline.patch
keywords: patch
messages: 65015
nosy: JosephArmbruster
severity: normal
status: open
title: removal of stale code from myreadline.c
versions: Python 2.6
Added file: http://bugs.python.org/file9956/myreadline.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2065] trunk version does not compile with vs8 and vc6

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

_wstat64 does not exist in VC6, so used GetFileAttributesW instead.

Added file: http://bugs.python.org/file9957/ocean.zip

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue815646] thread unsafe file objects cause crash

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

I'm reviewing this patch now and plan to commit it after some testing.

A couple comments:

I'd rename your sts variables to status.

Also FYI:

Your use of volatile on the int unlocked_count member of PyFileObject
does not do what you think it does and isn't needed here anyways.

Access to the variable is always protected by the GIL unlocking and
locking of which should cause an implicit memory barrier guaranteeing
that all other CPUs in the system will see the same value stored in the
structure in memory.

The C volatile keyword on the other hand does not guarantee this. 
volatile is useful for memory mapped IO but it makes no guarantees about
cache coherent access between multiple CPUs.  (the atomic types in the
recent C++ standards are meant for that)


Both of the above are trivial changes, no need for another patch.

--
assignee: tim_one -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.0


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

What's dict unpacking? I hope it's not an implementation of this sad
idea posted recently:

{'a': x, 'b': y} = {'a': 42, 'b': 'hello'}  # Same as x, y = 42, 'hello'

:-)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue508157] urllib.urlopen results.readline is slow

[Daniel Diniz]

Daniel Diniz <[EMAIL PROTECTED]> added the comment:

Well, this issue is still hurting performance, the most recent example
was with a developer of a download manager.

I suggest adding a buffer size argument to HTTPResponse.__init__
(defaulting to zero), along with docs that explain the problems that may
arise from using a buffer. If there's any chance this might be accepted,
I'll write a patch.

--
nosy: +ajaksu2
versions: +Python 2.6 -Python 2.2


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

> Well, so much for the first attempt.  I'll see what it takes to use 
> something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
> qualifies.

I would prefer to see the configure test for gcc be recorded and
passed through, over trying to detect gcc from its -v output, yes.
Who knows what other compilers will do when passed the -v option?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue508157] urllib.urlopen results.readline is slow

[Aren Olson]

Aren Olson <[EMAIL PROTECTED]> added the comment:

I can indeed confirm that this change creates a HUGE speed difference.
Using the code found at [1] with python2.5 and apache2 under Ubuntu,
changing the buffer size to 4096 improved the time needed to download
10MB from 15.5s to 1.78s, almost 9x faster. Repeat downloads of the same
file (meaning the server now has the file cached in memory), yield times
of 15.5s and 0.03s, a 500x improvement. When fetching from a server on
the local network, rather than from localhost, these times become 15.5s
and 0.9s in both cases, a 17x speedup. Real-world situations will likely
be a mix of these, however it is safe to say the speed improvement will
be substantial. Adding an option to adjust the buffer size would be very
welcome, though the default value should still be zero, to avoid the
issues already mentioned.

[1] - http://pastebin.ca/973578

--
nosy: +reacocard


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue815646] thread unsafe file objects cause crash

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

I've attached my patch that I want to commit.  The main change from
filethread4 is some cleanup in file_test to make it run a lot faster and
add verbose mode output to indicate how well it is actually testing the
problem (counting the times that close raises IOError).

One concern holding up my commit:

Will this test pass on windows?  It is opening and closing the same file
in 'w+' mode from multiple threads of the same process at once.

Can someone with a windows dev environment please apply this patch and
test it.  If it dislikes the above file behavior, can you propose a fix
for it (set windows file non-exclusive flags or whatever you're supposed
to do... the worse alternative would be to use a new filename on each
open but that could cause a nightmare of thousands of new files being
created by the test which then have to be cleaned up)?

thanks,
-gps

Added file: http://bugs.python.org/file9958/filethread4-gps01.patch


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2292] Missing *-unpacking generalizations

[Thomas Wouters]

Thomas Wouters <[EMAIL PROTECTED]> added the comment:

No, it's what you asked for in msg63551:

> How about dicts?
> kwds = {'z': 0, 'w': 12}
> {'x': 1, 'y': 2, **kwds}  # {'x': 1, 'y': 2, 'z': 0, 'w': 12}

(unpacking of dicts in dicts.)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com