[issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Can you please check with the regedit application whether you have an entry for the key: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Windows\CURRENTVERSION\App Paths\python.exe (this key is used when you type python in the Run dialog box)

[issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3

赵现刚 [EMAIL PROTECTED] added the comment: YES! It is exactly what you assumed. The default value is C:\Python30\Python.exe, and there is also another entry path,its value is C:\Python25\. Does that mean I should not start python from the Run dialog box? 非常感谢您的回复！ Subject: [issue4402]

[issue4425] UTF7 encoding of slash (character 47) is incorrect

New submission from Nick Barnes [EMAIL PROTECTED]: '/'.encode('utf7') returns '+AC8-'. It should return '/'. See RFC 2152. '/'.decode('utf7') raises an exception (this is a special case of a general problem with UTF-7 decoding, which I will report as a separate bug). -- components:

[issue4426] UTF7 decoding is far too strict

New submission from Nick Barnes [EMAIL PROTECTED]: UTF-7 decoding raises an exception for any character not in the RFC2152 Set D (directly encoded characters). In particular, it raises an exception for characters in Set O (optional direct characters), such as = [ ] @ etc. These characters

[issue4336] Fix performance issues in xmlrpclib

Kristján Valur Jónsson [EMAIL PROTECTED] added the comment: I have addressed some issues mentioned: 1) I have retained the _send_output() method. 2) the endheaders() method now takes an optional argument, send_data that defaults to True. It also returns any unsent data as a string. This

[issue4336] Fix performance issues in xmlrpclib

Kristján Valur Jónsson [EMAIL PROTECTED] added the comment: Sorry, I meant : you may have concerns regarding point 2) above ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4336 ___

[issue4427] Docs for 'y' Py_BuildValue tag are wrong

Changes by Thomas Heller [EMAIL PROTECTED]: -- assignee: georg.brandl components: Documentation files: doc.patch keywords: patch, patch nosy: georg.brandl, theller severity: normal stage: patch review status: open title: Docs for 'y' Py_BuildValue tag are wrong versions: Python 3.0,

[issue4428] io.BufferedWriter does not observe buffer size limits

New submission from David M. Beazley [EMAIL PROTECTED]: The Buffered I/O interface in the io module has the user specify buffer limits such as size and max_buffer_size. The first limit (size) is easy to understand as a buffering threshold at which writes will occur. However, no apparent

[issue4426] UTF7 decoding is far too strict

