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

[Amaury Forgeot d'Arc]

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)

What is its "(Default)" value?
Is there an additional entry named "PATH"?

(I presume that (Default)=C:\Python30\Python.exe, and PATH=C:\Python25\)

___
Python tracker <[EMAIL PROTECTED]>

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

[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] os.getenv('PATH') return different result 
between 2.5 and 3.0rc3> To: [EMAIL PROTECTED]> From: [EMAIL PROTECTED]> Date: 
Tue, 25 Nov 2008 08:24:21 +> > > 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)> > What is its "(Default)" value?> Is there an additional entry 
named "PATH"?> > (I presume that (Default)=C:\Python30\Python.exe, and 
PATH=C:\Python25\)> > ___> Python tracker 
<[EMAIL PROTECTED]>> > 
___
_
MSN资讯快递，帮助你第一时间了解最新资讯！
http://im.live.cn/newsexpress

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

___
Python tracker <[EMAIL PROTECTED]>

___


.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}



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] os.getenv('PATH') 
return different result between 2.5 and 3.0rc3> To: [EMAIL 
PROTECTED]> From: [EMAIL PROTECTED]> Date: Tue, 25 Nov 2008 
08:24:21 +> > > 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)> > What is its "(Default)" value?> 
Is there an additional entry named "PATH"?> > (I presume that 
(Default)=C:\Python30\Python.exe, and PATH=C:\Python25\)> > 
___> Python tracker <[EMAIL 
PROTECTED]>> ;> 
___使用新一代 
Windows Live Messenger 轻松交流和共享！ 立刻下载！
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Barnes]

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: Unicode
messages: 76404
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 encoding of slash (character 47) is incorrect
type: behavior
versions: 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

[issue4426] UTF7 decoding is far too strict

[Nick Barnes]

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 can legitimately appear in
UTF-7-encoded text, and should be decoded (as themselves).  As it is,
the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
than that encoded by Python's own UTF-7 encoder.

Looking at the source of unicodeobject.c, the call to the SPECIAL macro
on line 1009 has hardcoded second and third arguments of zero.  Maybe
changing the second argument to 1 would fix this.  Maybe.

--
components: Unicode
messages: 76405
nosy: Nick Barnes
severity: normal
status: open
title: UTF7 decoding is far too strict
type: behavior
versions: 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

[issue4336] Fix performance issues in xmlrpclib

[Kristján Valur Jónsson]

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 simplifies any code wishing to send more data.
3) The old HTTP class needs no changes anymore.
4) I've fixed the test_xmlrpc.py test case to run all the tests on 
windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer 
valid.
5) concatenating the result from endheaders() with the request body is 
valid, in xmlrpclib, because the assumption has already been made in 
send_content() that request_body is a string (str(len(request_body)).  
However, in httplib's request() method, we now special case this.  I 
don't want to complicate the code for what appears to be a rare case.

I chose not to mess with xmlrpclib and make it continue to use the old 
HTTP class in order to minimise the extent of this patch.  A simple and 
clear performance patch has in my experience a much greater chance of 
finding its way into the codebase than a more extensive rewrite :)

You may have concerns regarding point 3 above, and I am open to 
suggestions.

Now, what remains is the question of the read buffering for the socket 
fileobject.  Do you think that it is feasible to simply change the 
default read buffering for fileobjects to use buffering for readline() 
same as they do for read()?  Then we wouldn't need the second half of 
this patch and we could make a separate "socket" performance patch.

Added file: http://bugs.python.org/file12127/xmlrpc.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4336] Fix performance issues in xmlrpclib

[Kristján Valur Jónsson]

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

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

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

[Thomas Heller]

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, Python 3.1
Added file: http://bugs.python.org/file12128/doc.patch

___
Python tracker <[EMAIL PROTECTED]>

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

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

[David M. Beazley]

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 attempt is made to strictly limit the internal 
buffer size to max_buffer_size.
   
In BuffererWriter.write(), one of the first operations is 

 self._write_buf.extend(b)

which simply extends the buffer by the full data being written.  If b 
happens to be a large string (e.g., megabytes or even the entire 
contents of a big file), then the internal I/O buffer makes a complete 
copy of the data, effectively doubling the memory requirements for 
carrying out the write operation.

I suppose most programmers might not notice given that everyone has 
gigabytes of RAM these days, but you certainly don't see this kind of 
buffering behavior in the operating system kernel or in the C library.

