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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: closed -> open

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

> Perhaps we should make these algorithms build conditional?  Are these
> patent issues of concern to us?

Well, if RedHat used the "standard" OPENSSL_NO_ECDH flag, it's easy
enough to fix compilation of the ssl module.

--

___
Python tracker 

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

[issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line.

[Petri Lehtinen]

Petri Lehtinen  added the comment:

What's the status of this issue?

FWIW, this is not only a problem with east asian characters:

>>> ä äää
  File "", line 1
ä äää
^
SyntaxError: invalid syntax

--
nosy: +petri.lehtinen
versions: +Python 3.2, Python 3.3 -Python 3.0

___
Python tracker 

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

[issue6321] Reload Python modules when running programs

[Ned Deily]

Changes by Ned Deily :


--
resolution: out of date -> duplicate
stage:  -> committed/rejected
superseder:  -> IDLE/Win Installer: drop -n switch for 2.7/3.1; install 3.1 as 
idle3

___
Python tracker 

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

[issue4691] IDLE Code Caching Windows

[Ned Deily]

Changes by Ned Deily :


--
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> IDLE/Win Installer: drop -n switch for 2.7/3.1; install 3.1 as 
idle3
versions: +Python 2.7, Python 3.1 -Python 2.6

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

[maniram maniram]

maniram maniram  added the comment:

Oops, to reproduce this bug after running the code run "recurse()".

--

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

[maniram maniram]

maniram maniram  added the comment:

But Python 2 doesn't crash after running the code.

--

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

Python isn't crashing; it's bailing out of an impossible situation. It's not 
clear what the correct behavior is, since you're basically preventing Python 
from aborting the recursive behavior.

--
nosy: +benjamin.peterson

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

[maniram maniram]

Changes by maniram maniram :


--
title: Python 3 crashes with this code. -> Python 3 crashes (segfaults) with 
this code.

___
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 with this code.

[maniram maniram]

Changes by maniram maniram :


--
title: Python crashes with this code. -> Python 3 crashes with this code.

___
Python tracker 

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

[issue13644] Python crashes with this code.

[maniram maniram]

New submission from maniram maniram :

When you run the following code, Python 3 (not Python 2) crashes.
Interestingly, Python 2.7 doesn't seem to be affected and correctly raises an 
error about recursion ( so this must be a regression ).
The code's recursion should be detected and Python should raise a RuntimeError 
about recursion.

def recurse():
try:raise Exception #An arbitary exception
except Exception:recurse()

After running this code Python 3 says "Fatal Python error: Cannot recover from 
stack overflow." and then Python aborts .
In Jython, this code doesn't crash it.

--
components: Interpreter Core
messages: 149956
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Python crashes with this code.
type: crash
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

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

[Meador Inge]

Meador Inge  added the comment:

ECC is *not* available in the OpenSSL package provided on RedHat systems.  
RedHat intentionally strips it due to patent concerns 
(http://en.wikipedia.org/wiki/ECC_patents).  Therefore committing this work 
made it much more difficult to build the ssl module on RedHat systems.

I couldn't find a clear statement of this in any RedHat documentation, but I 
did find a few references to the stripping in these places:

   * https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=623483
   * 
https://www.martineve.com/2011/07/22/using-elliptical-curve-cryptography-in-openssh/
   * https://bugzilla.redhat.com/show_bug.cgi?id=615372

Perhaps we should make these algorithms build conditional?  Are these patent 
issues of concern to us?

--
nosy: +meador.inge

___
Python tracker 

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

[issue8098] PyImport_ImportModuleNoBlock() may solve problems but causes others.

[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

[issue8098] PyImport_ImportModuleNoBlock() may solve problems but causes others.

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

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

[Nick Coghlan]

Nick Coghlan  added the comment:

The thing that most appeals to me with this concept is moving closer to making 
it possible to experiment with generator-style functionality in *extension* 
modules (albeit extension modules that are coupled to private CPython APIs). 
So, for me, "not worse than the status quo" would be the main thing I'd be 
looking for out of any micro-benchmarks.

However, that also makes me question the movement of the "why_exit" from the 
frame to the tstate - having it on the thread state is significantly less 
flexible when it comes to experimenting with execution models.

The move from orthogonal bit flags in a dedicated enum to int fields and macro 
definitions also seems like a completely unnecessary pessimisation.

--

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

[Meador Inge]

Meador Inge  added the comment:

With the new patch I see no benefits on the same micro-benchmarks you posted 
(it is even slower for the smaller case) on a quad-core 64-bit F15 box:

BEFORE:

$ ./python -mtimeit "def y(n):" "  for x in range(n):" "yield  x" 
"sum(y(10))"
100 loops, best of 3: 1.33 usec per loop
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "yield  x" 
"sum(y(100))"
10 loops, best of 3: 66 msec per loop

AFTER:

$ ./python -mtimeit "def y(n):" "  for x in range(n):" "yield  x" 
"sum(y(10))"
100 loops, best of 3: 1.45 usec per loop
$ ./python -mtimeit "def y(n):" "  for x in range(n):" "yield  x" 
"sum(y(100))"
10 loops, best of 3: 65.8 msec per loop

--

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

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The standard encoding is UTF-8.

How so? I don't know of any Linux or Unix spec which says so. If you get
the Linux heads to standardize this then I'll certainly be very happy
(and countless others will, too). But AFAIK this it not the case and I
don't see why you are asking Python to make a choice that OS vendors
refuse to make. You are certainly asking the wrong project to solve this
problem. So I'd rather not solve your problem at the Python level so
that you instead try to get it solved at the right (OS) level.

--

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

Martin Pool  added the comment:

On 21 December 2011 12:16, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> So, you're complaining about something which works, kind of:
>
> $ touch héhé
> $ 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.

It wasn't impossible to get unicode right in python2, but python3
still thinks it's worth changing things to make it work better.

>> This makes robustly working with non-ascii filenames on different
>> platforms needlessly annoying, given no modern nix should have problems
>> just using UTF-8 in these cases.
>
> So why don't these supposedly "modern" systems at least set the appropriate 
> environment variables for Python to infer the proper character encoding?
> (since these "modern" systems don't have a well-defined encoding...)

The standard encoding is UTF-8.  Python shouldn't need to have a
variable set to tell it this.  Python is making an assumption about
the default but it is a bad assumption.

> The culprit is not Python, it's the Unix crap

Programs need to work with the environments that are available to
them, even though those environments often have flaws.  Windows and
Mac have annoying bugs too, even bugs specifically about Unicode.

--

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

Martin Pool  added the comment:

Thanks for the example.

Like you say, realistically, all data exchanged with other programs
and with the system needs to be in the same encoding.  (User document
content may be in something else.)

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.

With no locale set, python3 makes getdefaultencoding() utf-8, so it
seems oddly pessimistic to make the fsencoding only ascii.

If someone really wants to run everything in iso-8859-1 this patch
would not stop them doing so.

--

___
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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

So, you're complaining about something which works, kind of:

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

> This makes robustly working with non-ascii filenames on different
> platforms needlessly annoying, given no modern nix should have problems
> just using UTF-8 in these cases.

So why don't these supposedly "modern" systems at least set the appropriate 
environment variables for Python to infer the proper character encoding?
(since these "modern" systems don't have a well-defined encoding...)

Answer: because they are not modern at all, they are antiquated, inadapted and 
obsolete pieces of software designed and written by clueless Anglo-American 
people. Please report bugs against these systems. The culprit is not Python, 
it's the Unix crap and the utterly clueless attitude of its maintainers 
("filesystems are just bytes", yeah, whatever...).

--
nosy: +pitrou

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

> During 1 month, we had PYTHONFSENCODING environment variable. It was not a
> good idea.

I strongly agree. There is no sense in having a separate configurable value, 
anyone who would think about using a PYTHONFSENCODING should just change their 
locale instead. However, avoiding the need for manual intervention completely 
in a relatively narrow set of cases is still useful.

> Not after Python start. Using two encodings at the same would just adds new
> problems. On UNIX (at least on Linux?), it is mandatory to use the same
> encoding for:
>
>  - command line arguments
>  - environment variables
>  - filenames
>  - and more generally, all data exchanged with the system and other programs

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.

The real lesson is not that having more than one encoding is dangerous, but 
that having incompatible encodings is dangerous. As 'ascii' is a strict subset 
of 'utf-8' the cross process communication issues are greatly lessened, at 
worst stuff just breaks still.

Expanding the filesystem default encoding to utf-8 should be a very narrow 
change, mostly just affecting io and os operations. Other actions involving 
paths will still break if a non-ascii string is used, but without the 
possibility of mangling data.

--

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

I should not write comments so late :-p

> Not after Python start. Using two encodings at the same would just ...

at the same time

 > ... because I would like to inconsistency.

because it would lead to inconsistencies

--

___
Python tracker 

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

[issue13619] Add a new codec: "locale", the current locale encoding

[STINNER Victor]

STINNER Victor  added the comment:

I would be possible to implement incremental decoder with mbsrtowcs() and 
incremental encoder with wcsrtombs(), by serializing mbstate_t to a long 
integer (TextIOWrapper.tell() does something like that). The problem is that 
mbsrtowcs() and wcsrtombs() are "recent" (not always available). It may also be 
dangerous to allow the user to pass an arbitrary mbstate_t (using .setstate()).

--

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

I checked the submitted patches from the issues against the large patch by eye. 
Guilherme's patches in these separate issues have the same contents: 
issue1207589, issue1612262, issue1721083, issue6699, issue3359.

The large patch updates issue964437, but the "view_file" change is outdated. 

I wrote more recent patches for issue4832 and issue6698.

--

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

> The main problem I see being discussed is that
> changing the encoding after Python starts would
> be dangerous, which I agree with, but we're not
> proposing to do that.

Not after Python start. Using two encodings at the same would just adds new 
problems. On UNIX (at least on Linux?), it is mandatory to use the same 
encoding for:

 - command line arguments
 - environment variables
 - filenames
 - and more generally, all data exchanged with the system and other programs

Let's take an example: you use UTF-8 for filenames and ISO-8859-1 for all other 
data. You want to check if a specific filename is present in your home 
directory: encode the filename to UTF-8 and read the home directory from the 
HOME environment variable. But environment variables are decoded from 
ISO-8859-1, so you have to encode them back to ISO-8859-1 to avoid mojibake 
(and real bugs, like file not found).

Ok, let say that filenames and environment variables are UTF-8 and that other 
data are ISO-8859-1. You would like to play a MP3 using mplayer: you pass the 
filename encoded to UTF-8 as an argument of mplayer command line. But mplayer 
uses ISO-8859-1 to decode its command line (it's not exactly like that, but 
image that it's the case): mplayer will be unable to find your MP3.

etc.

That's why on UNIX there is one unique encoding, the locale encoding, and that 
Python uses the same encoding (called "the filesystem encoding", I don't like 
this name, sys.getfilesystemencoding()).

--

It is no more possible to change the Python filesystem encoding at runtime (I 
remove sys.setfilesystemencoding()) because I would like to inconsistency. If 
you decoded a filename before changing the encoding, and then you decode the 
same filename after changing the encoding: you will get two different names and 
encode the filenames back will give you two different byte sequences (and more 
likely, a Unicode encode error).

It was possible to override the filesystem encoding using a PYTHONFSENCODING 
environment variable, but it introduced all the inconsistencies listed before 
(especially with external programs).

Now the only right way to change the Python (filesystem) encoding is the UNIX 
way of doing that: set LC_ALL, LC_CTYPE or LANG environment variable (configure 
your locale).

--

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

Martin Pool  added the comment:

On 21 December 2011 11:26, STINNER Victor  wrote:
> I never checked which locale is used by default for programs called by cron. 
> So I checked: on Fedora 16, programs start with a very few environment 
> variables, and LANG and LC_ALL are not set. You can add "LANG=fr_FR.UTF-8" 
> (for example) to /etc/environment to set the default language for the whole 
> system (for all programs). I checked, it works with cron. Or if you don't 
> want to affect all programs, it is maybe safer to only set the locale for one 
> specific program in your crontab by adding "LANG=fr_FR.UTF-8 " before you 
> command. Example:
>
> * *  *  *  * LANG=fr_FR.UTF-8 /home/haypo/test.sh

That is the correct kind of configuration.  When I say it scales
poorly I mean that every user running a Python program on a unicode
system needs to insert this configuration in every relevant place, and
they need to work this out from what is typically a fairly cryptic
message.  (bzr just added a workaround for this, but for other
programs it still exists.)

Also, my other point, is that people may very well want their cron
scripts to send ascii output but cope with unicode filenames.

--

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

Martin Pool  added the comment:

On 21 December 2011 11:01, STINNER Victor  wrote:
>
> Again: please read the discussion (in closed issues) explaing why we removed 
> it (and which problems it introduced).

There's a lot of history, so I'm not sure exactly which problems
you're referring to.  The main problem I see being discussed is that
changing the encoding after Python starts would be dangerous, which I
agree with, but we're not proposing to do that.

--

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

> There are two problems with this: one is just the practical
> one that it scales poorly to have to tell every user to do this
> and to take them through working out how to set this in a way
> that covers cron jobs, daemons, things run over ssh, etc.

I never checked which locale is used by default for programs called by cron. So 
I checked: on Fedora 16, programs start with a very few environment variables, 
and LANG and LC_ALL are not set. You can add "LANG=fr_FR.UTF-8" (for example) 
to /etc/environment to set the default language for the whole system (for all 
programs). I checked, it works with cron. Or if you don't want to affect all 
programs, it is maybe safer to only set the locale for one specific program in 
your crontab by adding "LANG=fr_FR.UTF-8 " before you command. Example:

* *  *  *  * LANG=fr_FR.UTF-8 /home/haypo/test.sh

--


If you want to handle any filename without having to care of the locale, the 
simplest solution is to use the bytes type to store filenames.

--

___
Python tracker 

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

[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open

[Marco Scataglini]

Marco Scataglini  added the comment:

Well I checked 'SearchBar' IDLE extension and is not bad... has some minor 
bugs, nothing major just very very minor quirky behavior, but nothing that 
seems to impair functionality AFAIK.
It should be cleaned up and added to release in place of the existing 
non-functional one.
Just my 2c, of course.

--

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

> If there was a separate LC_FILENAMES then Python could respect
> that and insist people set it, but there isn't.

During 1 month, we had PYTHONFSENCODING environment variable. It was not a good 
idea. Again: please read the discussion (in closed issues) explaing why we 
removed it (and which problems it introduced).

--

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

Martin Pool  added the comment:

> I'm not sure why having a locale set to C or something invalid should be 
> considered a Python bug. 

Programs like bzr that hit these problems can tell their users, either in the 
docs or an error message, "change your locale to a UTF-8 one".

There are two problems with this: one is just the practical one that it scales 
poorly to have to tell every user to do this and to take them through working 
out how to set this in a way that covers cron jobs, daemons, things run over 
ssh, etc.

The other problem is that the locale variables primarily describe the locale 
for input/output, and that can very reasonably be different from the filesystem 
encoding.  As a specific common example people may have UTF-8 filenames but 
want a C locale terminal.  If there was a separate LC_FILENAMES then Python 
could respect that and insist people set it, but there isn't.

--
nosy: +poolie

___
Python tracker 

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

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

resolved as wont fix, because its not python's fault :)

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Hey, you found it!
PySide::DynamicSlotDataV2::callback() calls PyMethod_New() without getting the 
GIL.  The Python allocator is not thread-safe, operations are supposed to be 
serialized by this Global Interpreter Lock.

I suggest to modify this DynamicSlotDataV2::callback() and add the line 
"Shiboken::GilState gil;" at the beginning of the function.

--

___
Python tracker 

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

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

I think I have found the problem! I took a closer look at the Fatal error core:

#0  0xb76fe424 in __kernel_vsyscall ()
#1  0xb740ccb1 in *__GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb740e3f2 in *__GI_abort () at abort.c:92
#3  0xb766193f in Py_FatalError (msg=0xb76949de "GC object already tracked")
at Python/pythonrun.c:1670
#4  0xb7595a3a in PyMethod_New (func=, self=
, 
reactor=<...>, o=14) at remote 0x93f3dac>, threadCallQueue=[(, (0,), {})], _cancellations=0, _justStopped=False, 
_newTimedCalls=[], _pendingTimedCalls=[, seconds=, args=(), 
canceller=, delayed_time=0, kw={}, 
func=, _expectNextCallAt=, f=, 
deferred=, None, None), (, (...), {}))]) 
at remote 0x96da0cc>, running=True, kw={}, starttime=, call=<...>, _runAtStart=True) at remote 0x96d776c>, time=, cancelled=0, called=0) at remote 0x9d1184c>, 
,
  seconds=) at Objects/classobject.c:2250
