[issue4072] build_py support for lib2to3 is stale

[Martin v. Löwis]

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

Here is a patch. I also include a test case, which is intended to go
into the Demo directory.

--
keywords: +patch
Added file: http://bugs.python.org/file11744/build_py.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Martin v. Löwis]

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

> It is not documented anywhere but in the code

These also appear in file names of bdist commands, right? So I think it
should be documented.

> We (Bob Ippolitto and I) had some discussion about the architecture  
> strings when
> we were working on support for universal binaries and rejected my  
> initial suggestion
> of using "i386,ppc" instead of "fat" because that would be unwieldy.

OK. I wonder how you will call fat 64-bit binaries (i.e. ppc64 and
amd64), but I can live with that semantics as long as it's documented
(I actually question that it is documented in the code. If somebody
would put "-arch Itanium" in her CFLAGS, which might be supported in
10.9, it would infer that the architecture is "fat").

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

On 7 Oct, 2008, at 22:13, Martin v. Löwis wrote:

>
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
>> Somewhere along the way the calculation of the architecture string  
>> got
>> messed up, resulting in the current situation. That is, the current
>> situation is not as designed by the original author of the universal
>> binary support code.
>
> Ok, what *is* the desired way of naming architectures on that system?
> Is that documented somewhere?

It is not documented anywhere but in the code, but this is the  
intended behaviour:

* A single architecture build (what you would build on any other unix  
platform)
   uses the architecture string of the architecture
   it was build for (that is, "i386", "ppc", "x86_64" or "ppc64")

* A 32-bit universal build uses "fat" as the architecture string,  
regardless of the
architecture of the machine we're running on.
As an exception: OS X 10.3.9 machines are treated as if we're on a  
single
architecture build because the compiler on that platform doesn't  
support
building fat binaries.

* A 4-way universal build (that is, including all architectures  
supported by
OSX) uses "universal" as the architecture string.

We (Bob Ippolitto and I) had some discussion about the architecture  
strings when
we were working on support for universal binaries and rejected my  
initial suggestion
of using "i386,ppc" instead of "fat" because that would be unwieldy.

Ronald

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4074] Building a list of tuples has non-linear performance

[Martin v. Löwis]

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

This is a known problem; see the GC discussions in June for an example, e.g.

http://mail.python.org/pipermail/python-dev/2008-June/080579.html

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4074] Building a list of tuples has non-linear performance

[Gregory P. Smith]

New submission from Gregory P. Smith <[EMAIL PROTECTED]>:

The attached script simply loops building a list of tuples.  It has
horrible performance as the list gets larger compared to something
appending simple objects like ints to the list.

% python tuple_gc_hell.py  ~
...
100 1.3615500927
200 2.95893096924
300 4.53531980515
400 5.62795209885
500 7.70974612236
...

The time it takes to execute grows linearly with the number of tuples
already appended to the list.

Turning on gc.debug(gc.DEBUG_STATS) shows why as does running python
under a profiler:

  %   cumulative   self  self total  
 time   seconds   secondscalls   s/call   s/call  name   
 27.85115.84   115.8414270 0.01 0.02  collect
 21.19204.0188.17 1115120314   0.00 0.00  tupletraverse
 13.14258.6554.64 1655624731   0.00 0.00  visit_reachable
 10.72303.2544.60 1655624731   0.00 0.00  visit_decref
  5.97328.1024.85  338 0.07 1.10  PyEval_EvalFrame


It appears the cyclic gc is rechecking all of these tuples repeatedly. 
disabling gc during the loop or using a very high gc.set_threshold hides
the problem.

--
components: Interpreter Core
files: tuple_gc_hell.py
messages: 74512
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Building a list of tuples has non-linear performance
type: performance
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11743/tuple_gc_hell.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1028088] Cookies without values are silently ignored (by design?)

[Andres Riancho]

Andres Riancho <[EMAIL PROTECTED]> added the comment:

Sorry to bother you guys after so much time, but I think that there is
at least one bit of the RFC that isn't respected by this "name=value"
thing... If we look at the RFC we'll see this:

   cookie-av   =   "Comment" "=" value
   |   "Domain" "=" value
   |   "Max-Age" "=" value
   |   "Path" "=" value
   |   "Secure"
   |   "Version" "=" 1*DIGIT

As you may have noticed, "Secure" doesn't have any values. Also, (but
out of the RFC) there is a commonly used cookie flag named "HttpOnly"
[0], which would be nice to correctly parse also.

Should _CookiePattern be modified to address this issue? 

[0] http://www.owasp.org/index.php/HTTPOnly

--
nosy: +andresriancho

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)

[Hirokazu Yamamoto]

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

According to http://msdn.microsoft.com/en-us/library/aa364963.aspx,
current implementation have several problems.

>In the ANSI version of this function, the name is limited to MAX_PATH
>characters. To extend this limit to 32,767 wide characters, call the
>Unicode version of the function and prepend "\\?\" to the path.

