[issue13643] 'ascii' is a bad filesystem default encoding

[vila]

Changes by vila :


--
nosy: +vila

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Can you post the exact compiler errors you encountered?

--

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Nevermind, I've found them on the Fedora buildbot.

--

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Roundup Robot]

Roundup Robot  added the comment:

New changeset ec44f2e82707 by Antoine Pitrou in branch 'default':
Fix ssl module compilation if ECDH support was disabled in the OpenSSL build.
http://hg.python.org/cpython/rev/ec44f2e82707

--

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Since we're at it, do you know if Redhat also disables regular Diffie-Hellman? 
See issue13626.

--

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.

--
status: open -> closed

___
Python tracker 

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

[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/902f694a7b0e

New changeset b08bf8df8eec by Antoine Pitrou in branch 'default':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/b08bf8df8eec

--
nosy: +python-dev

___
Python tracker 

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

[issue1785] "inspect" gets broken by some descriptors

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/902f694a7b0e

New changeset b08bf8df8eec by Antoine Pitrou in branch 'default':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/b08bf8df8eec

--
nosy: +python-dev

___
Python tracker 

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

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Lars Gustäbel]

Lars Gustäbel  added the comment:

Is there a good reason why the tarfile mode that is used is "w|gz"? It seems to 
me that this is not necessary, "w:gz" should be enough. "w|gz" is for special 
operations only (see the tarfile docs).

--
nosy: +lars.gustaebel
Added file: http://bugs.python.org/file24065/distutils_tarfile_fix.diff

___
Python tracker 

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

[issue1785] "inspect" gets broken by some descriptors

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/13f56cd8dec1

--

___
Python tracker 

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

[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/13f56cd8dec1

--

___
Python tracker 

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

[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now fixed in all 3 branches.

--
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "inspect" gets broken by some descriptors

___
Python tracker 

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

[issue1785] "inspect" gets broken by some descriptors

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now fixed in all 3 branches.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Lars Gustäbel]

Lars Gustäbel  added the comment:

tarfile under Python 2.x is not particularly designed to support unicode 
filenames (the gzip module does not support them either), but that should not 
be too hard to fix.

--
keywords: +patch
Added file: 
http://bugs.python.org/file24066/tarfile-stream-gzip-unicode-fix.diff

___
Python tracker 

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

[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b07b1e58582d by Antoine Pitrou in branch 'default':
Issue #12708: Add starmap() and starmap_async() methods (similar to 
itertools.starmap()) to multiprocessing.Pool.
http://hg.python.org/cpython/rev/b07b1e58582d

--
nosy: +python-dev

___
Python tracker 

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

[issue12708] multiprocessing.Pool is missing a starmap[_async]() method.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch committed. Thanks for your contribution!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think we should relax the constraints a bit (RC4 seems ok for TLS/SSL use 
(*)) and therefore suggest we settle on 
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2".

(OpenSSL's default is "DEFAULT:!aNULL:!eNULL", so we're really disabling weak 
ciphers)

(*) Wikipedia even notes: “RC4, being a stream cipher, is the only common 
cipher which is immune[7] to the 2011 BEAST attack on TLS 1.0, which exploits a 
known weakness in the way cipher block chaining mode is used with all of the 
other ciphers supported by TLS 1.0, which are all block ciphers”

--

___
Python tracker 

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

[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I also suggested changes to the documentation of the "-u" flag, and to 
> "What's New in Python 3.0", can someone look at that also?

Sorry for having overlooked that. This should now be fixed as well.

--

___
Python tracker 

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

[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 19df72a77b39 by Antoine Pitrou in branch '3.2':
Issue #13597: Fix the documentation of the "-u" command-line option, and 
wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/19df72a77b39

New changeset 1ab124a6f171 by Antoine Pitrou in branch 'default':
Issue #13597: Fix the documentation of the "-u" command-line option, and 
wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/1ab124a6f171

--

___
Python tracker 

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

[issue13553] Tkinter doesn't set proper application name

[th9]

th9  added the comment:

Yes, I'm aware of the 'iconname' docs. In this case 'iconname' probably is not 
the right property to set, but I don't know which one should be.

For GTK+ applications there is a special function for setting application name 
which should be shown to user and apparently Gnome 3 is using that. 

http://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-set-application-name

I don't know how to achieve the same for Tkinter.

--

___
Python tracker 

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

[issue13577] __qualname__ is not present on builtin methods and functions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the patch. Since you modified PyCFunction_GET_SELF to return NULL 
for static methods, why not simply use it instead of manually looking up the 
flags in several places?

I'm talking about the following changes:

-PyObject *self = PyCFunction_GET_SELF(func);
+int flags = PyCFunction_GET_FLAGS(func);
+PyObject *self = flags & METH_STATIC ? NULL :
+_PyCFunction_GET_RAW_SELF(func);

[...]

 self = m->m_self;
-if (self == NULL)
+if (self == NULL || PyCFunction_GET_FLAGS(m) & METH_STATIC)
 self = Py_None;

[...]

-PyObject *self = PyCFunction_GET_SELF(func);
+PyObject *self = flags & METH_STATIC ? NULL :
+_PyCFunction_GET_RAW_SELF(func);


Unless you demonstrate there's a significant performance improvement in this 
style, we should really favour the simpler style.

--

___
Python tracker 

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

[issue12453] test_import.test_failing_import_sticks() sporadic failures

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +brett.cannon, ncoghlan

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Antoine Pitrou]

New submission from Antoine Pitrou :

test_import fails when run directly after test_coding:

$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_import.py", line 115, in 
test_creation_mode
self.assertEqual(stat.S_IMODE(s.st_mode), 0o666 & ~mask)
AssertionError: 436 != 420


384 is 0o600 while 420 is 0o644.

(seen sporadically on some buildbots, e.g.
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/1462/steps/test/logs/stdio
)


The same thing happens in 3.2, although the failing test is a different one:

$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/32/Lib/test/test_import.py", line 117, in 
test_execute_bit_not_copied
stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH)
AssertionError: 436 != 292

--
components: Interpreter Core, Tests
messages: 149982
nosy: brett.cannon, ncoghlan, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_import fails after test_coding
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The cause is that the import machinery checks the timestamp stored in the pyc 
file to decide whether it must be refreshed. Depending on the system's 
timestamp granularity, there can be false negatives: the py file was modified 
twice with the same timestamp, but the pyc file isn't regenerated for the 
second version of the py file. Adding a time.sleep(1) call to the failing test 
case makes it pass.

Correct fix for 3.2's tests is the following. I don't know if the import 
machinery can be improved not to exhibit any false negatives:

diff --git a/Lib/test/test_import.py b/Lib/test/test_import.py
--- a/Lib/test/test_import.py
+++ b/Lib/test/test_import.py
@@ -107,8 +107,9 @@ class ImportTests(unittest.TestCase):
 open(fname, 'w').close()
 os.chmod(fname, (stat.S_IRUSR | stat.S_IRGRP | stat.S_IROTH |
  stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH))
+fn = imp.cache_from_source(fname)
+unlink(fn)
 __import__(TESTFN)
-fn = imp.cache_from_source(fname)
 if not os.path.exists(fn):
 self.fail("__import__ did not result in creation of "
   "either a .pyc or .pyo file")

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

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The pyc format currently stores the modification time cast to a 32-bit int. A 
3.3 iteration of the pyc format could instead store two 32-bit ints, one for 
the integral part and one for the fractional part (e.g. in nanoseconds). When 
HAVE_STAT_TV_NSEC is defined, struct stat has a "st_mtim" member which is a 
struct timespec providing theoretical nanosecond precision.

Whether this would be useful remains to be decided.

--

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Changes by Hynek Schlawack :


Added file: http://bugs.python.org/file24067/c92c4d936255.diff

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Jason R. Coombs]

