[issue4393] Portability fixes in longobject.c

[Mark Dickinson]

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

This patch fixes 3 classes of bugs in Objects/longobject.c:

(1) declarations of a variable (usually a counter into the digits of
a PyLong) as int instead of Py_ssize_t.
(2) missing (twodigits) casts from multiplies and shifts.
(3) use of '<<' on negative values in _PyLong_AsByteArray.  This
may lead to undefined behaviour, according to the C standards.  (See C99, 
section 6.5.7, paragraph 4).

These bugs haven't manifested themselves in practice.  For (1), there's 
only a problem when dealing with huge integers (more than 2**31 digits).   
The bugs in (2) can only affect platform where the C 'int' type has fewer 
than 32 bits.  (3) could potentially conflict with future compiler 
optimizations, but doesn't seem to be a problem right now.

For these reasons I don't think these fixes should be backported to 2.5.3.

--
components: Interpreter Core
files: longobject_casts.patch
keywords: patch
messages: 76267
nosy: marketdickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Portability fixes in longobject.c
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12109/longobject_casts.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4389] Uninstaller Lacks an Icon

[Retro]

Retro <[EMAIL PROTECTED]> added the comment:

So are you willing to fix this issue?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

New submission from Tarek Ziadé <[EMAIL PROTECTED]>:

Right now you HAVE to store a clear text password in .pypirc.

But this should not be necessary since the "register" command does a
getpass.getpass call to get the password from the prompt and use it to
authenticate to pypi.

So what do we miss ? 

We miss a bit of persistency for the upload command to get that password
when register + upload have been called in the same command line, typically:

$ python setup.py register sdist upload

this patch does it, and adds a test for it.

I am wondering though if upload wouldn't be better not to depend on a 
previous call to register (basically by adding a getpass.getpass call
there too), but this can be a second patch.

--
components: Distutils
files: no_password.patch
keywords: patch
messages: 76268
nosy: tarek
severity: normal
status: open
title: make the storage of the password optional in .pypirc (using the prompt)
type: feature request
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12110/no_password.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Martin v. Löwis]

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

According to my tests, something is hosed with password saving in the
register command for 3.0 already: the saved password doesn't seem to be
used. Before this patch is considered, the other problem should be
resolved (but isn't yet reported to roundup, AFAICT).

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4395] Document auto __ne__ generation

[Terry J. Reedy]

New submission from Terry J. Reedy <[EMAIL PROTECTED]>:

3.0c3 doc (Basic customization) says
"There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected. "

In http://mail.python.org/pipermail/python-ideas/2008-October/002235.html
Guido says
"I should also note that part of George's proposal has already been
implemented: if you define __eq__, you get a complementary __ne__ for
free. However it doesn't work the other way around (defining __ne__
doesn't give you __eq__ for free), and there is no similar
relationship for the ordering operators."

And indeed, as Arnaud Delobelle posted on python-list
class A:
def __init__(self, x):
self.x = x
def __eq__(self, other):
return self.x == other.x

a, b, c = A(1), A(1), A(2)
print(a==b, b==c, c==a) # True, False, False
print(a!=b, b!=c, c!=a) # False, True, True

Suggested revision:
"There is one implied relationship among comparison operators: defining
__eq__ gives an automatic __ne__ (but not the other way).  There is no
similar relationship for the order comparisons.

--
assignee: georg.brandl
components: Documentation
messages: 76270
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Document auto __ne__ generation
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

[issue4396] parser module fails to validate "with" statements.

[David Binger]

New submission from David Binger <[EMAIL PROTECTED]>:

The parser module validates node trees when they are built from sequences.
The validator must, unfortunately, be updated every time there is a change
in the grammar.  The current validator fails to validate "with"
statements.  This bug probably exists in earlier versions of python
that support "with", but I haven't checked.

Here is a patch with a unit test for py3k.
Files involved: parsermodule.c, test_parser.py.

--
components: Library (Lib)
files: parsewith.diff
keywords: patch
messages: 76271
nosy: dbinger
severity: normal
status: open
title: parser module fails to validate "with" statements.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12111/parsewith.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4392] incorrect parameter name for collections.namedtuple

[Georg Brandl]

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

Fixed in r67355.

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

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

[Akira Kitada]

Akira Kitada <[EMAIL PROTECTED]> added the comment:

I looked into the code and found these warnings about 'z' were
not from printf family but PyString_FromFormat.
Apparently PyString_FromFormat handles the 'z' itself, without
delegating that to printf family.
Then why am I getting these warnings?
I could remove these by using PY_FORMAT_SIZE_T,
but it's not for them, according to http://bugs.python.org/issue3743
and the source code.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4382] test_dbm_dumb fails due to character encoding issue on Mac OS X

