[issue4387] binascii b2a functions accept strings (unicode) as data

[Georg Brandl]

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

I vote yes.

--
nosy: +georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4378] howto doc update

[Georg Brandl]

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

Fixed in r67328.

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

[issue4361] Docstring for "Lib/string.py" is outdated

[Georg Brandl]

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

Fixed in r67329.

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

[issue4364] error in multiprocessing docs - rawvalue

[Georg Brandl]

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

Fixed in r67330.

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

[issue2306] Update What's new in 3.0

[Georg Brandl]

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

Added __cmp__ issue in r67331.

--
nosy: +georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4206] multiprocessing docs

[Georg Brandl]

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

Thanks, fixed in r67334.

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

[issue4012] Minor errors in multiprocessing docs

[Georg Brandl]

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

Fixed applyAsync and missing ] in r67335.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4193] Multiprocessing example

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> jnoller
nosy: +jnoller

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4153] Unicode HOWTO up to date?

[Georg Brandl]

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

Thanks for noting this! The most basic changes had been done, but I had
to revise some sections for changes. Done in r67338.

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

[issue4388] test_cmd_line fails on MacOS X

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

This seems to have something to do with the current locale.
On OS X 10.4.11/PPC I have:

$ echo $LANG
C

and the test fails.  On OS X 10.5.5:

$ echo $LANG
en_GB.UTF-8

and test_cmd_line.py passes.  Moreover, after doing:

$ export LANG=C

test_cmd_line.py fails on OS X 10.5 too in the same way.

--
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Here's a minimal failing example, which I believe captures the cause of 
the test_cmd_line failure.  After "export LANG=C", on OS X 10.5, I get:

Python 3.0rc3+ (py3k:67335, Nov 22 2008, 09:11:58) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, posix
>>> sys.getfilesystemencoding()
'utf-8'
>>> posix.execv(sys.executable, [sys.executable, '-c', "ord('\xe9')"])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: ord() expected a character, but string of length 2 found

Clearly the single '\xe9' character is being encoded in utf8 as
b'\xc3\xa9', and the python interpreter invoked by the execv ends up 
receiving two characters here instead of one.

The encoding happens at around line 2988 of posixmodule.c, in posix_execv.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'm not competent enough in this area to judge how serious this bug is, or 
determine what to do about it, but it seems as though it might potentially 
be a release blocker.

Martin, would you be able to take a look?

--
assignee:  -> loewis
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

[issue4388] test_cmd_line fails on MacOS X

[Amaury Forgeot d'Arc]

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

There is some inconsistency in the conversions with the "command line":
- on input, sys.argv decodes with mbstowcs
- on output, os.system uses utf-8, os.execv uses the 
FileSystemDefaultEncoding.

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

[issue3799] Byte/string inconsistencies between different dbm modules

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

py3k patched with specify_open_encoding.diff passes test_dbm_dumb on my
Mac (Leopard, Intel).  Might as well assign this to Brett.  He seems to
be doing all the heavy lifting anyway. ;-)

Skip

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

[issue4389] Uninstaller Lacks an Icon

[Retro]

New submission from Retro <[EMAIL PROTECTED]>:

The uninstaller program of the Python interpreter lacks an icon. This
looks ackward in the Add/Remove Programs list on the Windows platform.
Please add an icon for the uninstaller.

--
components: None
messages: 76246
nosy: Retro
severity: normal
status: open
title: Uninstaller Lacks an Icon
versions: 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

[issue4389] Uninstaller Lacks an Icon

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:


--
assignee:  -> loewis
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

[issue4389] Uninstaller Lacks an Icon

[Martin v. Löwis]

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

What specific release are you referring to?

___
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

[Giampaolo Rodola']

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment:

An actual test suite for ftplib is now available.
Should we reconsider revamping 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

[issue4252] some missing links in html help index pane

[Georg Brandl]

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

Okay, I applied your latest patch as changeset 970452b02e2e. 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

[issue4389] Uninstaller Lacks an Icon

[Retro]

Retro <[EMAIL PROTECTED]> added the comment:

As far as I know, the uninstaller has never had an icon, but it
certainly needs one. The upcoming versions of Python could be equipped
with a neat little icon. Are you willing to implement it? That would be
very nice.

___
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

[Martin v. Löwis]

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

I can't quite reproduce the problem. Both on "Uninstall Python" in the
start menu, and in "Add and remove programs", Windows displays an icon,
showing a computer and a cdrom, atleast on Windows XP. So where are you
missing the icon?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4385] Py_Object_HEAD_INIT in Py3k