:-(

>If the lpBuffer buffer is too small to contain the path, the return
>value is the size, in TCHARs, of the buffer that is required to hold
>the path and the terminating null character.

We should allocate new buffer with this size and retry like already
doing for GetCurrentDirectory.

And one decision problem... What should we do when too long str is
passed to ntpath._getfullpathname? Report overflow error? Or convert to
unicode and retry with GetFullPathNameW? Hmm

--
nosy: +ocean-city

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3994] import fixer misses some symbols

[Nick Edds]

Nick Edds <[EMAIL PROTECTED]> added the comment:

I'll look in to it. Just give me a couple of days.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)

[Jason Day]

Jason Day <[EMAIL PROTECTED]> added the comment:

Running help() or mktemp() causes _getfullpathname to be called with the whole 
system path (791 characters). If you pass that to _getfullpathname as str it 
throws the aforementioned TypeError. If it's passed as unicode, it returns an 
empty string.
The offending _getfullpathname call occurs on the first call to one of these 
methods. Future calls to either do not call it (unless, of course, the first 
failed).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4073] distutils build_scripts and install_data commands need 2to3 support

[Mark Hammond]

New submission from Mark Hammond <[EMAIL PROTECTED]>:

The distutils commands 'build_scripts' and 'install_data' both may end
up installing .py files.  Such .py file should be able tobe run through
lib2to3 in the same way supported by build_py.

pywin32 has ended up with something like:

class my_build_scripts(build_scripts):
def copy_file(self, src, dest):
dest, copied = build_scripts.copy_file(self, src, dest)
# 2to3
if not self.dry_run and copied:
refactor_filenames([dest])
return dest, copied

where 'refactor_filenames' is (basically) the lib2to3 block from
build_py moved to a utility function.

--
components: Distutils
messages: 74507
nosy: loewis, mhammond
severity: normal
status: open
title: distutils build_scripts and install_data commands need 2to3 support
type: feature request
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4072] build_py support for lib2to3 is stale

[Mark Hammond]

New submission from Mark Hammond <[EMAIL PROTECTED]>:

The way build_py uses lib2to3 is out of date.  Instead of a dummy
Options object a dict should be used, and it seems the 'fixers' must
explicitly be loaded.  I'm afraid I don't have a specific patch as I
don't have a good test case, but the lib2to3 code needs to look
something like:

from lib2to3.refactor import RefactoringTool, get_fixers_from_package
fixers = get_fixers_from_package('lib2to3.fixes')
options = dict(doctests_only=False, fix=[], list_fixes=[], 
   print_function=False, verbose=False,
   write=True)
r = RefactoringTool(fixers, options)
r.refactor(self.updated_files)

--
components: Distutils
messages: 74506
nosy: loewis, mhammond
severity: normal
status: open
title: build_py support for lib2to3 is stale
versions: Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4036] Support bytes for subprocess.Popen()

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Oops, I attached the wrong patch :-/

--
dependencies: +Support bytes for os.exec*()
Added file: http://bugs.python.org/file11742/subprocess-bytes.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)

[Amaury Forgeot d'Arc]

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

The (buffer overflow) message indicates that the argument is too long to 
be converted. In your case, it seems that the path is longer than 
MAX_PATH=255 characters. What is the value of the argument of 
_getfullpathname()?

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4036] Support bytes for subprocess.Popen()

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11696/os_exec_bytes.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4035] Support bytes for os.exec*()

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11695/os_exec_bytes.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4035] Support bytes for os.exec*()

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Improved patch:
 - support bytes in the env dictionary using the file system default 
encoding
 - support bytes for program arguments but only on a POSIX system

Document is not updated yet.

Added file: http://bugs.python.org/file11741/os_exec_bytes-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4071] ntpath.abspath can fail on Win Server 2008 (64-bit)

[Jason Day]

New submission from Jason Day <[EMAIL PROTECTED]>:

On my system (Windows Server 2008 SP1 - 64-bit, Python 2.5.2 - 32-bit),
simple actions like:
>>> help(help) # Or any function
or
>>> import tempfile
>>> f = tempfile.mktemp()
result in this (rather confusing) error:
TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str

Apparently, _getfullpathname() chokes on certain paths if they are not
supplied as unicode. Locally, I was able to work around the issue by
changing the call to _getfullpathname in ntpath.abspath to:
path = str(_getfullpathname(unicode(path)))

--
components: Windows
messages: 74502
nosy: JDay
severity: normal
status: open
title: ntpath.abspath can fail on Win Server 2008 (64-bit)
type: crash
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

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

Just humble thought...
If we can replace stat(2) + S_ISDIR/S_ISREG check with
GetFileAttributesEx, maybe we are safe for this kind of problem, and can
solve issue3099 same time? :-)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>:


Added file: 
http://bugs.python.org/file11740/not_use_stat_in_import_on_windows.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>:


Removed file: 
http://bugs.python.org/file11739/not_use_stat_in_import_on_windows.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11732/traceback_unicode-3.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11633/traceback_unicode-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11612/traceback_unicode.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

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

zipimport.c seems fine, because stat(2) succeeds for UNC file. It fails
for UNC folder. (zip file is absolutely file)