[Martina Oefelein]

Martina Oefelein <[EMAIL PROTECTED]> added the comment:

Yes, the patch fixes the issue for me.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4391] optparse: use proper gettext plurals forms

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
priority:  -> low

___
Python tracker <[EMAIL PROTECTED]>

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

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

[Martin v. Löwis]

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

I'd like to see this in 3.0. It will help people porting to 3.0 better.

--
assignee:  -> barry
nosy: +barry
priority:  -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4397] test_socket fails occassionaly in teardown: AssertionError: [Errno 57] Socket is not connected

[Martina Oefelein]

New submission from Martina Oefelein <[EMAIL PROTECTED]>:

test_socket fails randomly in about 1 of 50 iterations (MacOS X 10.5.5 
intel):

$ for ((;;)); do DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-
3.0rc3: ./python.exe -E -bb ./Lib/test/regrtest.py -l test_socket;done
test_socket
1 test OK.

...

test_socket
test test_socket failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/test/test_socket.py", 
line 121, in _tearDown
self.fail(msg)
AssertionError: [Errno 57] Socket is not connected

1 test failed:
test_socket
test_socket
1 test OK.

...

--
components: Library (Lib), Macintosh, Tests
messages: 76276
nosy: oefe
severity: normal
status: open
title: test_socket fails occassionaly in teardown: AssertionError: [Errno 57] 
Socket is not connected
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

[issue4398] erewer

[Derek Hval]

Changes by Derek Hval <[EMAIL PROTECTED]>:


--
files: aa.html
nosy: der74hva3
severity: normal
status: open
title: erewer
type: compile error
Added file: http://bugs.python.org/file12112/aa.html

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4399] "shard" appears where "shared" intended

[David W. Lambert]

New submission from David W. Lambert <[EMAIL PROTECTED]>:

http://docs.python.org/dev/3.0/library/ctypes.html

insert "e" into "shard".

Errors have dissimilar importance.  The manual is so good that this is 
the worst I can find today.

--
assignee: georg.brandl
components: Documentation
messages: 76277
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: "shard" appears where "shared" intended
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

[issue4399] "shard" appears where "shared" intended

[Georg Brandl]

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

Fixed in r67359, thanks!

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

[issue4398] erewer

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


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

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

[Amaury Forgeot d'Arc]

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

You receive these messages because PyString_FromFormat is declared with 
a special directive __attribute__(format(printf, 1, 2)).
Gcc then takes the format string as a regular printf format and 
validates it against the passed arguments.

You can safely ignore these warnings.
Maybe python should disable this __attribute__ for old compilers.

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

[issue3926] Idle doesn't obey the new improved warnings arguements

[Scott David Daniels]

Scott David Daniels <[EMAIL PROTECTED]> added the comment:

Attached parts.zip -- a zip of updates for Python 2.6 and Python 3.0
against the current source [zip has two 

For Python 2.6:
py26/diff_py26.txt  -- differ against python26-maint tree
py26/PyShell.py -- Replacement file for .../Lib/idlelib/PyShell.py
py26/run.py -- Replacement file for .../Lib/idlelib/run.py

For Python 3.0:
py30/py3k_diff.txt  -- differ against python3k tree
py30/PyShell.py -- Replacement file for .../Lib/idlelib/PyShell.py
py30/run.py -- Replacement file for .../Lib/idlelib/run.py

Added file: http://bugs.python.org/file12113/parts.zip

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


--
resolution:  -> wont fix
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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

can you provide me a scenario to reproduce it ? 

-> did you have a .pypirc already with no password, or no .pypirc, etc..

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2433] Merge audio modules

[STINNER Victor]

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

2.6 and 3.0rc3 are released. It's too late to change the standard 
library. So I prefer to close the bug. Reopen it if you want to work 
on that.

--
resolution:  -> out of date
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

[issue1755388] Problem with socket.gethostbyaddr() and KeyboardInterrupt

[STINNER Victor]

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

I don't know how to fix the bug and it looks like nobody cares about 
it. So I prefer to close it. Reopen it if you get the same error.

Added file: http://bugs.python.org/file12114/hostname.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1755388] Problem with socket.gethostbyaddr() and KeyboardInterrupt

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


--
resolution:  -> wont fix
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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Martin v. Löwis]

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

Here is what I did:
1. I started with no pypirc
2. I ran register, it asked me for username, password
3. I chose to save it, it created a .pypirc
4. I ran register again, it asked me again for username, password, even
though this was saved already.

Looking at the code, it seems the problem is that the pypirc has a
section pypirc that lists the server, but the code reading it wants a
section distutils.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