Some patch suggestions (details left to the maintainers of this module):

1. Don't extend self._write_buf by more than the max_buffer_size.

 fragment = b[:self.max_buffer_size - len(self._write_buf)]
 self._write_buf.extend(fragment)

2. For large blocking writes, simply carry out the remaining I/O 
   operations in the write() method instead of in the _flush_locked()
   method.   Try to use the original input data b as the data
   source instead of making copies of it.  And if you have to copy
   the data, don't do it all at once.

--
components: Library (Lib)
messages: 76408
nosy: beazley
severity: normal
status: open
title: io.BufferedWriter does not observe buffer size limits
type: resource usage
versions: Python 2.6, Python 2.7, 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

[issue4426] UTF7 decoding is far too strict

[STINNER Victor]

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

___
Python tracker <[EMAIL PROTECTED]>

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

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

[STINNER Victor]

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

Related issue: #4426

--
nosy: +haypo

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Thomas Heller]

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 "", line 1, in 
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 5-7:
invalid data
[46742 refs]
>>>

--
assignee: theller
components: ctypes
messages: 76411
nosy: theller
priority: release blocker
severity: normal
status: open
title: ctypes.FormatError raises when the string to return contains non-ascii 
characters
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

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

[Thomas Heller]

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

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Thomas Heller]

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]
>>> FormatError(1)
'Unzulässige Funktion.'
[46698 refs]
>>>

Added file: http://bugs.python.org/file12130/ctypes-better.patch

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Thomas Heller]

Changes by Thomas Heller <[EMAIL PROTECTED]>:


--
keywords: +needs review

___
Python tracker <[EMAIL PROTECTED]>

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

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

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


--
nosy: +haypo
stage:  -> patch review

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4426] UTF7 decoding is far too strict

[Nick Barnes]

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 c in set_d)
all((c.decode('utf7') == c) for c in set_d)
all((c.decode('utf7') == c) for c in set_o)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4426] UTF7 decoding is far too strict

[Marc-Andre Lemburg]

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
> exception for characters in "Set O" (optional direct characters), such
> as < = > [ ] @ etc.  These characters can legitimately appear in
> UTF-7-encoded text, and should be decoded (as themselves).  As it is,
> the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
> than that encoded by Python's own UTF-7 encoder.

Thanks for noticing this. Apparently, the UTF-7 codec is not used
a lot by Python users, since it's been like this for years.

The tests we have do check round-trip safety, but not the special
characteristics of the UTF-7 codec.

Also note that the code for the codec was contributed and is, AFAIK,
not maintained by any of the Python developers.

--
nosy: +lemburg

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Akira Kitada]

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
other uses. (I'm not sure)
I'll look into the code more and if it seems being safe to rename it,
I'll update the patch and resubmit it.

--
components: +2to3 (2.x to 3.0 conversion tool), None

___
Python tracker <[EMAIL PROTECTED]>

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

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

[sil]

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 "", line 1, in 
  File "/usr/lib/python2.5/_strptime.py", line 311, in strptime
format_regex = _TimeRE_cache.compile(format)
  File "/usr/lib/python2.5/_strptime.py", line 267, in compile
return re_compile(self.pattern(format), IGNORECASE)
  File "/usr/lib/python2.5/re.py", line 188, in compile
return _compile(pattern, flags)
  File "/usr/lib/python2.5/re.py", line 241, in _compile
raise error, v # invalid expression
sre_constants.error: redefinition of group name 'd' as group 4; was group 1

If a format directive is repeated in time.strptime's format string, it
throws an error and should not do so. Subversion, for example, repeats
date parts in its svn log output ("2008-09-26 16:20:59 +0100 (Fri, 26
Sep 2008)"), which repeats both %d (day) and %y (year).

--
messages: 76417
nosy: sil
severity: normal
status: open
title: time.strptime does not allow same format directive twice
type: behavior
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

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

[Matthew Barnett]

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? The Pythonic thing to do is raise an exception.

(I suppose an alternative would be to raise an exception only if they
give different results.)

--
nosy: +mrabarnett

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4426] UTF7 decoding is far too strict

[Nick Barnes]

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?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3799] Byte/string inconsistencies between different dbm modules

[Brett Cannon]

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

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

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

[Brett Cannon]

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 groups with the same name, leading
to a conflict.