STINNER Victor [EMAIL PROTECTED] added the comment: Can you write some tests to help fixing this issue? Stupid example (I don't know UTF-8 encoding): all((byte.encode(utf-7) == byte) for byte in '=[]@') all((byte.decode(utf-7) == byte) for byte in '=[]@') -- nosy: +haypo

[issue4425] UTF7 encoding of slash (character 47) is incorrect

STINNER Victor [EMAIL PROTECTED] added the comment: Related issue: #4426 -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4425 ___ ___

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

New submission from Thomas Heller [EMAIL PROTECTED]: ctypes raises UnicodeDecodeError in german windows (it should print 'Unzulässige Funktion'): from ctypes import FormatError [46681 refs] FormatError(1) Traceback (most recent call last): File stdin, line 1, in module UnicodeDecodeError:

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

Thomas Heller [EMAIL PROTECTED] added the comment: The simple patch (ctypes-simple.patch) uses the 'y' format tag for PyBuild_Value to build a bytes object as error message. -- keywords: +patch Added file: http://bugs.python.org/file12129/ctypes-simple.patch

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

Thomas Heller [EMAIL PROTECTED] added the comment: The 'better' patch changes the internal FormatError function to return a wide string; so conversion from ascii to unicode by Python functions is not needed and it returns strings to the caller: from ctypes import FormatError [46681 refs]

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

Changes by Thomas Heller [EMAIL PROTECTED]: -- keywords: +needs review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4429 ___ ___ Python-bugs-list

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

Changes by STINNER Victor [EMAIL PROTECTED]: -- nosy: +haypo stage: - patch review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4429 ___ ___

[issue4426] UTF7 decoding is far too strict

Nick Barnes [EMAIL PROTECTED] added the comment: # Note, this test covers issues 4425 and 4426 # Direct encoded characters: set_d = ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'(),-./:? # Optional direct characters: set_o = '!#$%*;=@[]^_`{|}' all((c.encode('utf7') == c) for

[issue4426] UTF7 decoding is far too strict

Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-11-25 12:11, Nick Barnes wrote: New submission from Nick Barnes [EMAIL PROTECTED]: UTF-7 decoding raises an exception for any character not in the RFC2152 Set D (directly encoded characters). In particular, it raises an

[issue4370] warning: unknown conversion type character `z' in format

Akira Kitada [EMAIL PROTECTED] added the comment: Roumen, Thanks for the feedback! This patch disables __attribute__ when PY_FORMAT_SIZE_T isn't defined, not always. About the name of the macro, I think you are right. Py_GCC_FORMAT_ATTRIBUTE would be much better name if it is not used for

[issue4430] time.strptime does not allow same format directive twice

New submission from sil [EMAIL PROTECTED]: $ python -c import time; print time.strptime('25/11/2008 25/11/2008','%d/%m/%y %d/%m/%y') Traceback (most recent call last): File string, line 1, in module File /usr/lib/python2.5/_strptime.py, line 311, in strptime format_regex =

[issue4430] time.strptime does not allow same format directive twice

Matthew Barnett [EMAIL PROTECTED] added the comment: Subversion is formatting a string from a time (strftime), so a repeated placeholder is OK. You're trying to _parse_ a time from a string (strptime). If you're telling it that 2 different parts of the string are the date, what should it do?

[issue4426] UTF7 decoding is far too strict

Nick Barnes [EMAIL PROTECTED] added the comment: Well, I could submit a diff for unicodeobject.c, but I have never contributed to Python (or used this particular tracking system) before. Is there a standard form for contributing changes? Unified diff? ___

[issue3799] Byte/string inconsistencies between different dbm modules

Brett Cannon [EMAIL PROTECTED] added the comment: r67380 has the fix. Thanks for the review, Skip! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3799

[issue4430] time.strptime does not allow same format directive twice

Brett Cannon [EMAIL PROTECTED] added the comment: The reason this occurs is that in order to have a portable and sane implementation time.strptime() uses the re module to parse dates. The issue here is that by specifying the same format twice the re module is complaining that there are two named

[issue4373] Reference leaks in Python 3.0rc3

Brett Cannon [EMAIL PROTECTED] added the comment: Amaury's patch for pickle looks fine to me. -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4373 ___

[issue4426] UTF7 decoding is far too strict

STINNER Victor [EMAIL PROTECTED] added the comment: Is there a standard form for contributing changes? Unified diff? Attach a patch file (unified diff, yes). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4426

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

New submission from David Schnur [EMAIL PROTECTED]: This is my first time submitting an issue; sorry if I am doing this wrong. While attempting to build/install PyOpenSSL on Windows / MSVC, the mt.exe step failed because it could not find the manifest file that it was attempting to embed in

[issue4403] regression from 2.6: smtplib.py requiring ascii for sending messages

August Mueller [EMAIL PROTECTED] added the comment: For completeness, if anyone runs across this in the future, the following seems to work for sending utf-8 mail in python 3: import smtplib import email.mime.text msg = email.mime.text.MIMEText(Ümlaut, _charset=UTF-8) smtp =

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Since issue4120, the compilation tools precisely chose to *not* embed manifests in .pyd extensions. This probably means that the mt.exe step should be skipped by distutils. -- assignee: - loewis nosy: +amaury.forgeotdarc,

[issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Does that mean I should not start python from the Run dialog box? Not at all. Just remove the PATH entry and the inconsistency will disappear. I just wonder how to explain the presence of this additional variable. Which distribution

[issue4373] Reference leaks in Python 3.0rc3

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Applied pickle-leak2.patch in 67381. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4373 ___ ___

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: On 2008-11-25 21:16, David Schnur wrote: New submission from David Schnur [EMAIL PROTECTED]: This is my first time submitting an issue; sorry if I am doing this wrong. While attempting to build/install PyOpenSSL on Windows / MSVC,

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: This is why we don't see the problem: http://msdn.microsoft.com/en-us/library/f2c0w594.aspx The default is /MANIFEST. So it appears that you must have disabled this default somehow. ___ Python

[issue4373] Reference leaks in Python 3.0rc3

Christian Heimes [EMAIL PROTECTED] added the comment: Second fix applied in r67382 -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4373 ___

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

David Schnur [EMAIL PROTECTED] added the comment: I looked at this some more (I'm not super familiar with the use of manifests) and I think I figured it out. For somewhat complicated reasons, I'm compiling with /MT rather than /MD. Although link normally produces a manifest, since it's

[issue4429] ctypes.FormatError raises when the string to return contains non-ascii characters

Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The better patch is good to me. It is indeed better to always use the Wide Win32 API. -- keywords: -needs review nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED]

[issue4431] Distutils MSVC doesn't create manifest file (with fix)

Martin v. Löwis [EMAIL PROTECTED] added the comment: Closing it as invalid then. -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4431 ___

[issue4423] 2to3 replaces arbitrary variables

Benjamin Peterson [EMAIL PROTECTED] added the comment: I'm not sure what you mean about MAPPING being compiled in. It is regenerated every time 2to3 is run. Anyway, I fixed the replacement problem in r67386. -- resolution: - fixed status: open - closed

[issue4421] Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL

Benjamin Peterson [EMAIL PROTECTED] added the comment: Closing in favor of the closely related #4422. -- nosy: +benjamin.peterson resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4421

[issue4422] Failed to check 3rd Param of PyArena_AddPyObject() to ensure it isn't NULL

Benjamin Peterson [EMAIL PROTECTED] added the comment: I'm not what sure you mean, by the third param since PyArena_AddPyObject only takes two arguments. However, in r67373, I fixed a bunch of cases where NEW_INDENTIFER was used without checking for NULL. -- nosy: +benjamin.peterson

[issue4423] 2to3 replaces arbitrary variables

Martin v. Löwis [EMAIL PROTECTED] added the comment: I'm not sure what you mean about MAPPING being compiled in. It is regenerated every time 2to3 is run. This code does not work: from lib2to3.fixes import fix_imports del fix_imports.MAPPING['commands'] when followed by an attempt

[issue4370] warning: unknown conversion type character `z' in format

Roumen Petrov [EMAIL PROTECTED] added the comment: Akira Kitada wrote: Akira Kitada [EMAIL PROTECTED] added the comment: Roumen, Thanks for the feedback! This patch disables __attribute__ when PY_FORMAT_SIZE_T isn't defined, not always. I would like to clarify. After patch if

[issue4370] warning: unknown conversion type character `z' in format

Changes by Benjamin Peterson [EMAIL PROTECTED]: -- components: -2to3 (2.x to 3.0 conversion tool) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4370 ___

[issue4423] 2to3 replaces arbitrary variables

Benjamin Peterson [EMAIL PROTECTED] added the comment: On Tue, Nov 25, 2008 at 5:10 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: Martin v. Löwis [EMAIL PROTECTED] added the comment: I'm not sure what you mean about MAPPING being compiled in. It is regenerated every time 2to3 is run. This

[issue4329] base64 does not properly handle unicode strings

Michael Becker [EMAIL PROTECTED] added the comment: Terry, Thanks for your response. My main concern was that the behavior changed when updating from 2.5 to 2.6. The new behavior was not intuitive. Also 2.6, I thought, was supposed to be backward compatible. Based on this issue, I would assume

[issue4370] warning: unknown conversion type character `z' in format

Akira Kitada [EMAIL PROTECTED] added the comment: Thank you again for the feedback. I think those warnings are not so useful, or even misleading, when we know they are handled appropriately. with these warnings hidden, it would get much more easy to read build log and find real warnings there.

[issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD

Changes by Akira Kitada [EMAIL PROTECTED]: -- versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4366 ___

[issue4432] IDLE.app (Mac) File Menu MIssing Options

New submission from LZ [EMAIL PROTECTED]: Just compiled and installed 3.0rc3 configured with --enable-framework I can start IDLE.app in /Applications/Python 3.0, but the only option in that application's File menu is a list of recent files. What about Open? What about Save? etc --

[issue4402] os.getenv('PATH') return different result between 2.5 and 3.0rc3

赵现刚 [EMAIL PROTECTED] added the comment: _ MSN热搜榜，每天最In的信息资讯和热点排行让您一览无余！ http://top.msn.com.cn Added file: http://bugs.python.org/file12131/unnamed ___ Python tracker [EMAIL PROTECTED]

[issue4279] Module 'parser' fails to build

Yaakov (Cygwin Ports) [EMAIL PROTECTED] added the comment: I can confirm this problem in 3.0rc3 on Cygwin. If I could get some direction from the Python devs on which method would be preferred (accessor function vs. exposing data structure), I would be happy to provide a patch. --

[issue3994] import fixer misses some symbols

Benjamin Peterson [EMAIL PROTECTED] added the comment: I do have performance problems if I remove the match() override, but I found that special casing usage replacements fixes the bug while keeping speed. Done in r67390. Nick, thanks for the debugging and the patch! -- nosy:

[issue4423] 2to3 replaces arbitrary variables

Martin v. Löwis [EMAIL PROTECTED] added the comment: This is true of many fixers. What is the use case? In this case, I wanted to work around the fixer working incorrectly for commands, but still have it continue to work for all the other modules it fixes. The context is the setup.py script of

[issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD

Martin v. Löwis [EMAIL PROTECTED] added the comment: 2.5.3 is out of scope for this issue (and thus, the whole of 2.5). There is no workable patch, yet, and 2.5.3 is just two weeks ahead. -- versions: -Python 2.5.3 ___ Python tracker [EMAIL

[issue4279] Module 'parser' fails to build

Martin v. Löwis [EMAIL PROTECTED] added the comment: I think the parser module should call one of the existing functions. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4279 ___