Jason R. Coombs  added the comment:

That looks like a good patch to me. Do you want to commit it, or would you 
rather I do?

--

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Hynek Schlawack  added the comment:

I have updated the patch to latest default/tip and would appreciate a review.

--

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I've done a review at http://bugs.python.org/review/12715

--
nosy: +pitrou

___
Python tracker 

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

[issue3990] The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc

[Stefano Rivera]

Changes by Stefano Rivera :


--
nosy: +stefanor

___
Python tracker 

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

[issue13646] Document poor interaction between multiprocessing and -m on Windows

[Nick Coghlan]

New submission from Nick Coghlan :

The http://docs.python.org/library/multiprocessing#windows section of the docs 
should document the limitations that multiprocessing on Windows places on 
__main__ module invocation.

- no execution of modules inside packages with -m
- no execution of packages (since their __main__ is inside the package)

--
messages: 149988
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Document poor interaction between multiprocessing and -m on Windows

___
Python tracker 

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

[issue10128] multiprocessing.Pool throws exception with __main__.py

[Nick Coghlan]

Nick Coghlan  added the comment:

The fix from #10845 should be backported to Python 2.7 (bypassing the assertion 
isn't enough - you want to skip re-executing __main__ entirely)

--
nosy: +ncoghlan

___
Python tracker 

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

[issue13646] Document poor interaction between multiprocessing and -m on Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

(Actually the latter isn't true - the __main__ bypass handles that case. Since 
none of the code gets executed in the child process, it doesn't generally 
matter that __package__ isn't set properly)

--

___
Python tracker 

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

[issue13620] Support Chrome in webbrowser.py

[Senthil Kumaran]

Senthil Kumaran  added the comment:

This is in 3.3. Thanks for the patches.

--
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue13620] Support Chrome in webbrowser.py

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 7faa90a6324c by Senthil Kumaran in branch 'default':
Issue 13620 - Support chrome browser in webbrowser.py module.
http://hg.python.org/cpython/rev/7faa90a6324c

New changeset bd3631f9aa5c by Senthil Kumaran in branch 'default':
Docs and News update for Issue13620. Chrome support in webbrowser.py
http://hg.python.org/cpython/rev/bd3631f9aa5c

--
nosy: +python-dev

___
Python tracker 

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

[issue13620] Support Chrome in webbrowser.py

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
stage: patch review -> committed/rejected

___
Python tracker 

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

[issue11012] Add log1p(), exp1m(), gamma(), and lgamma() to cmath

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Charles-François Natali]

Charles-François Natali  added the comment:

> a struct timespec providing theoretical nanosecond precision.

Indeed. EXT3's timestamps have a 1s granularity, for example.
Another possibility would be to store both mtime and st_size (it's the default 
heuristic used by rsync does to decide whether to skip a file).

> Whether this would be useful remains to be decided.

Dunno.
On the one hand, it's frustrating to think that you can end up with a stale 
bytecode file forever (I've had more or less the same problem because of NFS 
mounts, and it can be quite puzzling when the last modification you made to the 
source file is not taken into account).
OTOH, nobody has ever complained about this...

--

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f4afc6858ed2 by Antoine Pitrou in branch '3.2':
Issue #13645: fix test_import failure when run immediately after test_coding.
http://hg.python.org/cpython/rev/f4afc6858ed2

