On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
> http://bugs.python.org/issue19332
Duplicate of this: http://bugs.python.org/issue6017
The conclusion on that also was that it is not worth guarding against
such an unusual circumstance.
--
Steven
On Wed, 06 Nov 2013 23:34:22 +1100, Steven D'Aprano wrote:
> On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
>
> > http://bugs.python.org/issue19332
>
> Duplicate of this: http://bugs.python.org/issue6017
>
> The conclusion on that also was that it is not worth guarding against
>
2013/11/6 R. David Murray :
> On Wed, 06 Nov 2013 23:34:22 +1100, Steven D'Aprano
> wrote:
>> On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
>>
>> > http://bugs.python.org/issue19332
>>
>> Duplicate of this: http://bugs.python.org/issue6017
>>
>> The conclusion on that also was tha
On Wed, 06 Nov 2013 16:10:16 +0100, Victor Stinner
wrote:
> More recently, I added another exception if a dictionary is modified
> during a lookup.
>
> When I proposed a new frozendict type to secure my pysandbox project,
> Armin Rigo wrote that CPython segfaults must be fixed. So I fixed a
> co
Le 06/11/2013 06:41, Nick Coghlan a écrit :
The behaviour of mutating builtin containers while iterating over them
is formally undefined beyond "it won't segfault" (one of the few such
undefined behaviours in Python). The associated exceptions are thus
strictly "best effort given other constrain
06.11.13 07:41, Nick Coghlan написав(ла):
If the benchmark suite indicates there's no measurable speed penalty
then such a patch may be worth reconsidering.
I don't see any significant speed difference even in artificial
presumably worst case (a lot of items assignment in tight loop).
If you
On Wed, Nov 6, 2013 at 11:02 AM, Serhiy Storchaka wrote:
> Actually we should guard not against changing dict during iteration, but
> against iterating modifying dict (and only such modifications which change
> dict's keys).
s/iterating modifying/iteration modifying/ ?
Just to clarify, do you me
diff -r bec6df56c053 Lib/datetime.py
--- a/Lib/datetime.pyTue Nov 05 22:01:46 2013 +0200
+++ b/Lib/datetime.pyThu Nov 07 00:46:34 2013 +0530
@@ -43,7 +43,7 @@
def _days_in_month(year, month):
"year, month -> number of days in that month in that year."
-assert 1 <= month <= 12, mo
Please put all patches on bugs.python.org, else we will lose track of the
change.
On Wed, Nov 6, 2013 at 2:17 PM, Sreenivas Reddy T <
thatiparthysreeni...@gmail.com> wrote:
> diff -r bec6df56c053 Lib/datetime.py
> --- a/Lib/datetime.pyTue Nov 05 22:01:46 2013 +0200
> +++ b/Lib/datetime.py
06.11.13 21:12, Eric Snow написав(ла):
Just to clarify, do you mean we should only guard against
modifications to the dict's keys during its iterator's __next__()?
Changes to the values during __next__() would be okay, as would
changes to the keys if they happen outside __next__()?
Dict iterati
> -assert 1 <= month <= 12, month
> +assert 1 <= month <= 12, 'month must be in 1..12'
In addition to Brett's comment, you might as well include the
offending value in your AssertionError message. For example, a value
of 0 probably tells you something different about your underlying bug
th
Le 06/11/2013 21:39, Skip Montanaro a écrit :
-assert 1 <= month <= 12, month
+assert 1 <= month <= 12, 'month must be in 1..12'
In addition to Brett's comment, you might as well include the
offending value in your AssertionError message. For example, a value
of 0 probably tells you som
On Wed, Nov 6, 2013 at 3:43 PM, Antoine Pitrou wrote:
> Besides, if it's an assertion it's only an internal helper to check
> implementation correctness. If it's an error that can be caused by
> erroneous user data, it should be replaced with the proper exception class
> (perhaps ValueError).
A
Thank you, Raymond, and everyone else who responded both here and on the
tracker.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
Hi,
I'm trying to avoid unnecessary temporary Unicode strings when
possible (see issue #19512). While working on this, I saw that Python
likes preparing an user friendly message to explain why getting an
attribute failed. The problem is that in most cases, the caller
doesn't care of the message: t
On Wed, Nov 06, 2013 at 11:32:33PM +0100, Victor Stinner wrote:
> Hi,
>
> I'm trying to avoid unnecessary temporary Unicode strings when
> possible (see issue #19512). While working on this, I saw that Python
> likes preparing an user friendly message to explain why getting an
> attribute failed.
16 matches
Mail list logo