Already fix for issue1293 was in, so maybe I should create the patch for
that direction but... anyway this issue seems to be fixed by my patch. I
also confirmed the test script in http://bugs.python.org/msg56523 works.

--
keywords: +patch
Added file: 
http://bugs.python.org/file11739/not_use_stat_in_import_on_windows.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[Amaury Forgeot d'Arc]

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

One last thing: there is a path where lineobj is not freed (when 
PyUnicode_Check(lineobj) is false); I suggest to move 
Py_XDECREF(lineobj) just before the final return statement.
Reference counting is fun ;-)

> Should I stop on the first error instead of using PyErr_Clear()?
> I would like to display the traceback even if an function failed.
You are right. Common failures should clear the error and return 0.
In your patch, there is one remaining place, the call to PyFile_GetLine().

More fun will arise when my Windows terminal (encoding=cp1252) will try 
to display Chinese characters. Let's pretend this is yet another issue.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[Amaury Forgeot d'Arc]

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

This issue depends on #3975 to properly display tracebacks from python 
files with encoding.

--
dependencies: +PyTraceBack_Print() doesn't respect # coding: xxx header

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11738/tokenizer-coding-4.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11737/traceback_unicode-4.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11609/test_traceback-gbk.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11717/tokenizer-coding-3.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11625/tokenizer-coding-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2384] [Py3k] line number is wrong after encoding declaration

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

@amaury: Ok, I added your long comment in tokenizer.c. You're also 
right about the strange code in the test. I reused ocean-city's 
test. "sys.exc_info()[2].tb_lineno" raises an additional (useless) 
error. So I simplified the code to use only "raise RuntimeError(...)" 
with the try/except/else.

Since tokenizer.c is hard to understand, I don't wnat to change the 
code of tok_nextc().

Added file: http://bugs.python.org/file11737/traceback_unicode-4.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

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

Ah, of cource, please change path to fit you environment. > test prog

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Hirokazu Yamamoto]

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

I think this is stat(2) problem on windows. Please try following test
program.

#include 
#include 
#include 

void test(const char *path)
{
struct stat st;

printf("%s %d %d\n", path, stat(path, &st), GetFileAttributes(path));
}

int main()
{
test("e:\\shared");
test("e:\\shared\\"); /* issue1293 */
test("e:\\shared\\a.py");
test("whiterab-c2znlh\\shared"); /* this issue */
test("whiterab-c2znlh\\shared\\");
test("whiterab-c2znlh\\shared\\a.py");
}

And this is result.

e:\shared 0 16
e:\shared\ -1 16
e:\shared\a.py 0 32
\\whiterab-c2znlh\shared -1 16
\\whiterab-c2znlh\shared\ 0 16
\\whiterab-c2znlh\shared\a.py 0 32

As discussed in issue1293, stat(2) fails for the normal folder path with
trailing slash, and also fails for the UNC folder path without trailing
slash. I'm using VC6, but same behavior on VC9?

trunk/Python/import.c(3160) and trunk/Modules/zipimport.c(99) is using
stat(2).

I'll create patch to prove my observation. :-)

--
nosy: +ocean-city

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

[Trent Mick]

Trent Mick <[EMAIL PROTECTED]> added the comment:

> What if you compile using 'gcc -arch ppc64 main.c'?

$ gcc -arch ppc64 main.c
$ ./a.out
sizeof(_Bool) is 1

As you figured out.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Thanks for your remarks amaury. I improved my patch:
 - PyMem_FREE(found_encoding) is called just after PyFile_FromFd()
 - Create static subfunction _Py_FindSourceFile(): find a file in 
sys.path
 - Consider that sys.path contains only unicode (and not bytes) string
 - Clear exception on "truncated = PyUnicode_FromUnicode(p, len);" 
error, but continue the execution
 - I added PyUnicode_check(lineobj)
 - Replace open(filename) by open(namebuf) (while searching the full 
path of the file) <= fix a regression introduced by my patch

Should I stop on the first error instead of using PyErr_Clear()? I 
would like to display the traceback even if an function failed.

Sum up of the patch version 4:
 - use open(O_RDONLY | O_BINARY) + PyFile_FromFd() instead of fopen()
 - open the file in unicode mode using the Python encoding found in 
the "#coding:..." header
 - consider sys.path as a list of unicode strings (and not of bytes 
strings)

I used _PyUnicode_AsStringAndSize() to convert unicode to string to be 
consistent with tb_printinternal(). As you noticed, it uses UTF-8 
which should is on Windows :-/ I propose to open a new issue when this 
one will be closed :-)

Added file: http://bugs.python.org/file11736/traceback_unicode-4.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4070] python tests failure if builddir <> sourcedir

[Roumen Petrov]

New submission from Roumen Petrov <[EMAIL PROTECTED]>:

The proposed patch add possibility to run python tests if python is
build outside source tree on POSIX systems.

--
components: Tests
files: python-trunk-DIST.patch
keywords: patch
messages: 74492
nosy: rpetrov
severity: normal
status: open
title: python tests failure if builddir <> sourcedir
versions: Python 2.7
Added file: http://bugs.python.org/file11735/python-trunk-DIST.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Martin v. Löwis]

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