New changeset a6bd166abde5 by Antoine Pitrou in branch 'default':
Issue #13645: fix test_import failure when run immediately after test_coding.
http://hg.python.org/cpython/rev/a6bd166abde5

--
nosy: +python-dev

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

In the meantime, I've committed the test patch.

--

___
Python tracker 

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

[issue8713] multiprocessing needs option to eschew fork() under Linux

[Charles-François Natali]

Charles-François Natali  added the comment:

Thanks for the patch sbt.
I think this is indeed useful, but I'm tempted to go further and say we should 
make this the default - and only - behavior. This will probably break existing 
code that accidentaly relied the fact that the implementation uses a bare 
fork(), but i'd say it's worth it:
- it's cleaner
- it will make it possible to remove all the ad-hoc handlers called after fork()
- it will remove the only place in the whole stdlib where fork() isn't followed 
by exec(): people who get bitten by issue #6721 will thus only be people 
calling explicitely fork(), in which case they're the sole responsibles for 
their misery ;-)

Another - although less common - advantage over the current implementation is 
that now one can run out of memory pretty easily if the operating system 
doesn't do overcommitting if you work with a large dataset. If fork() is 
followed by an exec, no problem.

Thoughts?

--
nosy: +neologix, pitrou

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Indeed. EXT3's timestamps have a 1s granularity, for example.
> Another possibility would be to store both mtime and st_size (it's the
> default heuristic used by rsync does to decide whether to skip a
> file).

Good idea. It would also avoid too much Windows-specific code (subsecond
precision for timestamps requires the use of a Win32 API).

--

___
Python tracker 

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

[issue8713] multiprocessing needs option to eschew fork() under Linux

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Thanks for the patch sbt.
> I think this is indeed useful, but I'm tempted to go further and say
> we should make this the default - and only - behavior. This will
> probably break existing code that accidentaly relied the fact that the
> implementation uses a bare fork(),

There is probably lots of such code:
- code that passes non-pickleable function object / function args to
execute in the child process
- code that executes code with side effects at module top level
- code that relies (willingly or not) on other stuff such as fds being
inherited

--

___
Python tracker 

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

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Meador Inge]

Meador Inge  added the comment:

> ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.

Awesome, thanks Antoine.  I will checkout the DH patch from issue13626 on 
Fedora today.

--

___
Python tracker 

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

[issue13626] Python SSL stack doesn't support DH ciphers

[Meador Inge]

Meador Inge  added the comment:

Per the Red Hat problems in issue13627 I just tried this patch on Fedora 16.  
Everything built just fine.  However, the patch doesn't apply cleanly to tip an 
longer:

[meadori@motherbrain cpython]$ patch -p1 < ../patches/dh.patch 
patching file Doc/library/ssl.rst
Hunk #2 succeeded at 715 (offset 27 lines).
patching file Lib/ssl.py
Hunk #1 succeeded at 68 with fuzz 2.
patching file Lib/test/dh512.pem
patching file Lib/test/ssl_servers.py
Hunk #1 succeeded at 180 (offset 1 line).
Hunk #2 succeeded at 194 (offset 1 line).
patching file Lib/test/test_ssl.py
Hunk #2 succeeded at 101 with fuzz 2.
Hunk #3 succeeded at 541 (offset 3 lines).
Hunk #4 FAILED at 1200.
Hunk #5 succeeded at 1858 with fuzz 2 (offset 29 lines).
1 out of 5 hunks FAILED -- saving rejects to file Lib/test/test_ssl.py.rej
patching file Modules/_ssl.c
Hunk #1 succeeded at 1922 (offset 20 lines).
Hunk #2 succeeded at 2082 (offset 22 lines).
Hunk #3 succeeded at 2539 with fuzz 2 (offset 24 lines).

After fixing the unit test hunk everything builds and the SSL unit tests pass.

--
nosy: +meador.inge

___
Python tracker 

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

[issue8713] multiprocessing needs option to eschew fork() under Linux

[sbt]

sbt  added the comment:

> I think this is indeed useful, but I'm tempted to go further and say we 
> should make this the default - and only - behavior. This will probably 
> break existing code that accidentaly relied the fact that the 
> implementation uses a bare fork(), but i'd say it's worth it:

I'm not convinced about making it the default behaviour, and certainly not the 
only one.

I have a working patch which ensures that leaked semaphores get cleaned up on 
exit.  However, I think to add proper tests for the patch, test_multiprocessing 
needs to be refactored.  Maybe we could end up with

multiprocessing_common.py
test_multiprocessing_processes_fork.py
test_multiprocessing_processes_nofork.py
test_multiprocessing_manager_fork.py
test_multiprocessing_manager_nofork.py
test_multiprocessing_threads.py
test_multiprocessing_others.py

The actual unittests would be in multiprocessing_common.py and 
test_multiprocessing_others.py.  The other files would run the unittests in 
multiprocessing_common.py using different configurations.

Thoughts?

--

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[Charles-François Natali]

Charles-François Natali  added the comment:

I'd like to make this move forward.
Milko, I see you have an implementation which looks OK at a first glance. Would 
like to propose a patch against the default branch? The patch should include 
documentation and tests.
I'm not sure about the best module to host this, though: os.path ?

--

___
Python tracker 

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

[issue13511] Let ./configure accept multiple --includedir and --libdir options

[Éric Araujo]

Éric Araujo  added the comment:

You haven’t answered my question: Is it a standard configure feature to support 
multiple --includedir and --libdir?

