common issue: setlocale handling?
Hi all, I recently got a bug filed on iotop about its setlocale handling (#593846). With a quick grep of my system I can see code in the following packages that looks like they would probably have the same issue: python-xdg virt-manager virtinst iotop mercurial-common python-hachoir-metadata inkscape cython python-gmenu python-aptdaemon fontypython gmobilemedia Do any of the python code checkers have heuristics that can check for this? There was discussion at DebConf10 about having lintian run external programs to check for things like python coding errors and so on. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktingej4zwbttj+ez+ljlabug6g-e8vzbstbx0...@mail.gmail.com
Re: common issue: setlocale handling?
* Paul Wise , 2010-08-22, 15:06: I recently got a bug filed on iotop about its setlocale handling (#593846). The issue was unguarded code like: locale.setlocale(locale.LC_ALL, '') which fails with "locale.Error: unsupported locale setting" if user has LC_* set to invalid values in his environment. I don't think this is a bug at all. I'd rather say it's an user error. -- Jakub Wilk signature.asc Description: Digital signature
Re: common issue: setlocale handling?
On Sun, Aug 22, 2010 at 3:40 PM, Jakub Wilk wrote: > I don't think this is a bug at all. I'd rather say it's an user error. I disagree, stuff written in C or Perl doesn't crash when the locale is not set properly and neither should stuff written in Python. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimok8kfd5r9mflfesjh6x2ugtzjs=+lucco0...@mail.gmail.com
Re: common issue: setlocale handling?
On So, 2010-08-22 at 15:44 +0800, Paul Wise wrote: > On Sun, Aug 22, 2010 at 3:40 PM, Jakub Wilk wrote: > > > I don't think this is a bug at all. I'd rather say it's an user error. > > I disagree, stuff written in C or Perl doesn't crash when the locale > is not set properly and neither should stuff written in Python. Well, it does not really make sense to use invalid locales, so I see no problems if applications exit with a failure. Users should fix their environments instead. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282473491.2784.3.ca...@jak-thinkpad
Is runpy missing from python2.6 ?
Dear Debian Python people, While testing the upgrade of a system to Squeeze, I am experiencing errors like the following: Paramétrage de python-markupsafe (0.9.2-1) ... Could not import runpy module Traceback (most recent call last): File "/usr/bin/pycompile", line 280, in main() File "/usr/bin/pycompile", line 264, in main compile(files, versions, e_patterns) File "/usr/bin/pycompile", line 194, in compile pipe.send(fn) File "/usr/bin/pycompile", line 176, in py_compile stdin.write(filename + '\n') IOError: [Errno 32] Broken pipe Apt-file suggests that runpy is only available in python2.7, that is not installed in my system. But actually, python-markupsafe is not the only module needing runpy: at least python-imaging-tk and python-pkg-resources give me the same error. So I wonder: is it an bug in the above packages, or is runpy missing from python2.6? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100822120212.ga6...@merveille.plessy.net
Re: common issue: setlocale handling?
On 2010-08-22 12:38, Julian Andres Klode wrote: > Well, it does not really make sense to use invalid locales, so I see no > problems if applications exit with a failure. Users should fix their > environments instead. It would be nice, if applications would fall back to the "C" locale and warn about the fact instead of just exiting. Still, this would be wishlist or minor. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100822121401.gc8...@beron.tangosoft.com
Re: common issue: setlocale handling?
OoO En cette matinée ensoleillée du dimanche 22 août 2010, vers 09:44,
Paul Wise disait :
>> I don't think this is a bug at all. I'd rather say it's an user error.
> I disagree, stuff written in C or Perl doesn't crash when the locale
> is not set properly and neither should stuff written in Python.
Perl spits out a lot of annoying warnings when using a non existing
locale. And it does this for any perl script.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "jhfjkghf"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
However, I don't say that the problem does not exist in Python. I see a
lot those kind of errors with Perl because I log into servers that don't
have my locale installed. There is not much to do because ssh does not
allow to remove some variables from environment that have been added
server side (with AcceptEnv). It would be better to switch silently to C
locale than to display a lot of useless warnings or just stop.
--
# Basic IBM dingbats, some of which will never have a purpose clear
# to mankind
2.4.0 linux/drivers/char/cp437.uni
pgp5ZJGU6LVJo.pgp
Description: PGP signature
Re: Is runpy missing from python2.6 ?
[Charles Plessy, 2010-08-22] > While testing the upgrade of a system to Squeeze, I am experiencing errors > like > the following: > > Paramétrage de python-markupsafe (0.9.2-1) ... > Could not import runpy module > Traceback (most recent call last): > File "/usr/bin/pycompile", line 280, in > main() > File "/usr/bin/pycompile", line 264, in main > compile(files, versions, e_patterns) > File "/usr/bin/pycompile", line 194, in compile > pipe.send(fn) > File "/usr/bin/pycompile", line 176, in py_compile > stdin.write(filename + '\n') > IOError: [Errno 32] Broken pipe > > Apt-file suggests that runpy is only available in python2.7, that is not > installed in my system. But actually, python-markupsafe is not > the only module needing runpy: at least python-imaging-tk and > python-pkg-resources > give me the same error. > > So I wonder: is it an bug in the above packages, or is runpy missing from > python2.6? it's in python2.6-minimal (which is the right place) (and I still don't know why it failed) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: common issue: setlocale handling?
On Sun, Aug 22, 2010 at 02:16:21PM +0200, Vincent Bernat wrote:
> OoO En cette matinée ensoleillée du dimanche 22 août 2010, vers 09:44,
> Paul Wise disait :
>
> >> I don't think this is a bug at all. I'd rather say it's an user error.
>
> > I disagree, stuff written in C or Perl doesn't crash when the locale
> > is not set properly and neither should stuff written in Python.
>
> Perl spits out a lot of annoying warnings when using a non existing
> locale. And it does this for any perl script.
>
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "jhfjkghf"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
>
> However, I don't say that the problem does not exist in Python. I see a
> lot those kind of errors with Perl because I log into servers that don't
> have my locale installed. There is not much to do because ssh does not
> allow to remove some variables from environment that have been added
> server side (with AcceptEnv). It would be better to switch silently to C
> locale than to display a lot of useless warnings or just stop.
Using the standard warnings module this would only happen once for
each python script. This sounds like the more sensible behaviour, but
it sounds like it should be fixed upstream so that the unguarded
setlocale just shows this behaviour. If everyone here agrees with
that maybe someone should ask python to consider this?
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100822211629.ga10...@laurie.devork.be
Re: common issue: setlocale handling?
OoO La nuit ayant déjà recouvert d'encre ce jour du dimanche 22 août
2010, vers 23:16, Floris Bruynooghe disait :
>> Perl spits out a lot of annoying warnings when using a non existing
>> locale. And it does this for any perl script.
>>
>> perl: warning: Setting locale failed.
>> perl: warning: Please check that your locale settings:
>> LANGUAGE = (unset),
>> LC_ALL = (unset),
>> LANG = "jhfjkghf"
>> are supported and installed on your system.
>> perl: warning: Falling back to the standard locale ("C").
>>
>> However, I don't say that the problem does not exist in Python. I see a
>> lot those kind of errors with Perl because I log into servers that don't
>> have my locale installed. There is not much to do because ssh does not
>> allow to remove some variables from environment that have been added
>> server side (with AcceptEnv). It would be better to switch silently to C
>> locale than to display a lot of useless warnings or just stop.
> Using the standard warnings module this would only happen once for
> each python script.
This would be a real pain! Incorrect locales should just be ignored.
--
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
pgpwCTKzM0DyA.pgp
Description: PGP signature
