rg3 added the comment:
I don't know if the behavior is considered a bug or just undocumented, but
under Python 2.7.3 it's still the same. locale.getpreferredencoding() does
return UTF-8, but the second element in the tuple locale.getdefaultlocale() is
"utf_8_valencia",
rg3 added the comment:
Charles-Francois Natali, Tuesday, February 22, 2011 20:57:
> Attached are two new versions which don't wait for the end of
> transfer.
I tested the one for Python 2.7 applied to Python 2.6 and it appears to
work perfectly. Thanks for th
rg3 added the comment:
> > I have to correct myself. I applied the patch manually to my Python
> > 2.6 installation. In Python 2.6, the line you moved is number 961,
> > and I did the same change.
>
> OK. For information, you can apply it using the Unix "patch&qu
rg3 added the comment:
I have to correct myself. I applied the patch manually to my Python 2.6
installation. In Python 2.6, the line you moved is number 961, and I did the
same change.
With your change, the connection can be closed, but you have to wait for the
file to be completely
rg3 added the comment:
I just tested the patch under Python 2.6. It doesn't seem to solve the problem.
--
___
Python tracker
<http://bugs.python.org/is
rg3 added the comment:
That makes sense and explains why the problem could not be reproduced over the
loopback (the transfer would be too fast).
I have not tested the patch, but I can reproduce the problem with a local
connection if I compile pure-ftpd with the --with-throttling switch and
New submission from rg3 :
If you run the attached program, you can see the program hangs in the
connection close stage. Uncommenting the sleep line makes the program work, so
I suspect some kind of race condition.
The URL used belongs to a Slackware Linux mirror. I have not been able to
rg3 added the comment:
Excellent. Thanks for the tip. I'll now proceed to modify my code to use
getpreferredencoding. Still, I think getdefaultlocale should work
because it could be used in other situations, I suppose.
--
___
Python tracker
rg3 added the comment:
Further investigation:
The guy who had this issue may be from Valencia, Spain. According to the
manpage for setlocale(3) in my system, the form is usually
language[_territory][.codese...@modifier]. So, in this case, it would
make sense for the language to be &qu
rg3 added the comment:
You are right. The issue is not reproduced with es_ca.ut...@valencia but
with ca_es.ut...@valencia. The fact that the first case works makes me
think maybe there's another way to solve the problem. Can you check
rg3 added the comment:
I just realized that the "if" I introduced is not really needed.
"encoding = encoding.split('@')[0]" works whether the '@' symbol is
present or not.
--
___
Python tr
New submission from rg3 :
A recent issue with one of my programs has shown that
locale.getdefaultlocale() does not handle correctly a corner case. The
issue URL is this one:
http://bitbucket.org/rg3/youtube-dl/issue/7/
Essentially, some users have LANG set to something like
es_ca.ut
12 matches
Mail list logo