About the only solution I can think of that doesn't require some massive
rewrite is to drop named group usage from time.strptime() and move to
positional groups by keeping track of the order of the formats and
zipping the format order and results together or something.

But I don't plan on doing that personally as that would require writing
a parser for format strings as well. But if someone manages to get it to
work I would be willing to review the patch.

Setting the priority to low as this is easy to work around since you
just use one set of date information instead of two which is redundant.

--
nosy: +brett.cannon
priority:  -> low
stage:  -> needs patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4373] Reference leaks in Python 3.0rc3

[Brett Cannon]

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

Amaury's patch for pickle looks fine to me.

--
nosy: +brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4426] UTF7 decoding is far too strict

[STINNER Victor]

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

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

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

[David Schnur]

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 crypto.pyd.  The problem was that link.exe 
was not creating the manifest.

The reason why is that distutils only passes link.exe the 
/MANIFESTFILE:filename parameter.  This tells it where to output the 
manifest, but not to actually create the manifest (see 
http://msdn.microsoft.com/en-us/library/fft52235(VS.80).aspx).  You'd 
think link could figure out that, if you use /MANIFESTFILE, you want a 
manifest, but I guess not ;)

My solution was to add this line to distutils/msvc9compiler.py:

ld_args.append('/MANIFEST')

Right beneath the existing line:

ld_args.append('/MANIFESTFILE:' + temp_manifest)

Hope that helps

--
components: Distutils
messages: 76424
nosy: dschnur
severity: normal
status: open
title: Distutils MSVC doesn't create manifest file (with fix)
type: behavior
versions: 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

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

[August Mueller]

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 = smtplib.SMTP('localhost')
smtp.sendmail('[EMAIL PROTECTED]', '[EMAIL PROTECTED]', "Subject: This is your 
mail\n" + msg.as_string())
smtp.quit()

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Amaury Forgeot d'Arc]

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

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Amaury Forgeot d'Arc]

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 of python did you install, the "official" one from 
www.python.org, or another one, from ActiveState for example?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4373] Reference leaks in Python 3.0rc3

[Amaury Forgeot d'Arc]

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

Applied pickle-leak2.patch in 67381.

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Marc-Andre Lemburg]

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, 
> the mt.exe step failed because it could not find the manifest file that 
> it was attempting to embed in crypto.pyd.  The problem was that link.exe 
> was not creating the manifest.
> 
> The reason why is that distutils only passes link.exe the 
> /MANIFESTFILE:filename parameter.  This tells it where to output the 
> manifest, but not to actually create the manifest (see 
> http://msdn.microsoft.com/en-us/library/fft52235(VS.80).aspx).  You'd 
> think link could figure out that, if you use /MANIFESTFILE, you want a 
> manifest, but I guess not ;)
> 
> My solution was to add this line to distutils/msvc9compiler.py:
> 
> ld_args.append('/MANIFEST')
> 
> Right beneath the existing line:
> 
> ld_args.append('/MANIFESTFILE:' + temp_manifest)
> 
> Hope that helps

I'm not sure whether that's necessary. We are building pyOpenSSL
just fine against stock Python 2.6.0 in our distribution:

http://www.egenix.com/products/python/pyOpenSSL/

and even though the command line does not include the /MANIFEST
switch, the linker does builds the .manifest file just fine.

OTOH, it probably doesn't hurt adding the switch :-)

--
nosy: +lemburg

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Marc-Andre Lemburg]

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 tracker <[EMAIL PROTECTED]>

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

[issue4373] Reference leaks in Python 3.0rc3

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Second fix applied in r67382

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

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

[David Schnur]

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 unnecessary when compiling static, it
isn't created unless you specify /MANIFEST.

So I suppose the issue is that distutils is trying to embed the manifest
in cases where it may legitimately not exist.  Since /MT is not the
default (I had to make that change explicitly), this is probably not a bug.

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Amaury Forgeot d'Arc]

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

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

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

[Martin v. Löwis]

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

Closing it as "invalid" then.

--
resolution:  -> invalid
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

[issue4423] 2to3 replaces "arbitrary" variables

[Benjamin Peterson]

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

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Benjamin Peterson]

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

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

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

[Benjamin Peterson]

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

[issue4423] 2to3 replaces "arbitrary" variables

[Martin v. Löwis]

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 to actually run the fixer. Instead, I need
to write

