> Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
I'd rather keep this a note. We don't want to use warnings except for cases
where there is a possibility of security implications or crashes.
Georg
Am 12.12.2010 19:25, schrieb antoine.pitrou:
> Author: antoine.pitrou
> Date: Sun Dec 12 19:25:25 2010
> New Revision: 87188
>
> Log:
> Make this a
On Sat, 18 Dec 2010 12:37:09 +0100
Georg Brandl wrote:
> I'd rather keep this a note. We don't want to use warnings except for cases
> where there is a possibility of security implications or crashes.
Well, there'll be a crash as soon as someone relies on an API we decide
to change or remove :)
Am 18.12.2010 13:07, schrieb Antoine Pitrou:
> On Sat, 18 Dec 2010 12:37:09 +0100
> Georg Brandl wrote:
>> I'd rather keep this a note. We don't want to use warnings except for cases
>> where there is a possibility of security implications or crashes.
>
> Well, there'll be a crash as soon as som
Am 17.12.2010 17:52, schrieb Laurens Van Houtven:
> +1 for throwing it out of the PEP. Assignment is a thing,
> nonlocal/global is a thing, don't mix them up :) (That in addition to
> the grammar cleanliness argument Stephan already made)
The trouble is what to make of
nonlocal x = 3, y
Is it tw
Am 18.12.2010 01:55, schrieb Victor Stinner:
> Hi,
>
> In 2008, I proposed a patch to raise a Python exception on SIGSEVG
> signal. In some cases, it's possible to catch the exception, log it, and
> continue the execution. But because in some cases, the Python internal
> state is corrupted, the
On Sat, 18 Dec 2010 13:11:09 +0100
Georg Brandl wrote:
> Am 18.12.2010 13:07, schrieb Antoine Pitrou:
> > On Sat, 18 Dec 2010 12:37:09 +0100
> > Georg Brandl wrote:
> >> I'd rather keep this a note. We don't want to use warnings except for
> >> cases
> >> where there is a possibility of securi
On Dec 17, 2010, at 7:55 PM, Victor Stinner wrote:
> Hi,
>
> In 2008, I proposed a patch to raise a Python exception on SIGSEVG signal. In
> some cases, it's possible to catch the exception, log it, and continue the
> execution. But because in some cases, the Python internal state is corrupted
Le 18/12/2010 13:21, Georg Brandl a écrit :
I very much like having a traceback on (some) segmentation faults,
Why do you say "some" segmentation faults?
but it's clear there needs to be a way to turn it off. An environment variable
seems to be the obvious choice (for the reasons you stated fo
On Sat, Dec 18, 2010 at 12:08:47AM +, MRAB wrote:
> This makes it harder to use more than one locale at a time
This is quite a known problem, not specific to Python. Locale
settings are global for a process, and this is one of the thousands
reasons why locale is considered so horrible.
I
Am 18.12.2010 14:57, schrieb Victor Stinner:
> Le 18/12/2010 13:21, Georg Brandl a écrit :
>> I very much like having a traceback on (some) segmentation faults,
> Why do you say "some" segmentation faults?
Well, without a closer I assume that for some crashes it's just not
possible anymore for the
Am 18.12.2010 14:57, schrieb Victor Stinner:
> Le 18/12/2010 13:21, Georg Brandl a écrit :
>> I very much like having a traceback on (some) segmentation faults,
> Why do you say "some" segmentation faults?
>> but it's clear there needs to be a way to turn it off. An environment
>> variable
>> see
On Sat, 18 Dec 2010 17:50:38 +0100
Georg Brandl wrote:
> Am 18.12.2010 14:57, schrieb Victor Stinner:
> > Le 18/12/2010 13:21, Georg Brandl a écrit :
> >> I very much like having a traceback on (some) segmentation faults,
> > Why do you say "some" segmentation faults?
> >> but it's clear there nee
On 18/12/2010 09:26, "Martin v. Löwis" wrote:
Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
The locale module would be able to return a named locale dict:
>>> loc = locale.getnamedlocale('en_UK')
or:
>>> loc =
On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote:
..
> In any case, this is coming pretty late; beta 2 is scheduled for this
> weekend, and even if this is something that only kicks in when all hope
> is lost anyway, it is a new feature. I should like to hear approval
> from a few more devs b
Am 18.12.2010 19:55, schrieb Alexander Belopolsky:
> On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote:
> ..
>> In any case, this is coming pretty late; beta 2 is scheduled for this
>> weekend, and even if this is something that only kicks in when all hope
>> is lost anyway, it is a new feature
On Sat, 18 Dec 2010 20:36:50 +0100
"Martin v. Löwis" wrote:
> Am 18.12.2010 19:55, schrieb Alexander Belopolsky:
> > On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl wrote:
> > ..
> >> In any case, this is coming pretty late; beta 2 is scheduled for this
> >> weekend, and even if this is something
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
> Author: ezio.melotti
> Date: Sat Dec 18 21:00:04 2010
> New Revision: 87389
>
> Log:
> #10573: use actual/expected consistently in unittest methods.
IMHO, this should be reverted. The API currently doesn't treat these
arguments diffe
Am 13.12.2010 21:08, schrieb Glenn Linderman:
> On 12/13/2010 11:39 AM, Mark Dickinson wrote:
>> my_thing = Thing(
>> foo = Foo(arg1, arg2, ...),
>> bar = Bar(arg3, arg4, ...),
>> ...
>> )
>>
>> and I've found the trailing comma very convenient during refactoring
>> and API experimen
On 12/18/2010 1:04 PM, Georg Brandl wrote:
Am 13.12.2010 21:08, schrieb Glenn Linderman:
On 12/13/2010 11:39 AM, Mark Dickinson wrote:
my_thing = Thing(
foo = Foo(arg1, arg2, ...),
bar = Bar(arg3, arg4, ...),
...
)
and I've found the trailing comma very convenient during refa
On 12/18/2010 3:48 PM, Antoine Pitrou wrote:
On Sat, 18 Dec 2010 21:00:04 +0100 (CET)
ezio.melotti wrote:
Author: ezio.melotti
Date: Sat Dec 18 21:00:04 2010
New Revision: 87389
Log:
#10573: use actual/expected consistently in unittest methods.
Change was requested by M. Foord and R. Hetting
On 12/18/2010 10:33 AM, Oleg Broytman wrote:
This is quite a known problem, not specific to Python. Locale
settings are global for a process, and this is one of the thousands
reasons why locale is considered so horrible.
ICU is perhaps the only way around the problem.
This is about the
Hi.
I've created bug on bugtracker, and then I was told there that I should post
this on this mailing list for discussion.
Here is link to bug: http://bugs.python.org/issue10730
Please add '.svgz': '.svg.gz' map to mimetypes.suffix_map
--
Grygoriy Fuchedzhy
_
Am 18.12.2010 19:26, schrieb MRAB:
> On 18/12/2010 09:26, "Martin v. Löwis" wrote:
>>> Comments?
>>
>> How do you implement that? In particular, how do you retrieve
>> information for different locales in a single program?
>>
> The locale module would be able to return a named locale dict:
>
On 19/12/2010 00:31, "Martin v. Löwis" wrote:
Am 18.12.2010 19:26, schrieb MRAB:
On 18/12/2010 09:26, "Martin v. Löwis" wrote:
Comments?
How do you implement that? In particular, how do you retrieve
information for different locales in a single program?
The locale module would be able to re
On 12/18/2010 4:37 PM, Grygoriy Fuchedzhy wrote:
Hi.
I've created bug on bugtracker, and then I was told there that I should
post this on this mailing list for discussion.
Here is link to bug: http://bugs.python.org/issue10730
Please add'.svgz':'.svg.gz' map to mimetypes.suffix_map
This issue
I may be unique, but I fear there is no great answer. On the one hand
I almost always code it as e.g. assertEqual(actual, expected), which
matches my preference for e.g. "if x == 5:" rather than "if 5 == x:".
On the other hand in those assert* functions that show a nice diff of
two lists, when read
On Sat, 18 Dec 2010 20:23:49 -0800, Guido van Rossum wrote:
> I may be unique, but I fear there is no great answer. On the one hand
> I almost always code it as e.g. assertEqual(actual, expected), which
> matches my preference for e.g. "if x =3D=3D 5:" rather than "if 5 =3D=3D x:=
> ".
> On the ot
28 matches
Mail list logo