#5  0xb6c71225 in PySide::DynamicSlotDataV2::callback (this=0x96b6440)
at 
/var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-qt4.7+1.0.9/libpyside/globalreceiverv2.cpp:129
#6  0xb6c718fc in PySide::GlobalReceiverV2::qt_metacall (this=0x9519b88, 
call=QMetaObject::InvokeMetaMethod, id=5, args=0xbffbeef4)
at 
/var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-qt4.7+1.0.9/libpyside/globalreceiverv2.cpp:289
#7  0xb6ab76a7 in QMetaObject::metacall (object=0x9519b88, 
cl=QMetaObject::InvokeMetaMethod, 
idx=5, argv=0xbffbeef4) at kernel/qmetaobject.cpp:237
#8  0xb6ac9b8c in QMetaObject::activate (sender=0x9760e40, m=0xb6c5d644, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3278
#9  0xb6b21b27 in QTimer::timeout (this=0x9760e40) at 
.moc/debug-shared/moc_qtimer.cpp:128
#10 0xb6acfb01 in QTimer::timerEvent (this=0x9760e40, e=0xbffbf41c) at 
kernel/qtimer.cpp:271
#11 0xb6e35efb in QTimerWrapper::timerEvent (this=0x9760e40, arg__1=0xbffbf41c)
at 
/var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-1.0.9_build/PySide/QtCore/PySide/QtCore/qtimer_wrapper.cpp:233
#12 0xb6ac2e67 in QObject::event (this=0x9760e40, e=0x6) at 
kernel/qobject.cpp:1181
#13 0xb6e37717 in QTimerWrapper::event (this=0x9760e40, arg__1=0xbffbf41c)
at 
/var/tmp/portage/dev-python/pyside-1.0.9/work/pyside-1.0.9_build/PySide/QtCore/PySide/QtCore/qtimer_wrapper.cpp:164