[Martin v. Löwis]

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

I don't think PyObject_HEAD_INIT should be removed.

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

[issue4388] test_cmd_line fails on MacOS X

[Martin v. Löwis]

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

The locale machinery on OSX is flaky. The question is what people really
pass for command line arguments. It would be useful to find out what
happens in these two cases:

1. Somebody runs "a.py ภาษาไทย" in a Terminal.app window. Most likely,
the terminal encoding is applied, which we should assume to be UTF-8
(although it might be different on some systems).

2. Somebody creates a file japanese_コンテンツ in the finder, then uses
shell completion to pass this to a Python script. Here I expect that
UTF-8 is used even if the terminal's encoding is not UTF-8.

I don't know whether it's possible to launch Python scripts from Finder,
for given files, if so, it would also be interesting to find out what
encoding will be used there.

Without actual testing, I would assume that command line arguments are
typically encoded in UTF-8 on OSX. We should use that for argument
processing, regardless of mbstowcs.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Martin v. Löwis]

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


--
assignee: loewis -> 

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3996] PyOS_CheckStack does not work

[Martin v. Löwis]

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

The patch is fine, please apply it to all versions from 2.6 to 3.0.

--
assignee: loewis -> amaury.forgeotdarc
nosy: +krisvale
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

It looks like your conjectures are right in both cases.

I tried adding a few lines to Modules/python.c to print out the argv 
entries as byte strings, before they're passed to mbstowcs.  Results
on OS X 10.5:

> 1. Somebody runs "a.py ภาษาไทย" in a Terminal.app window. Most likely,
> the terminal encoding is applied, which we should assume to be UTF-8
> (although it might be different on some systems).

Yes, it appears that the terminal encoding is applied, if I'm reading 
the results right.  Trying

./python.exe a.py é

with the terminal character encoding set to "Unicode (UTF-8)", Python 
receives the third argument as bytes([195, 169]).  With the terminal 
encoding set to "Western (ISO Latin 1)" instead, Python receives
bytes([233]).

> 2. Somebody creates a file japanese_コンテンツ in the finder, then uses
> shell completion to pass this to a Python script. Here I expect that
> UTF-8 is used even if the terminal's encoding is not UTF-8.

Yes.  Python seems to receive the same string regardless of terminal 
encoding.  (With the terminal encoding set to latin1, the tab-completed 
filename looks like garbage within Terminal, of course.)

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

Oh, I guess I should have been more informative, sorry. My OS is Windows
Vista Business (64 bit) onto which I have installed the 32 bit
interpreter. And now when this 32 bit interpreter is installed on my 64
bit OS platform, I don't see the two-snakes-kind-of-like icon in the
Add/Remove Programs list; instead I see the default icon -- you know,
that squared box. The files python.exe and pythonw.exe both have that
two-snakes-kind-of-like icon, and even pressing Alt+Tab (when the
interpreter is running) displays the two-snakes-kind-of-like icon, but
this two-snakes-kind-of-like icon is not displayed in the Add/Remove
Programs list. So I find that a strange thing to be.

Anyway, this is a bug so I reported it. I really don't know why this bug
exists. This could be because of a 64 bit OS and a 32 bit interpreter
mix issue, but I doubt it.

This is probably an easy fix for you guys. I keep my fingers crossed for
this bug to be fixed. Oh, and I can make screenshots if you like.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3996] PyOS_CheckStack does not work