from lib2to3.fixes import fix_imports
del fix_imports.MAPPING['commands']
fix_imports.FixImports.PATTERN="|".join(fix_imports.build_pattern())

> Anyway, I fixed the replacement problem in r67386.

Thanks! It still transforms

def g():
import commands
def f():
commands = foo()
commands.sort()

but I think this is ok; people just shouldn't write such code in the
first place (and the resulting code does work correctly - just with
a strangely-renamed local variable).

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Roumen Petrov]

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 PY_FORMAT_SIZE_T isn't defined 
then __attribute__(XXX) will be ignored always irrespective of content, 
i.e. XXX.

> 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
> other uses. (I'm not sure)
> I'll look into the code more and if it seems being safe to rename it,
> I'll update the patch and resubmit it.

The current python code use Py_GCC_ATTRIBUTE only for 
'format(printf(...)) ' attribute. The patch will prevent python to use 
this macro in future for other attributer.

Also I'm not sure that I would like warning to be hidden.
As example I know that GCC(mingw) 3.5.x don't support %z and I prefer to 
see those warnings instead to hide them.

Roumen

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
components:  -2to3 (2.x to 3.0 conversion tool)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4423] 2to3 replaces "arbitrary" variables

[Benjamin Peterson]

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 code does not work:
>
>from lib2to3.fixes import fix_imports
>del fix_imports.MAPPING['commands']
>
> when followed by an attempt to actually run the fixer. Instead, I need
> to write
>
>from lib2to3.fixes import fix_imports
>del fix_imports.MAPPING['commands']
>fix_imports.FixImports.PATTERN="|".join(fix_imports.build_pattern())

This is true of many fixers. What is the use case?

>
>> Anyway, I fixed the replacement problem in r67386.
>
> Thanks! It still transforms
>
> def g():
>import commands
> def f():
>commands = foo()
>commands.sort()
>
> but I think this is ok; people just shouldn't write such code in the
> first place (and the resulting code does work correctly - just with
> a strangely-renamed local variable).

This also won't work:

def f():
commands.call() # This fails to be fixed.

import commands

Is that reasonable also?

Scoping isn't something that 2to3 does well, and we'd probably have to
add a whole symtable analyzer to fix a few obscure bugs like above.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4329] base64 does not properly handle unicode strings

[Michael Becker]

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 this statement is not true when strings are passed
to any method that convert them to bytes. Maybe this was documented in
the 2.6 documentation somewhere and I simply missed it. Should I have
run the 2to3 converter on my 2.5 code prior to updating to 2.6? Please
let me know the new issue number so I can track the progress.
Thanks!

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Akira Kitada]

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.

As for renaming Py_GCC_ATTRIBUTE,
yes this would prevent python to use this macro in future for
other attributer, but after all python does not need it for now.
So I think that's not a problem.
Someone will write it when he/she need it.

--
components:  -None

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Akira Kitada]

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

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

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

[LZ]

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

--
components: IDLE
messages: 76443
nosy: LZ
severity: normal
status: open
title: IDLE.app (Mac) File Menu MIssing Options
type: behavior
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

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

___


.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}



My python2.5 is from ActiveState, and python3.0 is the official.
> Subject: [issue4402] os.getenv('PATH') return different result 
between 2.5 and 3.0rc3> To: [EMAIL PROTECTED]> From: [EMAIL 
PROTECTED]> Date: Tue, 25 Nov 2008 20:59:15 +> > 
> 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 of python did you install, the "official" one from > 
www.python.org, or another one, from ActiveState for example?> > 
___> Python tracker <[EMAIL 
PROTECTED]>> ;> 
___更多热辣资讯尽在新版MSN首页！ 立刻访问！
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4279] Module 'parser' fails to build

[Yaakov (Cygwin Ports)]

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.

--
nosy: +yselkowitz

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

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: +benjamin.peterson
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

[issue4423] 2to3 replaces "arbitrary" variables

[Martin v. Löwis]

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

> Is that reasonable also?

Sure! People will accept that they have to reorganize the source
before 2to3 can work correctly. More precisely, if they follow the
"convert once, cut the bridges" approach, they can just manually
unfix the few places that 2to3 got wrong. If they follow the
"single source" approach, they will accept that they have to
reformulate.

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Martin v. Löwis]

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

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

[issue4279] Module 'parser' fails to build

[Martin v. Löwis]

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

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