If this would explain the update_refs lock up then I will close this bug... (i 
also opening on on pyside)

--

___
Python tracker 

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

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

This also looks familiar:
http://bytes.com/topic/python/answers/36901-fatal-error-gc-object-already-tracked
"semi-randomly locks somewhere outside my C-code (after returning to
python), and semi-randomly issues a "Fatal error: GC object already
tracked... "
Someone replies with:
"... should be calling PyObject_GC_UnTrack before doing anything else..."

So, perhaps one of the extensions is not calling PyObject_GC_UnTrack? but I 
need to know which one to go further...

--

___
Python tracker 

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

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

I have 10 identical test machines running this this code ( operating systems 
are cloned ). I am not usning valgrind in these tests, it was causing various 
issues...

(gdb) info sharedlibrary
>FromTo  Syms Read   Shared Object Library
0xb75a02b0  0xb76baa38  Yes /usr/lib/libpython2.7.so.1.0
0xb75695a0  0xb7575878  Yes /lib/libpthread.so.0
0xb7422060  0xb7529374  Yes /lib/libc.so.6
0xb7404bd0  0xb7405b28  Yes /lib/libdl.so.2
0xb73ffbc0  0xb7400498  Yes /lib/libutil.so.1
0xb73dd360  0xb73f7e58  Yes /lib/libm.so.6
0xb77288d0  0xb773f97f  Yes /lib/ld-linux.so.2
0xb7721310  0xb77226d8  Yes /usr/lib/python2.7/lib-dynload/time.so
0xb728c130  0xb728e4b8  Yes 
/usr/lib/python2.7/site-packages/zope/interface/_zope_interface_coptimizations.so
0xb7284060  0xb7286cf8  Yes /usr/lib/python2.7/lib-dynload/strop.so
0xb72772a0  0xb727d648  Yes /usr/lib/python2.7/lib-dynload/_socket.so
0xb7271c50  0xb72729e8  Yes /usr/lib/python2.7/lib-dynload/_functools.so
0xb726a7d0  0xb726deb8  Yes /usr/lib/python2.7/lib-dynload/_ssl.so
0xb721ec00  0xb7253f28  Yes /usr/lib/libssl.so.1.0.0
0xb70f47c0  0xb71d3dd8  Yes /usr/lib/libcrypto.so.1.0.0
0xb70a3b20  0xb70af7b8  Yes /lib/libz.so.1
0xb7264130  0xb72653c8  Yes /usr/lib/python2.7/lib-dynload/cStringIO.so
0xb709aab0  0xb709e108  Yes /usr/lib/python2.7/lib-dynload/_struct.so
0xb70934c0  0xb70958a8  Yes /usr/lib/python2.7/lib-dynload/operator.so
0xb708b7e0  0xb708e868  Yes 
/usr/lib/python2.7/lib-dynload/_collections.so
0xb707db00  0xb7083dd8  Yes /usr/lib/python2.7/lib-dynload/itertools.so
0xb725f7d0  0xb725ff98  Yes /usr/lib/python2.7/lib-dynload/_bisect.so
0xb7077920  0xb7078ee8  Yes /usr/lib/python2.7/lib-dynload/_heapq.so
0xb7073970  0xb7074028  Yes /usr/lib/python2.7/lib-dynload/grp.so
0xb771d510  0xb771d6f8  Yes 
/usr/lib/python2.7/site-packages/twisted/python/_initgroups.so
0xb7062bf0  0xb706d3f8  Yes /usr/lib/python2.7/lib-dynload/datetime.so
0xb705ab90  0xb705d358  Yes /usr/lib/python2.7/lib-dynload/binascii.so
0xb7055a00  0xb7057018  Yes /usr/lib/python2.7/lib-dynload/fcntl.so
0xb704d9a0  0xb7051258  Yes /usr/lib/python2.7/lib-dynload/math.so
0xb7046e80  0xb7047d48  Yes /usr/lib/python2.7/lib-dynload/_hashlib.so
0xb7042d90  0xb7043d78  Yes /usr/lib/python2.7/lib-dynload/_random.so
0xb703c460  0xb703e548  Yes /usr/lib/python2.7/lib-dynload/select.so
0xb7036360  0xb7036e18  Yes /usr/lib/python2.7/lib-dynload/termios.so
0xb7032660  0xb7032968  Yes 
/usr/lib/python2.7/site-packages/twisted/internet/_sigchld.so
0xb6ce7930  0xb6ed3188  Yes 
/usr/lib/python2.7/site-packages/PySide/QtCore.so
0xb6c903b0  0xb6ca3b58  Yes /usr/lib/libpyside-python2.7.so.1.0
0xb7016230  0xb7023058  Yes /usr/lib/libshiboken-python2.7.so.1.0
0xb69ba370  0xb6b4c358  Yes /usr/lib/qt4/libQtCore.so.4
0xb68cd7e0  0xb693dac8  Yes 
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/libstdc++.so.6
0xb686a390  0xb6880a18  Yes 
/usr/lib/gcc/i686-pc-linux-gnu/4.5.3/libgcc_s.so.1
0xb6860e90  0xb68655c8  Yes /lib/librt.so.1
---Type  to continue, or q  to quit---
0xb5d81c30  0xb65d9cf8  Yes 
/usr/lib/python2.7/site-packages/PySide/QtGui.so
0xb54d9e50  0xb5ba8a38  Yes /usr/lib/qt4/libQtGui.so.4
0xb5394b80  0xb53b0a58  Yes /usr/lib/libpng15.so.15
0xb5315a80  0xb5377748  Yes /usr/lib/libfreetype.so.6
0xb5305910  0xb530a278  Yes /usr/lib/libSM.so.6
0xb52eee00  0xb52fddd8  Yes /usr/lib/libICE.so.6
0xb52e3740  0xb52e8be8  Yes /usr/lib/libXrender.so.1
0xb52db5c0  0xb52dfa48  Yes /usr/lib/libXrandr.so.2
0xb52b0f50  0xb52ca548  Yes /usr/lib/libfontconfig.so.1
0xb529f220  0xb52a8e98  Yes /usr/lib/libXext.so.6
0xb519b580  0xb5220388  Yes /usr/lib/libX11.so.6
0xb5173200  0xb5181a38  Yes /lib/libbz2.so.1
0xb5151580  0xb5167338  Yes /usr/lib/libexpat.so.1
0xb513e0c0  0xb514b988  Yes /usr/lib/libxcb.so.1
0xb5131b60  0xb51328b8  Yes /usr/lib/libXau.so.6
0xb512c0f0  0xb512dab8  Yes /usr/lib/libXdmcp.so.6
0xb50417e0  0xb50f0cf8  Yes 
/usr/lib/python2.7/site-packages/PySide/QtNetwork.so
0xb4f13ff0  0xb4fd6f18  Yes /usr/lib/qt4/libQtNetwork.so.4
0xb702d1e0  0xb702ebd8  Yes /usr/lib/python2.7/lib-dynload/_locale.so
0xb4ed2ab0  0xb4ee4fa8  Yes 
/usr/lib/python2.7/site-packages/psycopg2/_psycopg.so
0xb4ea7d90  0xb4ebe638  Yes (*) /usr/lib/libpq.so.5
0xb4e8fc90  0xb4e9da98  Yes /usr/lib/python2.7/lib-dynload/cPickle.so
0xb4e84c70  0xb4e89498  Yes /usr/lib/python2.7/lib-dynload/array.so
0xb4e69d90  0xb4e7cb08  Yes /usr/lib/python2.7/lib-dynload/_ctypes.so
0xb4e5f310  0xb4e62638  Yes /usr/lib/libf

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