I could reproduce it under 2.6, 

the problem is located at distutils.config.DEFAULT_PYPIRC

the default structure is wrong there, I'll add a ticket with a patch
and a test right away

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4400] pypirc default is not at the right format

[Tarek Ziadé]

New submission from Tarek Ziadé <[EMAIL PROTECTED]>:

when generated the default pypirc format is wrong, this patch fixes it
(could be backported in 2.6)

--
components: Distutils
files: fix_pypirc_default.diff
keywords: patch
messages: 76286
nosy: tarek
severity: normal
status: open
title: pypirc default is not at the right format
versions: Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file12115/fix_pypirc_default.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4394] make the storage of the password optional in .pypirc (using the prompt)

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

Ok, I wrote a patch for the problem you mentioned in 

http://bugs.python.org/issue4400

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4194] default subprocess.Popen buffer size

[STINNER Victor]

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

About Python3, os.popen() is more than two times faster (0.20 sec vs 
0.50 sec) than subprocess.Popen()! It's amazing because popen() opens 
the standard output as unicode file whereas Popen() creates a binary 
file! Another funny thing: os.popen() calls subprocess.Popen() :-) The 
difference is just this instruction:
   stdout = io.TextIOWrapper(stdout)

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

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

[Benjamin Peterson]

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

Review:

1. Since RefactoringTool no longer writes backup files, write_file
doesn't need to be overridden.

2. Don't worry about **kwds on log_error. It's not used at the moment.

3. It might be nice to let users pick which fixers they do or do not
want. Using only needed fixers can boost performance immensely.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4401] os.extsep status? doc or os bug?

[Terry J. Reedy]

New submission from Terry J. Reedy <[EMAIL PROTECTED]>:

3.0c3 Manual (as with 2.x):
os.extsep 
The character which separates the base filename from the extension; for
example, the '.' in os.py. Also available via os.path.

3.0c3
>>> import os
>>> os.extsep
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'extsep'
>>> os.path.extsep
'.'

os.extsep apparently was present in 2.x
Mention of os.extsep was also present in 2.x docstring and removed in
3.0 docstring, so perhaps this was intentional, but it does not make
much sense, so I am provisionally marking this as a library bug.

--
components: Library (Lib)
messages: 76290
nosy: tjreedy
severity: normal
status: open
title: os.extsep status? doc or os bug?
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

[issue4194] default subprocess.Popen buffer size

[STINNER Victor]

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

Summary of unchanged Python (2.4 .. 2.7):
 * Mac: subprocess is 25 .. 50 times SLOWER than os.popen
 * Solaris : subprocess is 13 times SLOWER than os.popen
 * Windows XP : subprocess is 1.5 times FASTER than os.popen
 * Linux : (results are very close)

With a different buffer size:
 * Solaris : Popen(bufsize=-1) is FASTER than os.popen()
 * Mac : Popen(bufsize=1) and Popen(bufsize=8192) are a little bit 
slower than os.popen(), but much FASTER than Popen(bufsize=0)

Notes:
 - PyFile_SetBufSize(bufsize) does nothing if bufsize < 0: keep system 
default (buffer of BUFSIZE bytes)
 - On Ubuntu Gutsy, system default (BUFSIZ) is 8192 bytes

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4194] default subprocess.Popen buffer size

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

If anything for 2.6 lets just highlight this in the docs and mention
that bufsize needs to be set to non-zero for good performance on many
platforms such as Mac OS X and Solaris.

We can consider changing the default for 2.7/3.1.

3.x having poor performance is pretty much another issue entirely of its
own..

--
nosy: +gregory.p.smith

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2628] ftplib Persistent data connection

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

sure go for it, i haven't had time to look at the latest patch myself.

___
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

[赵现刚]

New submission from 赵现刚 <[EMAIL PROTECTED]>:

I am using windows xp(sp3),chinese simplified.I found that in os 
module,os.getenv('PATH') return different result between python 2.5 and 
3.0rc3.py2.5's result is the same as the path command's result.

path command's result:
PATH=C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py2.5's result:
C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...
py3.0rc3's result:
C:\Python25\;C:\Tcl\bin;C:\oracle\product\10.2.0\db_1
\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program 
Files\Borland\Delphi7\Bin;C:\Program Files\Borland\Delphi7
\Projects\Bpl\;C:\Program Files\Java\jdk1.7.0\bin;C:\Python25
\;C:\Python30\;...

you can see that python3.0 gets extra element "C:\Python25\",which is 
first. Is it a bug or something? thanks.