If it’s a standard feature used by people, then you can argue it’s a build bug 
for all active versions (2.7, 3.2, 3.3).

If it’s a request for something specific to CPython, then as a new feature it 
would go into 3.3 only.

--
title: ./configure --includedir, --libdir accept multiple -> Let ./configure 
accept multiple --includedir and --libdir options
type: behavior -> enhancement
versions:  -Python 2.7

___
Python tracker 

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

[issue8713] multiprocessing needs option to eschew fork() under Linux

[Charles-François Natali]

Charles-François Natali  added the comment:

> There is probably lots of such code:

> I'm not convinced about making it the default behaviour, and 
> certainly not the only one.

Then I'm not convinced that this patch is useful.
Having three different implentations and code paths doesn't sound like a good 
idea to me.
fork() vs fork() + exec() is an implementation detail, and exposing such 
tweakables to the user will only make confusion worse.

--

___
Python tracker 

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

[issue1785] "inspect" gets broken by some descriptors

[Éric Araujo]

Éric Araujo  added the comment:

Great stuff.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue13644] Python 3 crashes (segfaults) with this code.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

The behavior of Python 2 is not anymore correct than that of Python 3.

--

___
Python tracker 

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

[issue13511] Let ./configure accept multiple --includedir and --libdir options

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Parsing of options is implemented inside autoconf. The feature would have to be 
implemented in autoconf and then 'configure' would have to be regenerated from 
'configure.in' using new version of autoconf.

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

Well, if you do:
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2" ciphers enabled are
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH   Au=DSS  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA  SSLv3 Kx=PSK  Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHASSLv3 Kx=PSK  Au=PSK  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHASSLv3 Kx=DH   Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 Kx=DH   Au=DSS  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH   Au=DSS  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHASSLv3 Kx=RSA  Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHASSLv3 Kx=RSA  Au=RSA  Enc=IDEA(128) Mac=SHA1
PSK-AES128-CBC-SHA  SSLv3 Kx=PSK  Au=PSK  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=MD5 
PSK-RC4-SHA SSLv3 Kx=PSK  Au=PSK  Enc=RC4(128)  Mac=SHA1


If we want to start from the "DEFAULT" than we should probably disable:
- PSK
- CAMELLIA
- MD5
- IDEA
- SEED

That way:
openssl ciphers -v 
'DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2:!PSK:!CAMELLIA:!MD5:!IDEA!SEED'

ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSL

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If we want to start from the "DEFAULT" than we should probably disable:
> - PSK
> - CAMELLIA
> - MD5
> - IDEA
> - SEED

Why do you want to disable all these?

--

___
Python tracker 

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

[issue13577] __qualname__ is not present on builtin methods and functions

[sbt]

sbt  added the comment:

A simplified patch getting rid of _PyCFunction_GET_RAW_SELF().

--
Added file: http://bugs.python.org/file24068/method_qualname.patch

___
Python tracker 

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

[issue13645] test_import fails after test_coding

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue13585] Add contextlib.CleanupManager

[Éric Araujo]

Éric Araujo  added the comment:

> The idea is to add a general-purpose context manager to manage (python
> or non-python) resources that don't come with their own context manager.

I read the thread back on python-ideas and didn’t like the idea, without 
knowing exactly why—maybe a feeling that it’s too generic and less clean than 
adding context management support to the classes directly.  My opinion is only 
that of a user, I’m less qualified than Nick or Raymond for this module.

In the passage I quoted, I don’t understand what is meant by “non-Python 
resources”.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue13585] Add contextlib.CleanupManager

[Nikolaus Rath]

Nikolaus Rath  added the comment:

On 12/21/2011 11:46 AM, Éric Araujo wrote:
> 
> Éric Araujo  added the comment:
> 
>> The idea is to add a general-purpose context manager to manage (python
>> or non-python) resources that don't come with their own context manager.
> 
> In the passage I quoted, I don’t understand what is meant by “non-Python 
> resources”.

Think about e.g. mounting a file system.

Best,

   -Nikolaus

--

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Changes by Hynek Schlawack :


Added file: http://bugs.python.org/file24069/4832bf7aa028.diff

___
Python tracker 

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

[issue2134] Add new attribute to TokenInfo to report specific token IDs

[Éric Araujo]

Éric Araujo  added the comment:

The cmdoption directive should be used with a program directive.  See 
library/trace for an example of how to use it and to see the anchors and index 
entries it generates.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Hynek Schlawack  added the comment:

Thanks to Antoine & Charles-François for their reviews! I think I've 
incorporated all desired changes.

Please let me know if I have missed something, meanwhile I'll tackle the docs.

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

Well,

with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
- MD5 was disabled
- IDEA was disabled
- SEED was disabled

Then we realized that RC4 could be a cipher to be leaved enabled, so the new 
proposal starting from 'DEFAULT'.

While i don't like RC4 because it's not FIPS-140 compliant 
(https://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html)
 i understand that we may want to keep it.

I would suggest by default to keep disabled also CAMELIA and PSK because almost 
no one use it, they are just into the standard like many ciphers.

Generally speaking, as a concept to define a default we could:
- Start from a FIPS-140 compliant SSL stack
- Open some additional ciphers for compatibility reason (for example RC4-SHA)

What do you think about such approach?

-naif

--

___
Python tracker 

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

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

[Éric Araujo]

Éric Araujo  added the comment:

I think this would need a test.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue13585] Add contextlib.CleanupManager

[Éric Araujo]

Éric Araujo  added the comment:

>> In the passage I quoted, I don’t understand what is meant by “non-Python 
>> resources”.
> Think about e.g. mounting a file system.