[Ned Deily]

Ned Deily  added the comment:

Thanks, Roger.  It would also be helpful if you ascertain for the overlaps 
which of the two versions is newer, the individual issue/path or the large 
feature diff.  The relative import changes should not be applied in the 
standard library; they were specifically removed earlier.

--
assignee:  -> ned.deily

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

minor mistake - issue3559 "Pasted \n not same as typed \n"

--

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

I went through the changes in "idlelib20101012_From_r32a3.patch". 

A lot of the changes are for using relative imports. Those changes aside, here 
is a list of issues that this patch covers. Most of these issues already have 
patches that are included in the large patch.

EditorWindow.py, textView.py:
issue964437 - "idle help is modal"

EditorWindow.py, OutputWindow.py, PyShell.py:
issue1207589 - "Right Click Context Menu"

ClassBrowser.py:
patch in issue1612262 - "Class Browser doesn't show internal classes"

FileRevert.py:
patch in issue1721083 - "Add File - Reload"

IOBinding.py:
patch in issue6699 - "IDLE: Warn user about overwriting a file that has a 
newer version on filesystem"
patch in issue4832 - "idle filename extension"

PyShell.py:
- use "subprocess" module - already fixed in issue12540
- patch for "paste_callback" in issue3359 - "Pasted \n not same as typed \n"
- fix for issue6698 "IDLE no longer opens only an edit window when 
configured to do so"
 