[Amaury Forgeot d'Arc]

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

Committed r67343 (trunk) and r67344 (release26-maint)

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

[issue4390] Using subprocess.STDOUT causes AttributeError

[Krzysztof Pawlik]

New submission from Krzysztof Pawlik <[EMAIL PROTECTED]>:

Using stderr=subprocess.STDOUT causes Python 3.0 (RC1 from Ubuntu 8.10)
to raise AttributeError, important code snippet (whole test program
attached):

proc = subprocess.Popen(['whoami'], stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
stdout, stderr = proc.communicate()


[EMAIL PROTECTED] ~$ python2.5 --version
Python 2.5.2
[EMAIL PROTECTED] ~$ python2.5 test-subprocess.py
('stdout:', 'nelchael\n')
('stderr:', None)
[EMAIL PROTECTED] ~$ python3 --version
Python 3.0rc1+
[EMAIL PROTECTED] ~$ python3 test-subprocess.py
Traceback (most recent call last):
  File "test-subprocess.py", line 4, in 
stdout, stderr = proc.communicate()
  File "/usr/lib/python3.0/subprocess.py", line 663, in communicate
stdout = self._fo_read_no_intr(self.stdout)
AttributeError: 'Popen' object has no attribute '_fo_read_no_intr'
[EMAIL PROTECTED] ~$

--
components: Library (Lib)
files: test-subprocess.py
messages: 76258
nosy: nelchael
severity: normal
status: open
title: Using subprocess.STDOUT causes AttributeError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file12106/test-subprocess.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4390] Using subprocess.STDOUT causes AttributeError

[Amaury Forgeot d'Arc]

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

This "_fo_read_no_intr" method does not exist anywhere in the standard 
python code.

A quick Google search reveals that it certainly comes from a patch 
proposed by the Ubuntu maintainers:
http://patches.ubuntu.com/p/python2.5/extracted/subprocess-eintr-
safety.dpatch

It is very likely that this patch (for 2.5) did not apply correctly to 
the 3.0 source code.
In any case, this is not a Python problem.

--
nosy: +amaury.forgeotdarc
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

[issue4391] optparse: use proper gettext plurals forms

[Dwayne Bailey]

New submission from Dwayne Bailey <[EMAIL PROTECTED]>:

The following code in optparse:

if len(rargs) < nargs:
if nargs == 1:
self.error(_("%s option requires an argument") % opt)
else:
self.error(_("%s option requires %d arguments")
   % (opt, nargs))

works for languages with plurals of n!=1 but will not work for many
others that have more sophisticated plurals.

I've created a patch that handles missing gettext and implements it
correctly if it is available. Be aware that I have not been able to test
the patch.

--
components: Library (Lib)
files: optparse_proper_gettext_plurals.diff
keywords: patch
messages: 76260
nosy: dwayne
severity: normal
status: open
title: optparse: use proper gettext plurals forms
type: behavior
versions: Python 2.5
Added file: 
http://bugs.python.org/file12107/optparse_proper_gettext_plurals.diff

___
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

[David W. Lambert]

David W. Lambert <[EMAIL PROTECTED]> added the comment:

And while at it, replace "usage" with "Use".
"Usage" isn't a word.

--
nosy: +LambertDW

___
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

[Dwayne Bailey]

Dwayne Bailey <[EMAIL PROTECTED]> added the comment:

Mmm some problems with my head late at night.  This patch sorts things
out and makes sure strings can be extracted by xgettext

Added file: 
http://bugs.python.org/file12108/optparse_proper_gettext_plurals.diff

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

The test was originally run with

% echo $LANG
tcsh: LANG: Undefined variable.

The same failure occurs with LANG set to C 

% env LANG=C ../Python-3.0rc3/python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 151, in 
test_main()
  File "Lib/test/test_cmd_line.py", line 147, in test_main
test.support.run_unittest(CmdLineTest)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
698, in run_unittest
_run_suite(suite)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
681, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
0)
AssertionError: 1 != 0


But the test passes in both these cases:

% env LANG=en_US.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py
Lib/test/test_cmd_line.py

test_run_code (__main__.CmdLineTest) ... ok

OK


% env LANG=en_GB.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py

test_run_code (__main__.CmdLineTest) ... ok

OK

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4388] test_cmd_line fails on MacOS X

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

The results from this script

  import os, sys
  print('Python %s' % sys.version.split()[0])
  print('env[LANG]: %s' % os.environ.get('LANG', ''))
  print('default encoding: %s' % sys.getdefaultencoding())
  print('filesystem encoding: %s' % sys.getfilesystemencoding())

are with Python 3.0:

Python 3.0rc3
env[LANG]: 
default encoding: utf-8
filesystem encoding: utf-8

but for Python 2.3 thru 2.6:

Python 2.6
env[LANG]: 
default encoding: ascii
filesystem encoding: utf-8

All with Python built from source on MacOS X 10.4.11 (Intel).

___
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

[none_00]

New submission from none_00 <[EMAIL PROTECTED]>:

http://docs.python.org/library/collections.html#collections.namedtuple
it is stated that the second parameter to namedtuple 
is "fieldnames", while in reality it is "field_names"

--
assignee: georg.brandl
components: Documentation
messages: 76265
nosy: georg.brandl, none_00
severity: normal
status: open
title: incorrect parameter name for collections.namedtuple
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