Ok, un-targetting this from 2.5.3 then. 

Usage of IsUNCRoot disappeared as part of r42230, which dropped usage of
the C library for stat implementations. This only affects os.stat,
though, so I don't see the relation to this issue.

For the record: What *exactly* is the problem? I.e. specifically, what
do you do, what happens, what do you expect to happen instead?

--
versions:  -Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Kristján Valur Jónsson]

Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment:

No, not really.
Again, I refer to defect 954115 by glchapman.  And note that those 
functions added there are actually not used.
I was hoping that there was someone here more familiar with importing 
on PC.
I'll go and see if the old defect still applies and if there is perhaps 
a more general fix to be made.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3367] Uninitialized value read in parsetok.c

[Martin v. Löwis]

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

Ok, un-targetting it from 2.5.3 for now.

--
versions:  -Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3367] Uninitialized value read in parsetok.c

[Kristján Valur Jónsson]

Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment:

Now that the 'easy' keyword is absent, I'm afraid this is out of my 
depth.
I'll run purify again and try to find the exact repro case.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3994] import fixer misses some symbols

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
nosy: +nedds

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3873] Unpickling is really slow

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

The solution is to add a read buffer to Unpickler (Pickler already has a
write buffer, so that why it is unaffected). I believe this would
mitigate much of the (quite large) Python function call overhead.

cPickle has a performance hack to make it uses cStringIO and PyFile 
directly (via C function calls). In Python 3, the hack was removed since
cStringIO.h and fileobject.h aren't public anymore. This explains the
0.02s deviation you are getting for dump speed.

--
nosy: +alexandre.vassalotti

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3448] Multi-process 2to3

[Benjamin Peterson]

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

I'm not opposed to having the support available. I just don't what it
enabled by default.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4004] missing newline in "Could not convert argument %s to string" error message

[Amaury Forgeot d'Arc]

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

Committed as r66838.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4069] set.remove raises confusing KeyError

[Amaury Forgeot d'Arc]

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

Committed r66836 (trunk) and r66837 (2.6).
This will merge nicely into py3k.

Hello Carl Friedrich, and thanks for the report!

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Roumen Petrov]

Roumen Petrov <[EMAIL PROTECTED]> added the comment:

Now in mingw case the common is "python posix build system".
If the cross-compilation work what is problem to build in native
environment? Personally I prefer to build in cross environment. It is
convenient.

There is no problem to run python tests in the native environment.
In emulated environment most of the python test run smoothly.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4051] use of TCHAR under win32

[Martin v. Löwis]

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

> What about to substitute UNICODE macro as example with RAWUNICODE in the
> source ?

That would work as well. As it stands, the macro names are equivalent to
the ones in pickle.py, which is a useful property to have. So I'm in
favor of the proposed change.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4051] use of TCHAR under win32

[Roumen Petrov]

Roumen Petrov <[EMAIL PROTECTED]> added the comment:

What about to substitute UNICODE macro as example with RAWUNICODE in the
source ?

--
nosy: +rpetrov

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Martin v. Löwis]

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

> Martin meaning of target and host is different.
> There is no reason to use "Canadian Cross": build->host->target.
> It is about more simple cross-compilation case: build->host.

Terminology issues aside, I hope people still will understand my
objection. I meant it this way:
- host system: system hosting Python build process
- target system: system intended to run resulting Python executable
Whether that conforms to autoconf should be irrelevant, as long
as we aren't talking about configure.in changes.

> About loading of modules in build environment: some OS-es can run
> binaries from other OS-es.

Sure. However, I don't think this is the general case for
cross-compilation, and I don't think cross-compilation support in
Python should assume this is possible. Instead, cross-compilation
should assume that build system and target system have anything
in common (except that target headers and for-target cross tools
are installed on the build system).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3367] Uninitialized value read in parsetok.c

[Martin v. Löwis]

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

Kristján, you suggested this patch to be considered for 2.5.3.

It seems the patch is incorrect. Can you provide a correct one?

--
nosy: +loewis
versions: +Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3677] importing from UNC roots doesn't work

[Martin v. Löwis]

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

Kristjan, you suggested this issue for consideration for 2.5.3.

Is there an actual patch to apply?

If not, the issue should get forwarded to 2.7 (and then to 2.8, and so
on, until somebody actually comes up with a patch).

--
nosy: +loewis
versions: +Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Martin v. Löwis]

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

> Somewhere along the way the calculation of the architecture string got 
> messed up, resulting in the current situation. That is, the current 
> situation is not as designed by the original author of the universal 
> binary support code.

Ok, what *is* the desired way of naming architectures on that system?
Is that documented somewhere?

--
title: distutils.util.get_platform() is wrong for universal builds on macosx -> 
distutils.util.get_platform() is wrong for universal builds on macosx

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Roumen Petrov]

Roumen Petrov <[EMAIL PROTECTED]> added the comment:

Martin meaning of target and host is different.
There is no reason to use "Canadian Cross": build->host->target.
It is about more simple cross-compilation case: build->host.