There are two major changes that are not covered by other issues (AFAIK). 
1) The "PseudoStderrFile" in PyShell.py brings the shell forward if an error 
occurs. I like this behavior.
2) Run a script without saving it first. This functionality is scattered across 
several files.

There are several other small tweaks in the patch that will need some review. 

If I missed anything, please add a comment.

--
nosy: +serwy

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

> It was already discussed: using a different encoding for filenames and for
> other things is really not a good idea. The main problem is the interaction
> with other programs.

Yes, for many programs, a change like this will mean they create the file, but 
then throw a traceback anyway when trying to print its name to stdout or 
something.

> Read discussion of issues #8622, #8775 and #9992.

Thanks. I agree that spreading different values to things like subprocess 
arguments and the environment is asking for trouble. Just changing how unicode 
filename are encoded by default seems safer, though it certainly won't help all 
code.

> The right fix is to fix your locale, not Python.

I've found that hard to stick to in the face of bug reports where "your locale" 
turns out to be "the locale used by some cronjob". Fixing my library to work 
under LANG=C is easier than bugging every downstream project.

--

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

> I'm not sure why having a locale set to C or something invalid should be
> considered a Python bug.  You have to handle un-decodable filenames no
> matter what you do, since things aren't always encoded in utf-8 on non-OSX
> unix even when that is the system locale.  It's just something you have to
> live with.