Ah, ok.  In that case there would still be a Python-level object (just like a 
Python file object will also release the OS-level handle when it’s closed).

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Why make this decision ourselves at all? Copy what Mozilla and Chromium do
by default.

--

___
Python tracker 

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

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Éric Araujo]

Éric Araujo  added the comment:

Lars: I will check the history to see if there is a reason (there is probably 
none) and apply your patch, thank you.

Jason: Thanks for the input.

> It's not obvious to me what the encoding should be. Python and the tarfile 
> module can
> accept unicode filenames.
Note that distutils2 supports back to 2.4, which may not be as convenient.

> It seems that only the gzip part of tarfile fails if a unicode name is passed.
OK.

> Encoding to 'utf-8' or the default file system encoding doesn't seem right 
> (as the
> characters end up getting stored in the gzip archive itself).
I don’t understand.

> Additionally, encoding as 'utf-8' would cause the file to be created with a 
> utf-8 filename,
> which would be undesirable.
Why?

> So in the current repo, I've created a check to convert the filename to 
> ASCII. If it can be
> converted to ASCII, it is converted and passed through to tarfile. This 
> should address the
> majority of users who have thus encountered this issue. For those who wish to 
> use non-ascii
> characters in project names or versions, one will have to use Python 3 or 
> wait until #13639
> is fixed.
The problem is that even in the latest PEP (345), the characters allowed in a 
project name are under-specified.  I don’t know if restricting to ASCII-only is 
acceptable.

> Please review the enclosed patch.
I will.

> Since one test fails (and is known to fail), should it omitted? Can it remain 
> but be marked as
> "expected to fail"?
Is it the test with non-ASCII characters?  If there’s hope to fix it later, you 
can include it and mark it @unittest.expectedFailure.

--
keywords:  -easy, patch
nosy: +haypo

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Why make this decision ourselves at all? Copy what Mozilla and Chromium do
> by default.

If that translates to an explicit list of ciphers it will be a pain to
maintain. Using a generic OpenSSL string such as "DEFAULT:!LOW:[etc.]"
means OpenSSL mostly does the maintenance for us.

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
> - MD5 was disabled
> - IDEA was disabled
> - SEED was disabled

That was the consequence of it, but that wasn't an explicit goal.

> Generally speaking, as a concept to define a default we could:
> - Start from a FIPS-140 compliant SSL stack
> - Open some additional ciphers for compatibility reason (for example
> RC4-SHA)
> 
> What do you think about such approach?

As I already said, the more sophisticated the approach, the more tedious
the maintenance.

--

___
Python tracker 

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

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

[Charles-François Natali]

Charles-François Natali  added the comment:

Yes, but it's not easy: the different URLs provided don't demonstrate
the behavior anymore (even if we do find such an URL, there's no
guarantee it won't change in a couple days/weeks).
It could be possible to set up an ad-hoc httpserver for that purpose,
but that sounds a bit overkill.

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

Well, my concept is that it would be reasonable to use what people consider 
secure.

SSL/TLS are security protocol.

Some combination of the protocol configuration (ciphers/hash/key exchange) are:
- known to be insecure
- known to be secure
- known to be unused (like SEED, only used in South Korea by military 
applications) or PSK with almost no adoption
- Unknown (like CAMELIA, i don't find a single software using it)

The concept i would propose is to choose the ciphers that "known to be secure" 
by disabling everything else.

--

___
Python tracker 

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

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> > Encoding to 'utf-8' or the default file system encoding doesn't seem
> > right (as the characters end up getting stored in the gzip archive itself).
> I don’t understand.

The characters are being stored in the gzip archive as part of the gzip header. 
The comment in the Python 3 trunk indicates the encoding should be iso-8859-1: 
https://bitbucket.org/mirror/cpython/src/f3041e7f535d/Lib/tarfile.py#cl-475

My point is that the file system encoding is not relevant here. Because the 
name is being stored in a gzip blob, it should be encoded according to gzip 
specs.

> > Additionally, encoding as 'utf-8' would cause the file to be created
> > with a utf-8 filename, which would be undesirable.
> Why?

My concern here was that if we're encoding the string as utf-8 before passing 
to the __builtins__.open() call, Python might encode _that_ utf-8 string using 
the file system encoding and save the file that way (where the file is named 
with a utf-8 encoded string, not the unicode string intended). After further 
investigation, and based on the work that's been proposed, this is not a risk.

--

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The concept i would propose is to choose the ciphers that "known to be
> secure" by disabling everything else.

I hate repeating myself, but who will maintain it?

--

___
Python tracker 

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

[issue13607] Move generator specific sections out of ceval.

[Ron Adam]

Ron Adam  added the comment:

I think the time benefits I saw are dependent on how the C code is compiled.  
So it may be different on different compilers or the same compiler with only a 
very minor change.

Some of the things I've noticed...

A switch is sometimes slower if it has a "default:" block.

Moving "why = tstate->why_exit;" to just before the if helps a tiny bit.

why = tstate->why_exit;
if (why != WHY_EXCEPTION) {

Returning directly out of the WHY_YIELD case.

case WHY_YIELD:
return result;

These will be mostly compiler dependent, but they won't slow things down any 
either.

What I was trying to do is clean up things a bit in ceval.c.  Having the why 
available on the frame can help by allowing some things to be moved out of 
ceval.c where it makes sense to do that.

I'll post a new diff tonight with the why_exit moved back to the frame object 
and the why's back to enums.  Yes, I think the frame object is a good place for 
it.

One of the odd issues is the opcode and why values sometimes need to be pushed 
on the value stack.  Which means it needs to be converted to a pyobject first, 
then converted back after it's pulled off the stack.  I'm looking for a way to 
avoid that.

I also was able to make fast_block_end section simpler and more understandable 
without making it slower.  I think it was trying to be too clever in order to 
save some lines of code.  That makes it very hard to figure out by someone else.

But first I need to finish my Christmas shopping, I'll post a new patch tonight 
when I get a chance. :-)

--

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Changes by Hynek Schlawack :


Added file: http://bugs.python.org/file24070/d9212bb67f64.diff

___
Python tracker 

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

[issue12715] Add symlink support to shutil functions

[Hynek Schlawack]

Hynek Schlawack  added the comment:

The patch contains also the necessary changes for the docs now.

Please let me know, if I can do anything else.

--

___
Python tracker 

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

[issue13585] Add contextlib.CleanupManager

[Nikolaus Rath]

Nikolaus Rath  added the comment:

On 12/21/2011 12:03 PM, Éric Araujo wrote:
> 
> Éric Araujo  added the comment:
> 
>>> In the passage I quoted, I don’t understand what is meant by “non-Python 
>>> resources”.
>> Think about e.g. mounting a file system.
> 
> Ah, ok.  In that case there would still be a Python-level object (just like a 
> Python file object will also release the OS-level handle when it’s closed).

I don't think so.

subprocess.check_call(['mount', 'bla', '/mnt'])

Allocates the resource (mounts the file system) but doesn't leave you
with any Python object.

Best,

   -Nikolaus

--

___
Python tracker 

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

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Lars Gustäbel]

Lars Gustäbel  added the comment:

Just for the record:

The gzip format (defined in RFC 1952) allows storing the original filename 
(without the .gz suffix) in an additional field in the header (the FNAME 
field). Latin-1 (iso-8859-1) is required. It is ironic that this causes so much 
trouble, because it is never used. A gzip file without that field is prefectly 
valid. The gzip program for example stores the original filename by default but 
does not use it when decompressing unless it is explicitly told to do so with 
the -N/--name option. If no FNAME field is present in a gzipped file the gzip 
program just falls back on stripping the .gz suffix.

--

___
Python tracker 

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

[issue13607] Move generator specific sections out of ceval.

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue8713] multiprocessing needs option to eschew fork() under Linux

