[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

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

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

[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

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

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

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

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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

<    1   2