This is more about un-encodable filenames. At the moment work with non-ascii 
filenames in Python robustly requires two branches, one using unicode and one 
that encodes to bytestrings and deals with the case where the name can't be 
represented in the declared filesystem encoding. That may be something that 
just had to be lived with, but it's a little annoying when even without a UTF-8 
locale for a particular process, that's what most systems will want on disk.

--
type:  -> behavior

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

> under either the C locale, or with an invalid or missing locale

The right fix is to fix your locale, not Python.

--

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

> Currently when running Python on a non-OSX posix environment
> under either the C locale, or with an invalid or missing locale,
> it's not possible to operate using unicode filenames outside
> the ascii range.

It was already discussed: using a different encoding for filenames and for 
other things is really not a good idea. The main problem is the interaction 
with other programs.

Read discussion of issues #8622, #8775 and #9992.

--
nosy: +haypo

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

I'm not sure why having a locale set to C or something invalid should be 
considered a Python bug.  You have to handle un-decodable filenames no matter 
what you do, since things aren't always encoded in utf-8 on non-OSX unix even 
when that is the system locale.  It's just something you have to live with.

--
nosy: +r.david.murray

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

New submission from Martin :

Currently when running Python on a non-OSX posix environment under either the C 
locale, or with an invalid or missing locale, it's not possible to operate 
using unicode filenames outside the ascii range. Using bytes works, as does 
reading expecting unicode, using the surrogates hack.

This makes robustly working with non-ascii filenames on different platforms 
needlessly annoying, given no modern nix should have problems just using UTF-8 
in these cases.