About loading of modules in build environment: some OS-es can run
binaries from other OS-es.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Roumen Petrov]

Roumen Petrov <[EMAIL PROTECTED]> added the comment:

I found the patch cross-2.5.1.patch as too limited.
I'm interesting in this topic and I post patch in issue3871 that
continue work from issue841454 and issue1412448.

--
nosy: +rpetrov

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

On 7 Oct, 2008, at 18:29, Trent Mick wrote:

>
> Trent Mick <[EMAIL PROTECTED]> added the comment:
>
>> I get:
>>
>> sizeof(_Bool)=4 bytes
>>
>> on a G4 PPC.
>
> Same thing on a G5 PPC:
>
> $ cat main.c
> #include 
>
> int main(void) {
>printf("sizeof(_Bool) is %d\n", sizeof(_Bool));
> }
> $ gcc main.c

What if you compile using 'gcc -arch ppc64 main.c'?

Ronald

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

The basic idea is that the architecture bit of get_platform() should 
tell you something about the archicture for which a build is valid. 
That's why 'i386' or 'ppc' is not very useful for a universal build. The 
original author of the universal binary support choose 'fat' as the 
architecture designator for universal builds ("fat binaries").

Somewhere along the way the calculation of the architecture string got 
messed up, resulting in the current situation. That is, the current 
situation is not as designed by the original author of the universal 
binary support code.

Another reason for fixing this is that setuptools uses the platform 
designator of the current system and a downloaded binary archive to 
determine if the two are compatible. In the current situation univeral 
binary distributions built on a PPC system don't work on an i386 system 
(as far as setuptools is concerned).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Martin v. Löwis]

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

> the compiling strategy for Python (IIRC) is to compile everything,
> including modules that will never work, and use compiler errors as a
> signal to not include a module in the result. 

I don't think this can work in the cross-compilation case, though
(or the entire setup.py part of it can't really work). It uses the
target's python binary to run setup.py, compiles the modules, and then
tries to load them. In a cross-compilation case, you can't run the
target python binary, and even if you use a host python instead, you
can't load the target extension modules (unless the "cross" compilation
is for the same microprocessor and operating system - a case I'm not
very much interested in).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4068] Backport fix for issue 3312

[Martin v. Löwis]

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

Looks fine to me. Please apply (don't forget a NEWS entry).

--
nosy: +loewis
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4067] ast.fix_missing_locations() breaks if node doesn't have "_attributes" variable

[Amaury Forgeot d'Arc]

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

empty_tuple should be DECREF'ed at the end of the function.
Otherwise the patch is fine.

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4065] _multiprocessing doesn't build on macosx 10.3

[Martin v. Löwis]

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

What does sendmsg(2) say what to include? What about writev(2)? (the
latter, on Linux, says that sys/uio.h is indeed the correct header)

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

[Martin v. Löwis]

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

> When using a universal build of python on macosx 
> distutils.util.get_platform should use "fat" for the machine 
> architecture, instead of the architecture of the current machine.

Can you please explain why it should do so? Where do these architecture
names come from?

--
nosy: +loewis
title: distutils.util.get_platform() is wrong for universal builds on macosx -> 
distutils.util.get_platform() iswrong for universal builds on macosx

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4017] IDLE 2.6 broken on OSX (Leopard)

[Kent Johnson]

Changes by Kent Johnson <[EMAIL PROTECTED]>:


--
nosy: +kjohnson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4069] set.remove raises confusing KeyError

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Patch looks fine.  I see no need to backport to 2.5 though.

--
assignee: rhettinger -> amaury.forgeotdarc
keywords:  -needs review
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2218] Enhanced hotshot profiler with high-resolution timer

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. <[EMAIL PROTECTED]> added the comment:

May I ask what the reasoning is for further developing hotshot as part
of the core?  My understanding, based on discussions on python-dev, is
that hotshot is being deprecated in favor of cProfile.

If hotshot still provides functionality that's interesting (and it may),
perhaps it makes sense to maintain and improve it in a separate
distribution.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2218] Enhanced hotshot profiler with high-resolution timer

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.7 -Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2281] Enhanced cPython profiler with high-resolution timer

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.7 -Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3163] module struct support for ssize_t and size_t

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.7 -Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3163] module struct support for ssize_t and size_t

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.5.3 -Python 2.7

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4067] ast.fix_missing_locations() breaks if node doesn't have "_attributes" variable

[Armin Ronacher]

Armin Ronacher <[EMAIL PROTECTED]> added the comment:

The root of the problem is that ast.AST doesn't have _fields or
_attributes.  I think the better solution is to add these attributes to
the root class which makes it easier to work with these objects.

I attached a diff for asdl_c.py which fixes that problem by adding
attributes to the AST class.

Run `python Parser/asdl_c.py -h Python Parser/Python.asdl` to regenerate
the Python-ast.c file.

Can someone review the diff?

--
nosy: +aronacher
Added file: http://bugs.python.org/file11734/asdl_c.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2281] Enhanced cPython profiler with high-resolution timer

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.5.3 -Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2218] Enhanced hotshot profiler with high-resolution timer

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 2.5.3 -Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4069] set.remove raises confusing KeyError

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4069] set.remove raises confusing KeyError