[Jesse Noller]

Jesse Noller  added the comment:

On Wednesday, December 21, 2011 at 10:04 AM, Charles-François Natali wrote:

While I would tend to agree with you in theory - I don't think we should make 
it the default - at least not without a LOT of lead time. There's a surprising 
amount of code relying on the current behavior that I think the best course is 
to enable this option, and change the docs to steer users in this direction.

For users jumping from 2.x into 3.x, I think the less surprises they have the 
better, and changing the default behavior of the stdlib module in this was 
would qualify as surprising.

--

___
Python tracker 

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

[issue13643] 'ascii' is a bad filesystem default encoding

[STINNER Victor]

STINNER Victor  added the comment:

> Having more than one encoding on unix is already a reality, there's nothing 
> to stop someone setting LANG=de_DE.UTF-8 and LC_MESSAGES=C say.

Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
the encoding. Example:

$ LANG=de_DE.iso88591 LC_MESSAGES=fr_FR.UTF-8 python -c 'import os, 
locale; locale.setlocale(locale.LC_ALL, ""); 
print(locale.getpreferredencoding(), repr(os.strerror(23)))'
('ISO-8859-1', "'Trop de fichiers ouverts dans le syst\\xe8me'")

$ LANG=de_DE.UTF-8 LC_MESSAGES=fr_FR.UTF-8 python -c 'import os, locale; 
locale.setlocale(locale.LC_ALL, ""); 
print(locale.getpreferredencoding(), repr(os.strerror(23)))'
('UTF-8', "'Trop de fichiers ouverts dans le syst\\xc3\\xa8me'")

 > The real lesson is not that having more than one encoding
 > is dangerous, but that having incompatible encodings is dangerous.

Yes, and ASCII and UTF-8 are incompatible. ASCII is unable to decode an 
UTF-8 encoded string.

 > Expanding the filesystem default encoding to utf-8
 > should be a very narrow change, mostly just affecting io
 > and os operations.

It affects everything because filenames are used everywhere.

 > On modern systems, this problem is solved by making the
 > standard encoding UTF-8.  So it is unfortunate that, when
 > no locale is set, Python3 defaults to ascii for the filesystem.

Python doesn't invent an encoding: ASCII is the result of 
nl_langinfo(CODESET). Example:

$ python3 -c "import locale; print(locale.nl_langinfo(locale.CODESET))"
UTF-8
$ LANG=C python3 -c "import locale; 
print(locale.nl_langinfo(locale.CODESET))"
ANSI_X3.4-1968

 >> $ LANG=C python3 -c "import os; print(os.listdir())"
 >> ['h\udcc3\udca9h\udcc3\udca9']

 > It's possible to work around this in some cases, such as listdir,
 > by coping with the result including some byte strings, and then
 > manually decoding them.  But there are, iirc, other cases where
 > the call just fails and there is no easy workaround.

In Python 3, os.listdir(str) *CANNOT* fail because of a Unicode decode 
error thanks to the PEP 393. In Python 2, it works differently (return 
the raw bytes filename if decoding fails).

 > Windows and Mac have annoying bugs too, even bugs specifically
 > about Unicode.

Windows supports Unicode since Windows 95 and fully support all Unicode 
characters since Windows 2000.