See the downstream bzr bug for more:


One option is to just use UTF-8 for encoding and decoding filenames when 
otherwise ascii would be used. As a strict superset, this shouldn't break too 
many existing assumptions, and it's unlikely that non-UTF-8 filenames will 
accidentally be mangled due to a locale setting blip. See the attached patch 
for this behaviour change. It does not include a test currently, but it's 
possible to write one using subprocess and overriden LANG and LC_ALL vars.

--
components: Interpreter Core
files: /tmp/filesystem_encoding_utf8.patch
keywords: patch
messages: 149924
nosy: benjamin.peterson, gz
priority: normal
severity: normal
status: open
title: 'ascii' is a bad filesystem default encoding
versions: Python 3.3
Added file: http://bugs.python.org/file24064//tmp/filesystem_encoding_utf8.patch

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

[Hynek Schlawack]

Changes by Hynek Schlawack :


Removed file: http://bugs.python.org/file24062/8a9e14cda106.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.

[Hynek Schlawack]

Changes by Hynek Schlawack :


Added file: http://bugs.python.org/file24063/c02fbcda56f3.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.

[Hynek Schlawack]

Hynek Schlawack  added the comment:

You're right. I've updated the docs accordingly, thanks!

--

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

[Charles-François Natali]

Charles-François Natali  added the comment:

Looks good to me, except for another minor nit:
"""
the elements of the `iterable` are expected to be tuples
"""

AFAICT, you just require the elements of `ìterables` to be iterables, not 
necessarily tuples.

--

___
Python tracker 

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

[issue3905] subprocess failing in GUI applications on Windows

[Christian Häggström]

Changes by Christian Häggström :


--
nosy: +chn

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

[Hynek Schlawack]

Changes by Hynek Schlawack :


Removed file: http://bugs.python.org/file22860/mp-starmap-w-docs.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.

[Hynek Schlawack]

Changes by Hynek Schlawack :


Added file: http://bugs.python.org/file24062/8a9e14cda106.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.

[Hynek Schlawack]

Hynek Schlawack  added the comment:

Thanks for the feedback Antoine!

I updated the patch to latest default tip and added the requested tags to the 
docs.

--
hgrepos: +97

___
Python tracker 

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

[issue13051] Infinite recursion in curses.textpad.Textbox

[Tycho Andersen]

Tycho Andersen  added the comment:

Attached is a patch which contains a testcase as well. A few notes about this 
testcase:

1. I couldn't figure out how to get it to run correctly after all the other 
tests had run, so I had to run it first. This seems lame. One possible fix is 
to run each testcase in curses.wrapper; I'd be happy to change this patch to do 
that if it's more acceptable.

2. This testcase only tests one of the two bugs this patch fixes. The other 
seems much harder to write a testcase for, since you have to have a terminal 
such that curses.LINES * curses.COLUMS > sys.getrecursionlimit(). If there's a 
good way to guarantee this, I'd be happy to write a testcase for it.

Comments are appreciated!

--
Added file: http://bugs.python.org/file24061/textpad-recursion-fix.patch

___
Python tracker 

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

[issue6321] Reload Python modules when running programs

[samwyse]

samwyse  added the comment:

[issue5847] fixed in 2.7/3.1

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue13614] `setup.py register` fails if long_description contains RST

[anatoly techtonik]

anatoly techtonik  added the comment:

s/commit/comment/ sry.

--

___
Python tracker 

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

[issue13614] `setup.py register` fails if long_description contains RST

[anatoly techtonik]

anatoly techtonik  added the comment:

A good analysis of the issue is made by Jason Conti at Ubuntu bug report 
mentioned in the first commit.

--
title: `setup.py register` fails with traceback -> `setup.py register` fails if 
long_description contains RST

___
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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +lars.gustaebel

___
Python tracker 

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

[issue9725] urllib.request.FancyURLopener won't connect to pages requiring username and password

[Joonas Kuorilehto]

Changes by Joonas Kuorilehto :


--
nosy: +joneskoo

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

One nit: the patch needs "versionadded" tags for the two new functions.

--

___
Python tracker 

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

[issue13642] urllib incorrectly quotes username and password in https basic auth

[Joonas Kuorilehto]

New submission from Joonas Kuorilehto :

Reproduction:

>>> import urllib
>>> urllib.urlopen("https://example.com/";)
Enter username for Test Site at example.com: user
Enter password for user in Test Site at example.com: top secret
Enter username for Test Site at example.com:
# If the correct password contains spaces, nothing will be accepted.

The problem is that the password in basic auth is URI quoted and then base64 
encoded. The password should not be quoted.

RFC 2617:
  userid  = *
  password= *TEXT
  base64-user-pass  = 

I traced the problem with Pydev to urllib retry_https_basic_auth where I can 
see that
  user = "user"
  passwd = "my secret password"

After that, the path is like this:
self.retry_https_basic_auth:
  self.open(fullurl="https://user:my%20%secret%20passw...@example.com/";)
  self.open_https(url="://user:my%20%secret%20passw...@example.com/")
  => in open_https:
host, selector = splithost(url)
user_passwd, host = splituser(host)
host = unquote(host)