[Amaury Forgeot d'Arc]

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

The KeyError initially contains the correct frozenset, but its content
is swapped with the original set object (yes, like C++ std::set::swap(),
this mutates the frozenset!).

Attached a patch with unit test. The exception now shows the original key:
KeyError: {3, 4}

--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file11733/set_remove.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

[Trent Mick]

Trent Mick <[EMAIL PROTECTED]> added the comment:

> I get:
>
> sizeof(_Bool)=4 bytes
>
> on a G4 PPC.

Same thing on a G5 PPC:

$ cat main.c
#include 

int main(void) {
printf("sizeof(_Bool) is %d\n", sizeof(_Bool));
}
$ gcc main.c
$ ./a.out
sizeof(_Bool) is 4

--
title: PyUnicode_DecodeUTF16(...,   byteorder=0) gets it wrong on Mac OS 
X/PowerPC -> PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS 
X/PowerPC

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4063] sphinx: make all-pdf does not exist.

[Georg Brandl]

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

Are you sure you're doing "make all-pdf" in the build/latex directory?

--
resolution:  -> works for me
status: open -> pending

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4069] set.remove raises confusing KeyError

[Carl Friedrich Bolz]

New submission from Carl Friedrich Bolz <[EMAIL PROTECTED]>:

When trying to remove a set from a set, the KeyError that is raised is
confusing:

Python 2.6 (r26:66714, Oct  7 2008, 13:23:57)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = set([frozenset([1, 2]), frozenset([2, 3])])
>>> s.remove(set([3, 4]))
Traceback (most recent call last):
  File "", line 1, in 
KeyError: frozenset([])


I understand that s.remove(set(...)) turns the set into a frozenset, but
I was expecting this converted frozenset to be attached to the KeyError,
not an empty set.

--
components: Interpreter Core
messages: 74461
nosy: cfbolz
severity: normal
status: open
title: set.remove raises confusing KeyError
type: behavior
versions: Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[Amaury Forgeot d'Arc]

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

I still have remarks about traceback_unicode-3.patch, that I did not see
before:
- (a minor thing) PyMem_FREE(found_encoding) could appear only once,
just after PyFile_FromFd.
- I feel it dangerous to call the PyUnicode_AS_UNICODE() macro without
checking that PyFile_GetLine() actually returned a PyUnicode object.
- If the "truncated" variable is NULL, an exception has been set; it is
necessary to exit the function.

___
Python tracker <[EMAIL PROTECTED]>

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

=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=

[Marc-Andre Lemburg]

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

On 2008-10-07 14:33, Ronald Oussoren wrote:
> Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
> 
> Annoyingly enough my patch isn't good enough, it turns out that ctypes 
> has introduced a SIZEOF__BOOL definition in configure.in and that needs 
> special caseing as well.
> 
> pymacconfig.h.patch2 fixes that issue as well. Do you have access to a 
> PPC G5 system? I've determined the correct value of SIZEOF__BOOL for 
> that platform by reading the assembly code for a small test program and 
> hence am not 100% sure that sizeof(_Bool) actually is 1 on that 
> architecture.

Using this helper:

#include 
main() {
printf("sizeof(_Bool)=%i bytes\n", sizeof(_Bool));
}

I get:

sizeof(_Bool)=4 bytes

on a G4 PPC.

Seems strange to me, but reasonable since it is defined like this
in stdbool.h:

#if __STDC_VERSION__ < 199901L && __GNUC__ < 3
typedef int _Bool;
#endif

--
title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS 
X/PowerPC -> PyUnicode_DecodeUTF16(...,  byteorder=0) gets it wrong on Mac OS 
X/PowerPC

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2810] _winreg.EnumValue fails when the registry data includes multibyte unicode characters

[Daniel Stutzbach]

Changes by Daniel Stutzbach <[EMAIL PROTECTED]>:


--
versions: +Python 2.5.3

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Han-Wen Nienhuys]

Han-Wen Nienhuys <[EMAIL PROTECTED]> added the comment:

@Luke

the compiling strategy for Python (IIRC) is to compile everything,
including modules that will never work, and use compiler errors as a
signal to not include a module in the result. 

this is what I end up with for 2.4

./usr/bin/libpython2.4.dll
./usr/bin/imageop.dll
./usr/bin/_codecs_hk.dll
./usr/bin/_codecs_jp.dll
./usr/bin/_heapq.dll
./usr/bin/_random.dll
./usr/bin/cPickle.dll
./usr/bin/cStringIO.dll
./usr/bin/regex.dll
./usr/bin/collections.dll
./usr/bin/_locale.dll
./usr/bin/_testcapi.dll
./usr/bin/_codecs_tw.dll
./usr/bin/pyexpat.dll
./usr/bin/_hotshot.dll
./usr/bin/mmap.dll
./usr/bin/math.dll
./usr/bin/binascii.dll
./usr/bin/array.dll
./usr/bin/smtpd.py
./usr/bin/cmath.dll
./usr/bin/audioop.dll
./usr/bin/_codecs_kr.dll
./usr/bin/parser.dll
./usr/bin/itertools.dll
./usr/bin/_csv.dll

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1597850] Cross compiling patches for MINGW

