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
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 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
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
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:
>
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
_
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
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 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
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 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
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
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, 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
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, 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
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
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
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
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 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
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
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
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 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
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 :)
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
> 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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
28 matches
Mail list logo