user_passwd is not unquoted, host is.

I found closely related Issue2244 - but did not confirm where this bug has been 
introduced. I added some people from 2244 to this issue. I hope that is ok.

I think a test should be added that covers usernames and passwords with spaces 
to avoid further regressions. The reproduction code given works with Python 
2.4.3 urllib. This probably also affects python3, did not try.

--
components: Library (Lib)
messages: 149915
nosy: carljm, joneskoo, orsenthil
priority: normal
severity: normal
status: open
title: urllib incorrectly quotes username and password in https basic auth
type: behavior
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

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This looks like a reasonable request to me, and the patch looks generally ok as 
well.

--
nosy: +neologix, pitrou
stage:  -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

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

[issue13637] binascii.a2b_* functions could accept unicode strings

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: open -> closed

___
Python tracker 

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

[issue13637] binascii.a2b_* functions could accept unicode strings

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed now.

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

[issue13641] decoding functions in the base64 module could accept unicode strings

[Antoine Pitrou]

New submission from Antoine Pitrou :

Similarly to #13637 for the binascii module, the decoding functions in the 
base64 module could accept ASCII-only unicode strings.

--
components: Library (Lib)
keywords: easy
messages: 149912
nosy: pitrou
priority: normal
severity: normal
status: open
title: decoding functions in the base64 module could accept unicode strings
type: enhancement
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

[issue13637] binascii.a2b_* functions could accept unicode strings

[Roundup Robot]

Roundup Robot  added the comment:

New changeset eb8d62706d5f by Antoine Pitrou in branch 'default':
Issue #13637: "a2b" functions in the binascii module now accept ASCII-only 
unicode strings.
http://hg.python.org/cpython/rev/eb8d62706d5f

--
nosy: +python-dev

___
Python tracker 

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

[issue11867] Make test_mailbox deterministic

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c9facd251725 by Charles-François Natali in branch '2.7':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/c9facd251725

New changeset 9dee8a095faf by Charles-François Natali in branch '3.2':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/9dee8a095faf

New changeset 9014e0cc5589 by Charles-François Natali in branch 'default':
Followup to issue #11867: Use socketpair(), since FreeBSD < 8 doesn't really
http://hg.python.org/cpython/rev/9014e0cc5589

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Charles-François Natali]

Charles-François Natali  added the comment:

> 1. On FreeBSD, we must assume that every blocking system call, in
> *every thread*, can be interrupted, and we need to catch EINTR.

That's true for every Unix. Every blocking syscall can return EINTR, and there 
are may non restartable syscalls. Writting code which depends on
a specific OS behavior, or whether the code is run from the main thread,
is broken.

>  2. On FreeBSD, we cannot block indefinitely in the main thread and
> expect to handle signals. This means that indefinite selects are not
> possible if we want to handle signals, and, perhaps more perversely,
> signal.pause() cannot be reliably used in the main thread.

The proper way to do so, in Python as in C, is to use pthread_sigmask
(http://docs.python.org/dev/library/signal.html#signal.pthread_sigmask)
- thanks to Victor. Just block all signals by default, and create a thread 
dedicated to signals management (that's the approach used by Java). You could 
also play some nice tricks with set_wakeup_fd 
(http://docs.python.org/dev/library/signal.html#signal.set_wakeup_fd).

> * Block all *asynchronous* signals in user threads.

What if some code expects to receive a signal from a thread other than
the main thread?

> * Unblock all signals after a fork() in a thread, since the thread is
> now the main thread.

What if a signal is delivered between fork() and unblock?

Really, signals and threads don't mix well (kinda like fork() and threads), so 
I don't think we can expect to fix this in Python. There's no free lunch, every 
design will chose will break existing code, or won't work as expected on a 
platform. The best we can do is to keep a sensitive default behavior (i.e. the 
one chosen by the OS designers), and offer APIs allowing the user to fine-tune 
the behavior according to its needs.

We've fixed many bugs pertaining to signals and threads during the last months, 
and we've gained a couple useful APIs to deal with signals and threads 
(pthread_sigmask(), sigwait(), etc).

I'd suggest to close this.

--

___
Python tracker 

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

[issue13405] Add DTrace probes

[Charles-François Natali]

Charles-François Natali  added the comment:

As I said, I'm skeptical about the benefit vs maintenance burden ratio, 
especially since cPython doesn't target performance critical applications. I 
just fear that's a lot of intrusive code which will only be used by a handful 
of people worldwild, but I could be wrong.
But I'm definitely not stubborn, so if other core developers think it's a 
worthwhile feature, I won't object to it (but I'd really prefer if the patch 
also supported SystemTap).

--

___
Python tracker 

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

[issue13634] Python SSL stack doesn't support Compression configuration

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now committed in 3.3.

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

[issue13634] Python SSL stack doesn't support Compression configuration

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 20b52be99b5d by Antoine Pitrou in branch 'default':
Issue #13634: Add support for querying and disabling SSL compression.
http://hg.python.org/cpython/rev/20b52be99b5d

--
nosy: +python-dev

___
Python tracker 

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

[issue13637] binascii.a2b_* functions could accept unicode strings

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24060/binasciistr.patch

___
Python tracker 

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