[Han-Wen Nienhuys]

Han-Wen Nienhuys <[EMAIL PROTECTED]> added the comment:

I'm still interested in this, but the last time I did anything, I jumped
through all the hoops (see conversation here), and not a single change
was put into trunk. I'm not very enthousiastic about spending a lot time
on this again.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X

[Bill Janssen]

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Yes, we were looking at using this for linking PyLucene's JCC extension.
 I believe we came up with a different way of doing it.  It would still
be useful to have distutils.unixccompiler.runtime_library_dir_option()
updated to understand the right flags for Leopard.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11732/traceback_unicode-3.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[Amaury Forgeot d'Arc]

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

> Ok, O_BINARY and GIL fixed.
which patch? ;-)

> I just realized that sys.path is considered as a bytes string
> (PyBytes_Check) whereas Python3 uses an unicode string!
> 
> ['', '/home/haypo/prog/python-ptrace', (...)]
> >>> sys.path.append(b'bytes'); sys.path
> ['', '/home/haypo/prog/python-ptrace', '(...)', b'bytes']
> 
> Oops, so it's possible to mix strings and bytes. But the normal case
is a list 
> of unicode strings. Another fix is needed :-/

You could do like the import function, which converts unicode with the
fs encoding. See the code in import.c, below "PyList_GetItem(path, i)"

> I don't know how to get into "if (fd < 0)" (code using sys.path).
> Any clue?

The .pyc stores the full path of the .py, at compilation time. If the
directory is moved, or accessed with another name (via mounts or soft
links), the traceback displays the filename as stored in the .pyc file,
but the content can still be displayed. It does not work every time,
though, for example when the directory is shared between Windows & Unix.

> > Besides this, the "char* filename" is relevant only on utf8-encoded
> > filesystems, and will not work on windows with non-ascii filenames.
> > But this is another issue.
> 
> I don't know the Windows API enough to answer.

Windows interprets the char* variables with its system-set "mbcs"
encoding. On my machine, it is equivalent to the cp1252 encoding (almost
equivalent latin-1). Since the 'filename' comes from a call to
_PyUnicode_AsString(tb->tb_frame->f_code->co_filename), it will be wrong
with any accented letter.

> Doesn't Python provide "high level" functions to open a file?
io.open()?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4068] Backport fix for issue 3312

[Gerhard Häring]

New submission from Gerhard Häring <[EMAIL PROTECTED]>:

This is a backport of Georg Brandl's fix for issue #3312.

--
assignee: ghaering
files: 253_backport_fix_issue3312.diff
keywords: patch, patch
messages: 74454
nosy: ghaering
priority: normal
severity: normal
status: open
title: Backport fix for issue 3312
type: crash
versions: Python 2.5.3
Added file: http://bugs.python.org/file11731/253_backport_fix_issue3312.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4067] ast.fix_missing_locations() breaks if node doesn't have "_attributes" variable

[Marcin Bachry]

New submission from Marcin Bachry <[EMAIL PROTECTED]>:

ast.fix_missing_locations() fails if any node is missing "_attributes"
instance variable - but it's the case of some fundamental nodes like
"alias" or "identifier".  When I run simple test:

  import ast
  with open(__file__) as fp:
  tree = ast.parse(fp.read())
  ast.fix_missing_locations(tree)

I get:

  $ python2.6 /tmp/test.py 
  Traceback (most recent call last):
File "/tmp/test.py", line 5, in 
  ast.fix_missing_locations(tree)
File "/usr/local/lib/python2.6/ast.py", line 133, in
fix_missing_locations
  _fix(node, 1, 0)
File "/usr/local/lib/python2.6/ast.py", line 132, in _fix
  _fix(child, lineno, col_offset)
File "/usr/local/lib/python2.6/ast.py", line 132, in _fix
  _fix(child, lineno, col_offset)
File "/usr/local/lib/python2.6/ast.py", line 121, in _fix
  if 'lineno' in node._attributes:
  AttributeError: 'alias' object has no attribute '_attributes'

--
components: Library (Lib)
files: ast.diff
keywords: patch
messages: 74453
nosy: marcin.bachry
severity: normal
status: open
title: ast.fix_missing_locations() breaks if node doesn't have "_attributes" 
variable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11730/ast.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4066] smtplib SMTP_SSL._get_socket doesn't return a value

[Marcin Bachry]

New submission from Marcin Bachry <[EMAIL PROTECTED]>:

SMTP.connect method expects _get_socket() method to return socket object:

  self.sock = self._get_socket(host, port, self.timeout)

but overriden _get_socket() method in SMTP_SSL class doesnt' have return
statement (it sets self.sock instead).  Hence I get
SMTPServerDisconnected exception when I try to send mail over ssl.

The same seems to apply to LMTP class.