--
components: Library (Lib)
files: path_result.txt
messages: 76294
nosy: clive
severity: normal
status: open
title: os.getenv('PATH')   return different result between 2.5 and 3.0rc3
versions: Python 3.0
Added file: http://bugs.python.org/file12116/path_result.txt

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

New submission from August Mueller <[EMAIL PROTECTED]>:

smtplib requires that messages being sent be in ascii, and throws an exception 
otherwise.  
Python 2.6 doesn't require this.  Here's the diff where it was introduced:
http://svn.python.org/view/python/branches/py3k/Lib/smtplib.py?rev=59102&r1=58495&r2=59102

Is there a good reason for this?  I use python for a webstore, and send out 
emails for folks 
with multibyte names (for instance, if a name has an umlaut).

Here's a code snippit + exception:

Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 18:45:57) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtplib
>>> server = smtplib.SMTP("localhost")
>>> server.sendmail("[EMAIL PROTECTED]", "[EMAIL PROTECTED]", "Ümlaut")
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 713, 
in sendmail
(code,resp) = self.data(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 481, 
in data
self.send(q)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 305, 
in send
s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode character '\xdc' in position 0: 
ordinal not in 
range(128)

Is there a workaround or a new way of using it?  I couldn't seem to find it.

Thanks!

--
components: Library (Lib)
messages: 76295
nosy: ccgus
severity: normal
status: open
title: regression from 2.6: smtplib.py requiring ascii for sending messages
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

[issue4396] parser module fails to validate "with" statements.

[Benjamin Peterson]

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

Thanks for the patch! Fixed in r67365.

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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Toshio Kuratomi]

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment:

Pardon, but when you close something as wontfix it's polite to say why.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1208304] urllib2's urlopen() method causes a memory leak

[Toshio Kuratomi]

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment:

I tried to repeat the test in http://bugs.python.org/msg60749 and found
that the descriptors will close if you read from the file before closing.

so this leads to open descriptors::

  import urllib2
  f = urllib2.urlopen('http://www.google.com')
  f.close()

while this does not::

  import urllib2
  f = urllib2.urlopen('http://www.google.com')
  f.read(1)
  f.close()

--
nosy: +a.badger

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2433] Merge audio modules

[Brett Cannon]

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

On Sun, Nov 23, 2008 at 15:49, STINNER Victor <[EMAIL PROTECTED]> wrote:
>
> STINNER Victor <[EMAIL PROTECTED]> added the comment:
>
> 2.6 and 3.0rc3 are released. It's too late to change the standard
> library. So I prefer to close the bug. Reopen it if you want to work
> on that.
>

It's not too late, just harder; new modules can always be added and
old ones deprecated. If Michael still wants to do this there is a
chance for it to go into the stdlib. But closing the bug is fine.

--
title: Merge  audio modules -> Merge audio modules

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1208304] urllib2's urlopen() method causes a memory leak

[Toshio Kuratomi]

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment:

One further data point.   On two rhel5 systems with identical kernels,
both x86_64, both python-2.4.3... basically, everything I've thought to
check identical, I ran the test code with f.read() in an infinite loop.
 One system only has one TCP socket in use at a time.  The other one has
multiple TCP sockets in use, but they all close eventually.

/usr/sbin/lsof -p INTERPRETER_PID|wc -l reported 

96 67 97 63 91 62 94 78

on subsequent runs.

___
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

[Martin v. Löwis]

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

> Is there a good reason for this?

Most definitely. In Python 2.x, the string literal denotes
a byte string, whereas in 3.x, it is a character string.
It's not possible to send a character string directly over
the network; try encoding it.

It might be considered a bug that sendmail accepts a string
at all as long as the string only consists of ASCII characters;
it should reject such strings as well.

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Martin v. Löwis]

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

> Pardon, but when you close something as wontfix it's polite to say why.

Can you propose a reasonable way to fix this? People have thought hard,
and many days, and nobody could propose a reasonable fix. As 3.0 is
going to be released soon, there will be no way to fix it now.

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

Encoding the message first doesn't work either:

>>> import smtplib
>>> server = smtplib.SMTP("localhost")
>>> server.sendmail("[EMAIL PROTECTED]", "[EMAIL PROTECTED]", 
>>> "Ümlaut".encode("UTF-8"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 713, 
in sendmail
(code,resp) = self.data(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 477, 
in data
q = quotedata(msg)
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/smtplib.py", line 157, 
in quotedata
re.sub(r'(?:\r\n|\n|\r(?!\n))', CRLF, data))
  File "/home/mu.org/home/gus/unix/python3/lib/python3.0/re.py", line 165, in 
sub
return _compile(pattern, 0).sub(repl, string, count)
TypeError: can't use a string pattern on a bytes-like object

Should a check be done in data() first, before it tries to try string 
operations on it?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Toshio Kuratomi]

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment:

Is it a bug?  If so, then it should be retargetted to 3.1 instead of
closed wontfix.  If it's not a bug then there should be an explanation
of why it's not a bug.

As for fixing it there are several inelegant methods that are better
than silently ignoring the problem:

1) return mixed unicode and byte types in os.environ
2) return only byte types in os.environ
3) raise an exception if someone attempts to access an environment
variable that cannot be decoded to unicode via the system encoding and
allow the value to be accessed as a byte string via another method.
4) silently ignore the non-decodable variables when accessing os.environ
the normal way but have another method of accessing it that returns all
values as byte strings.

#4 is closest to what was done with os.listdir().  However, I think that
approach is wrong for os.listdir() and os.environ because it leads to
code that works in simple testing but can start failing mysteriously
when it becomes used in more environments.  The os.listdir() method will
lead to lots of people having to write code that uses the byte methods
on Unix and does its own conversion because it's the only thing
guaranteed to work on Unix and the unicode methods on Windows because
it's the only thing guaranteed to work there.  It degenerates to case #2
except harder to debug and requiring more platform specific knowledge of
the programmer.

#3 seems like the best choice to me as it provides a way for the
programmer to discover what's wrong and provide a fix but people seem to
have learned the wrong lessons from the python2 UnicodeEncode/Decode
problems so that might not have a large following other than me

#2 is conceptually correct since environment variables are a point where
you're receiving bytes from a non-python environment.  However, it's
very annoying for the common case where everything in the environment
has a single encoding.

#1 is the easiest for simplistic code to deal with but seems to violate
the python3 philosophy the most.  I don't like it as it takes us to one
of the real failings of python2's unicode handling: Not knowing what
type of data you're going to get back from a method and therefore not
knowing if you have to convert it before passing it on.  Please don't do
this one as it's two steps forward and one step backwards from where we
are now.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Martin v. Löwis]

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

> Is it a bug?

It's not a bug; see my original reply. This case is just not supported.

It may be supported in future versions, but (if it was for me) not
without a PEP first.

___
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

[Martin v. Löwis]

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

I see. It seems Python 3.0 just won't support that usage, then.

You still should be able to use MIME to send non-ASCII characters.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4404] os.listdir() documentation error

[steve21]

New submission from steve21 <[EMAIL PROTECTED]>:

The documentation entry for os.listdir(path) at
 html docs at http://docs.python.org/dev/3.0/library/os.html#module-os
says:

"os.listdir(path)
   Return a list containing the names of the entries in the directory.
The list is in arbitrary order. It does not include the special entries
. and .. even if they are present in the directory. Availability: Unix,
Windows.

This function can be called with a bytes or string argument. In the
bytes case, all filenames will be listed as returned by the underlying
API. In the string case, filenames will be decoded using the file system
encoding, and skipped if a decoding error occurs."

The problem is that nowhere it the above documentation does it describe
what the 'path' argument should be !

However, if I do
$ Python3.0
>>> import os
>>> help(os.listdir)   # it does describe 'path'
Help on built-in function listdir in module posix:

listdir(...)
listdir(path) -> list_of_strings

Return a list containing the names of the entries in the directory.

path: path of directory to list

The list is in arbitrary order.  It does not include the special
entries '.' and '..' even if they are present in the directory.


It looks like the html docs are missing some information and out of sync
with the module docs.

--
assignee: georg.brandl
components: Documentation
messages: 76307
nosy: georg.brandl, steve21
severity: normal
status: open
title: os.listdir() documentation error
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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Toshio Kuratomi]

Toshio Kuratomi <[EMAIL PROTECTED]> added the comment:

I'm sorry but "For the moment, this case is just not supported." is not
an explanation of why this is not a bug.  It is a statement that the
interpreter cannot handle a situation that has arisen.

If you said, "We don't believe that any computer has mixed encodings
that can show up in environment variables" that would be an explanation
of why this is not a bug and I could then give counter-examples of
computers that have mixed encodings in their environment variables.  So
what's the reason this is 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

[issue4006] os.getenv silently discards env variables with non-UTF-8 values

[Martin v. Löwis]

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

Toshio Kuratomi wrote:
> So what's the reason this is not a bug?

It's a bug only if the implementation deviates from the specification.
In this case, it does not. The behavior is intentional: python
deliberately drops environment variables it cannot represent as a
string. We know that such environment variables can happen in real
life - that's why they get dropped (rather than raising an exception
at startup).

___
Python tracker <[EMAIL PROTECTED]>

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