[issue4072] build_py support for lib2to3 is stale

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 <[EM

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

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 w

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

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. Th

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

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 PROTECTE

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

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 ~ ... 10

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

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

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

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 chara

[issue3994] import fixer misses some symbols

Nick Edds <[EMAIL PROTECTED]> added the comment: I'll look in to it. Just give me a couple of days. ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

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 strin

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

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

[issue4072] build_py support for lib2to3 is stale

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 li

[issue4036] Support bytes for subprocess.Popen()

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]>

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

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()? -- n

[issue4036] Support bytes for subprocess.Popen()

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11696/os_exec_bytes.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11695/os_exec_bytes.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

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

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_exe

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

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()

[issue3677] importing from UNC roots doesn't work

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 <[

[issue3677] importing from UNC roots doesn't work

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]> ___ _

[issue3677] importing from UNC roots doesn't work

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]> ___ ___

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11732/traceback_unicode-3.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11633/traceback_unicode-2.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11612/traceback_unicode.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3677] importing from UNC roots doesn't work

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

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

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 fi

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

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 <[EM

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11738/tokenizer-coding-4.patch ___ Python tracker <[EMAIL PROTECTED]> ___

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11737/traceback_unicode-4.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11609/test_traceback-gbk.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11717/tokenizer-coding-3.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11625/tokenizer-coding-2.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

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 onl

[issue3677] importing from UNC roots doesn't work

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Ah, of cource, please change path to fit you environment. > test prog ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3677] importing from UNC roots doesn't work

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)); } i

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

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]> __

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

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

[issue4070] python tests failure if builddir <> sourcedir

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

[issue3677] importing from UNC roots doesn't work

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

[issue3677] importing from UNC roots doesn't work

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 d

[issue3367] Uninitialized value read in parsetok.c

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]> ___ _

[issue3367] Uninitialized value read in parsetok.c

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]>

[issue3994] import fixer misses some symbols

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- nosy: +nedds ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailin

[issue3873] Unpickling is really slow

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

[issue3448] Multi-process 2to3

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]> ___

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

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Committed as r66838. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue4069] set.remove raises confusing KeyError

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 ___ Pyth

[issue1597850] Cross compiling patches for MINGW

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 t

[issue4051] use of TCHAR under win32

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

[issue4051] use of TCHAR under win32

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]>

[issue1597850] Cross compiling patches for MINGW

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

[issue3367] Uninitialized value read in parsetok.c

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

[issue3677] importing from UNC roots doesn't work

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:

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

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. O

[issue1597850] Cross compiling patches for MINGW

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 bin

[issue1597850] Cross compiling patches for MINGW

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 tra

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

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) { >p

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

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 univer

[issue1597850] Cross compiling patches for MINGW

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

[issue4068] Backport fix for issue 3312

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]>

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

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]>

[issue4065] _multiprocessing doesn't build on macosx 10.3

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]>

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

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 thes

[issue4017] IDLE 2.6 broken on OSX (Leopard)

Changes by Kent Johnson <[EMAIL PROTECTED]>: -- nosy: +kjohnson ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue4069] set.remove raises confusing KeyError

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]>

[issue2218] Enhanced hotshot profiler with high-resolution timer

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 t

[issue2218] Enhanced hotshot profiler with high-resolution timer

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.7 -Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue2281] Enhanced cPython profiler with high-resolution timer

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.7 -Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue3163] module struct support for ssize_t and size_t

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.7 -Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue3163] module struct support for ssize_t and size_t

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.5.3 -Python 2.7 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

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

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 fix

[issue2281] Enhanced cPython profiler with high-resolution timer

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.5.3 -Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue2218] Enhanced hotshot profiler with high-resolution timer

Changes by Jean Brouwers <[EMAIL PROTECTED]>: -- versions: +Python 2.5.3 -Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Pyth

[issue4069] set.remove raises confusing KeyError

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue4069] set.remove raises confusing KeyError

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 o

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

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_Dec

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

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]>

[issue4069] set.remove raises confusing KeyError

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 inf

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

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() macr

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

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 an

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

Changes by Daniel Stutzbach <[EMAIL PROTECTED]>: -- versions: +Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue1597850] Cross compiling patches for MINGW

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/libp

[issue1597850] Cross compiling patches for MINGW

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.

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

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 rig

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

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11732/traceback_unicode-3.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

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

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.a

[issue4068] Backport fix for issue 3312

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: Backp

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

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: tre

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

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

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

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) ___ Pyth

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

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 alway

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

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]>

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

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, sever

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

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 t

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

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: What's the purpose of the additional YY substring? -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Thanks! Committed as r66831 -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ __

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

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 resolu

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

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 release

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

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

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

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]> _

[issue4017] IDLE 2.6 broken on OSX (Leopard)

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/a7c269

  1   2   >