--
components: Library (Lib)
files: smtplib.diff
keywords: patch
messages: 74452
nosy: marcin.bachry
severity: normal
status: open
title: smtplib SMTP_SSL._get_socket doesn't return a value
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11729/smtplib.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4035] Support bytes for os.exec*()

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

The patch is incomplete. It allows bytes for the arguments but not for 
the environment variables: posix_execve() in Modules/posixmodule.c 
uses:
 PyArg_Parse(key "s", &k)
 PyArg_Parse(val "s", &v)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Le Tuesday 07 October 2008 15:06:01 Amaury Forgeot d'Arc, vous avez écrit :
> - The two calls to open() are missing the O_BINARY flag, necessary on
> Windows to avoid newline translation. This may be important for some
> codecs.

Oops, I always forget Windows specific options :-/

> - the GIL should be released around calls to open(); searching the whole
> sys.path can be long.

Ok, O_BINARY and GIL fixed.

I just realized that sys.path is considered as a bytes string (PyBytes_Check) 
whereas Python3 uses an unicode string!

['', '/home/haypo/prog/python-ptrace', (...)]
>>> sys.path.append(b'bytes'); sys.path
['', '/home/haypo/prog/python-ptrace', '(...)', b'bytes']

Oops, so it's possible to mix strings and bytes. But the normal case is a list 
of unicode strings. Another fix is needed :-/

I don't know how to get into "if (fd < 0)" (code using sys.path). Any clue?

> Besides this, the "char* filename" is relevant only on utf8-encoded
> filesystems, and will not work on windows with non-ascii filenames. But
> this is another issue.

I don't know the Windows API enough to answer.

Doesn't Python provide "high level" functions to open a file?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4035] Support bytes for os.exec*()

[Martin v. Löwis]

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

Can you come up with a test case?

Also, it would probably be good to document what parameters can have
what datatypes in the exec family of functions.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

[Martin v. Löwis]

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

I agree with Trent that this is a bug, and I agree with the second patch
(pymacconfig.h.patch2).

Mark-Andre, sys.byteorder is not affected because detects the byte order
at run-time, not at compile-time. Likewise, in the struct module,
several code paths rely on dynamic determination of the endianness, such
as _PyLong_FromByteArray, the float packing, and the whichtable function.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4004] missing newline in "Could not convert argument %s to string" error message

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

@amaury.forgeotdarc: Done for "out of memory".

@loewis: Oops, it's an error. I removed the YY.

So here is a new patch.

Added file: http://bugs.python.org/file11728/argv_error_newline-2.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4004] missing newline in "Could not convert argument %s to string" error message

[Martin v. Löwis]

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

What's the purpose of the additional YY substring?

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3740] PEP 3121 --- module state is not nul-initalized as claimed in the PEP

[Martin v. Löwis]

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

Thanks! Committed as r66831

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4004] missing newline in "Could not convert argument %s to string" error message

[Amaury Forgeot d'Arc]

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

The patch is good, and consistent with all usages of fprintf(stderr) in
pythonrun.c, for example.

Please also add \n to
fprintf(stderr, "out of memory");
in both python.c and frozenmain.c

--
nosy: +amaury.forgeotdarc
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[Amaury Forgeot d'Arc]

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

The patch goes in the good direction, here are some remarks:

- The two calls to open() are missing the O_BINARY flag, necessary on
Windows to avoid newline translation. This may be important for some codecs.

- the GIL should be released around calls to open(); searching the whole
sys.path can be long.

Besides this, the "char* filename" is relevant only on utf8-encoded
filesystems, and will not work on windows with non-ascii filenames. But
this is another issue.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC

[Ronald Oussoren]

Ronald Oussoren <[EMAIL PROTECTED]> added the comment:

Annoyingly enough my patch isn't good enough, it turns out that ctypes 
has introduced a SIZEOF__BOOL definition in configure.in and that needs 
special caseing as well.

pymacconfig.h.patch2 fixes that issue as well. Do you have access to a 
PPC G5 system? I've determined the correct value of SIZEOF__BOOL for 
that platform by reading the assembly code for a small test program and 
hence am not 100% sure that sizeof(_Bool) actually is 1 on that 
architecture.

One other annoying issue cropped up: regrtest.py consistently hangs in 
test_signal (with 100% CPU usage) when I run it in rossetta (PPC 
emulator). I'll test this on an actual PPC machine as well, this might 
well be an issue with the PPC emulator.

Added file: http://bugs.python.org/file11727/pymacconfig.h.patch2

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

[Amaury Forgeot d'Arc]

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

> The line is not displayed (why? no idea)
Well, it's difficult to re-open ...

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4017] IDLE 2.6 broken on OSX (Leopard)

[Nat]

Nat <[EMAIL PROTECTED]> added the comment:

I asked a slightly different question (related to tkinter in general on
OS 10.4.11), but the symptoms were remarkably similar - perhaps the
solution is as well?

http://groups.google.com/group/comp.lang.python/browse_thread/thread/1114b05318a5507e/a7c269e62b4f0434#a7c269e62b4f0434

Worth a try?

--
nosy: +njw23

___
Python tracker <[EMAIL PROTECTED]>

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