Mac enforces UTF-8. For example, it is not possible to *create* a 
filename with invalid UTF-8 name. It looks like it always use UTF-8 on 
the command line.

On Linux, we cannot rely on anything except of the locale encoding. We 
try to use Unicode API when it's possible (e.g. use wcstime() instead of 
strftime()), but quite all functions use byte strings and so rely on the 
locale encoding.

--

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a60a3610a97b by Lars Gustäbel in branch '2.7':
Issue #13639: Accept unicode filenames in tarfile.open(mode="w|gz").
http://hg.python.org/cpython/rev/a60a3610a97b

--
nosy: +python-dev

___
Python tracker 

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

[issue12510] IDLE get_the_calltip mishandles raw strings

[Roger Serwy]

Roger Serwy  added the comment:

The attached patch fixes the bug. The bug occurs in "get_entity" which is used 
to get the object. Then "get_argspec" determines the calltip text. 

The calltip can be prevented for strings by having get_argspec check if the 
object has a "__call__" method. I opted for adding "not callable" to the 
calltip initially for testing, but setting argspec="" will prevent the calltip 
altogether.

--
keywords: +patch
nosy: +serwy
Added file: http://bugs.python.org/file24071/issue12510.patch

___
Python tracker 

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

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[STINNER Victor]

STINNER Victor  added the comment:

> By default the Python SSL/TLS Stack (client/server) expose
> unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).

If there is a problem, it should not be fixed in Python, but in the underlying 
library (OpenSSL) or in applications. Python only exposes features of the 
OpenSSL library. You should not see Python as an application but as a language: 
Python doesn't know what is your use case, or if you write a client or a server.

I suppose that OpenSSL has good reasons to still support weak algorithms like 
MD4 or SSLv2. Some operating systems, like Debian Sid, disable SSLv2 in the 
OpenSSL at the compilation.

If you consider that it is too complex to change the cipher list in a high 
level API (like http.client?), we may a ssl.DEFAULT_CIPHERS to allow an 
application to change the *default* cipher list.

SSLContext() requires a protocol, I suppose that the protocol is also by 
OpenSSL used in the negociation of the cipher list.

If we change the default behaviour, we should allow the user to get back the 
old behaviour (e.g. mark ssl._DEFAULT_CIPHERS as public in 
default_ciphers.patch).

--

IMO this issue is more a documentation issue: we should add a warning in the 
ssl module documentation, and maybe also in the documentation of modules using 
the ssl module (as we done for certificates for HTTPS).

--
nosy: +haypo

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[STINNER Victor]

STINNER Victor  added the comment:

+ self.name = self.name.encode("iso-8859-1", "replace")

Why did you chose ISO-8859-1? I think that the filesystem encoding should be 
used instead:

-self.name = self.name.encode("iso-8859-1", "replace")
+self.name = self.name.encode(ENCODING, "replace")

--
nosy: +haypo

___
Python tracker 

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

[issue8604] Adding an atomic FS write API

[STINNER Victor]

STINNER Victor  added the comment:

> I'm not sure about the best module to host this, though: os.path ?

Some OS don't provide atomic rename. If we only define a function when it is 
atomic (as we do in the posix module, only expose functions available on the 
OS), programs will have to write two versions of their function. I prefer to 
write a "best-effort" function, and so I consider that shutil is the best place 
for such function.

If this function requires a function specific to the OS, the specific function 
can be added to posix (or another module).

Example:

with shutil.write_file(filename) as f:
  f.write("I hope it will be atomic!")

We need an "atomic rename file" function to implement "atomic write file": see 
#8828.

--

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Lars Gustäbel]

Lars Gustäbel  added the comment:

See http://bugs.python.org/issue11638#msg150029

--

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[STINNER Victor]

STINNER Victor  added the comment:

"The gzip format (defined in RFC 1952) allows storing the original filename 
(without the .gz suffix) in an additional field in the header (the FNAME 
field). Latin-1 (iso-8859-1) is required."

Hum, it looks like the author of the gzip program (on Linux Fedora 16) didn't 
read the RFC!

$ tar -cvf hého.tar README
README
$ gzip hého.tar 
$ hachoir-urwid ~/prog/python/default/hého.tar.gz 
0) file:/home/haypo/prog/python/default/hého.tar.gz: ...
   0) signature= "\x1f\x8b": GZip file signature (\x1F\x8B) (2 bytes)
   2) compression= deflate: Compression method (1 byte)
   3.0) is_text= False: File content is probably ASCII text (1 bit)
   3.1) has_crc16= False: Header CRC16 (1 bit)
   3.2) has_extra= False: Extra informations (variable size) (1 bit)
   3.3) has_filename= True: Contains filename? (1 bit)
   3.4) has_comment= False: Contains comment? (1 bit)
   3.5) reserved[0]=  (3 bits)
   4) mtime= 2011-12-21 19:34:54: Modification time (4 bytes)
   8.0) reserved[1]=  (1 bit)
   8.1) slowest= False: Compressor used maximum compression (slowest) (1 bit)
   8.2) fastest= False: Compressor used the fastest compression (1 bit)
   8.3) reserved[2]=  (5 bits)
   9) os= Unix: Operating system (1 byte)
   10) filename= "hého.tar": Filename (10 bytes)

Raw display:

   10) filename= "h\xc3\xa9ho.tar\0": Filename (10 bytes)

--

___
Python tracker 

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

[issue13643] 'ascii' is a bad filesystem default encoding

[Martin]

Martin  added the comment:

> Nope. The locale encoding is chosen using LC_ALL, LC_CTYPE or LANG 
> variable: use the first non-empty variable. LC_MESSAGES doesn't affect 
> the encoding. Example:

That's good to know, thanks. Only leaves the case where setlocale is called 
again with a different value.

> Yes, and ASCII and UTF-8 are incompatible. ASCII is unable to decode an 
> UTF-8 encoded string.

I think we're envisioning different things here.

  os.stat("\u2601") # with LANG=C
current -> UnicodeEncodeError
changed -> works if utf-8 encoded file exists

  os.listdir() # with LANG=C
current -> returns non-ascii as unicode with funky surrogates
changed -> returns non-utf-8 as unicode with funky surrogates

> It affects everything because filenames are used everywhere.

But currently everything handling filenames as unicode on nix needs to worry 
about surrogates (that can't be encoded as ascii) already, or it will still be 
passing values that can't be interpreted by other processes as you highlighed 
earlier. Making utf-8 names come out correctly rather than as surrogates 
doesn't seem like it increases the burden.

--

___
Python tracker 

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

[issue13643] 'ascii' is a bad filesystem default encoding

[STINNER Victor]

STINNER Victor  added the comment:

> it will still be passing values that can't be
> interpreted by other processes as you highlighed earlier.

On UNIX, data going outside Python has be be encoded: you pass byte strings, 
not directly Unicode. Surrogates are encoded back to original bytes.

Example:

>>> b'a\xff'.decode('ascii', 'surrogateescape')
'a\udcff'
>>> b'a\xff'.decode('ascii', 'surrogateescape').encode('ascii', 
>>> 'surrogateescape')
b'a\xff'

--

___
Python tracker 

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

[issue9016] IDLE won't launch (Win XP)

[Roger Serwy]

Roger Serwy  added the comment:

Is this still a problem?

--
nosy: +serwy

___
Python tracker 

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

[issue6528] builtins colored as keyword at beginning of line

[Roger Serwy]

Roger Serwy  added the comment:

The attached patch excludes keywords from the builtin list and corrects the 
highlighting configuration panel.

--
keywords: +patch
nosy: +serwy
versions: +Python 3.2, Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file24072/issue6528.patch

___
Python tracker 

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

[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x

[Geoffrey Bache]

Geoffrey Bache  added the comment:

Thanks.

I'm not sure what you've written about the "-u" flag is correct though 
currently. From experimenting I believe it changes buffering of stdout and 
stderr to line-buffering also when directed to file, i.e. it does affect the 
behaviour of the text-layer.

Some other changes might be needed also, but perhaps they should wait until we 
know whether issue13601 will be accepted.

--

___
Python tracker 

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

[issue8093] IDLE processes don't close

[Roger Serwy]

Roger Serwy  added the comment:

This issue should be closed since issue12540 fixes it.

I verified that the bug exists with 3.1.4 on Vista. It does not exist with 
3.2.2 on Vista.

--
nosy: +serwy

___
Python tracker 

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

[issue8820] IDLE not launching correctly

[Roger Serwy]

Roger Serwy  added the comment:

Is this still a problem with 2.7?

--
nosy: +serwy

___
Python tracker 

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

[issue11829] inspect.getattr_static code execution with meta-metaclasses

[Andreas Stührk]

Andreas Stührk  added the comment:

As the test demonstrates, it's still possible to trigger a dynamic lookup 
without the patch, hence I think this is still needed and valid, yes.

I updated the patch to make it reflect the latest committed changes.

--
Added file: http://bugs.python.org/file24073/getattr_static_metaclasses_v2.patch

___
Python tracker 

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

[issue7883] CallTips.py _find_constructor does not work

[Roger Serwy]

Roger Serwy  added the comment:

The patch works for me as well against 3.3a0. 

Are there any cases where "__init__.__func__" would work?

--
nosy: +serwy
versions: +Python 3.3

___
Python tracker 

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

[issue13078] Python Crashes When Saving Or Opening

[Roger Serwy]

Roger Serwy  added the comment:

Is this still an issue?

Ash, can you please run IDLE from the command line and report the error message 
from there?

   cd c:\python32
   python -m idlelib.idle

--
nosy: +serwy

___
Python tracker 

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

[issue10079] idlelib for Python 3 with Guilherme Polo GSoC enhancements

[Roger Serwy]

Roger Serwy  added the comment:

The large patch also contains the same patch in issue6649.

--

___
Python tracker 

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

[issue13643] 'ascii' is a bad filesystem default encoding

[R. David Murray]

R. David Murray  added the comment:

> But currently everything handling filenames as unicode on
> nix needs to worry about surrogates (that can't be encoded
> as ascii) already, or it will still be passing values that
> can't be interpreted by other processes as you highlighed
> earlier. Making utf-8 names come out correctly rather than
> as surrogates doesn't seem like it increases the burden.

And that is *exactly* the problem.  You can't assume that those other programs 
are expecting utf-8 on unix.  The only thing you have to go by is the locale.  
So that's what we use.  And as Haypo pointed out, unless you manipulate it file 
system stuff gets turned back into the same bytes when it exits Python, so 
pre-existing stuff should work fine.

Now, if posix (or a given unix platform, like OS X did) would say "utf-8 is the 
standard filesystem and program interchange encoding", we could change Python.  
Short of that, it is our experience that using anything other than locale leads 
to more problems than using locale does.

--

___
Python tracker 

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

[issue9150] IDLE should not save trailing whitespace after strip trailing whitespace has been used

[Roger Serwy]

Roger Serwy  added the comment:

Is this still an issue?

--

___
Python tracker 

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