On Fri, 20 Feb 2015 08:50:10 +
raymond.hettinger python-check...@python.org wrote:
https://hg.python.org/cpython/rev/0ba4bcc0a7a6
changeset: 94696:0ba4bcc0a7a6
user:Raymond Hettinger pyt...@rcn.com
date:Fri Feb 20 00:50:04 2015 -0800
summary:
Improve struct cache
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka storch...@gmail.com
wrote:
Different patterns for TypeError messages are used in the stdlib:
expected X, Y found
expected X, found Y
expected X, but Y found
expected X instance, Y found
X expected, not Y
Hi all,
python now supports the __length_hint__ method but not for every use
case that could potentially benefit from it, v.g.:
1) Some common builtins like map don't set the hint.
2) Generators.
3) Application specific hints that, by definition, can't be predicted
by a general strategy.
I know
On Fri, Feb 20, 2015 at 12:36 PM, Florian Bruhin m...@the-compiler.org wrote:
* Demian Brecht demianbre...@gmail.com [2015-02-20 10:24:53 -0800]:
These and other implementations return a string representation of the
instance’s value, not a string representation of the object itself. Whereas
On Wed, Jan 7, 2015 at 2:48 PM, Guido van Rossum gu...@python.org wrote:
There's a proof of concept patch in http://bugs.python.org/issue22906, but
it doesn't have the __future__ import and probably gets other details wrong.
Reference:
PEP 479 -- Change StopIteration handling inside
Hi all,
In case anyone wants to mentor a student for GSoC 2015, or have an
idea on which students can work on during GSoC, please start putting
them up in [1]. I am yet to get the edit access, I will put up the
initial template text there. You can even send the idea as a reply to
this thread. The
On Fri Feb 20 2015 at 10:27:35 AM Stefan Richthofer
stefan.richtho...@gmx.de wrote:
Honestly, the right solution would be to have a function or macro that
generates the TypeError messages
from X, Y, Z arguments. (Until now I actually believed this would be
already the case)
- type errors
On 02/20/2015 09:05 AM, Brett Cannon wrote:
Some messages (only in C) truncate actual type name (%.50s, %.80s,
%.200s, %.500s). Should type name be truncated at all and for how limit?
I assume this is over some worry of string size blowing out memory
allocation or something? If
Honestly, the right solution would be to have a function or macro that generates the TypeError messages
from X, Y, Z arguments. (Until now I actually believed this would be already the case)
- type errors would be of uniform style
- if for some reoson the format should be changed, this can be
While working on a bug in the issue tracker, I came across something that I
thought was a little odd around the behaviour of IntEnum. Should the behaviour
of an instance of an IntEnum not be symmetric to an int where possible? For
example:
class MyEnum(IntEnum):
... FOO = 1
...
On Fri Feb 20 2015 at 11:39:11 AM Demian Brecht demianbre...@gmail.com
wrote:
While working on a bug in the issue tracker, I came across something that
I thought was a little odd around the behaviour of IntEnum. Should the
behaviour of an instance of an IntEnum not be symmetric to an int where
ACTIVITY SUMMARY (2015-02-13 - 2015-02-20)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4770 (-20)
closed 30484 (+54)
total 35254 (+34)
Open issues
I just realized I actually never committed this change. Assuming no new
objections I'll commit this in the near future (promise this time =).
On Fri May 16 2014 at 1:51:00 PM Brett Cannon bcan...@gmail.com wrote:
Here is some proposed wording. Since it is more of a clarification of what
it
On Feb 20, 2015, at 8:54 AM, Brett Cannon br...@python.org wrote:
Concrete reason. The string is 'MyEnum.FOO' which is much more readable and
obvious where the value came from. The fact that it can be treated as an int
is the same as the reason True and False are subclasses of int; it made
* Demian Brecht demianbre...@gmail.com [2015-02-20 10:24:53 -0800]:
These and other implementations return a string representation of the
instance’s value, not a string representation of the object itself. Whereas
elsewhere in the standard library:
str(ProtocolError('url', 42, 'msg', ''))
On 02/20/2015 10:24 AM, Demian Brecht wrote:
I think that a decent rule around the usage of __str__ is that it should
be a string representation of the value, not of the object. Failing the
ability to logically coerce the value to a string, it should simply fall
back to repr(obj).
There are
16 matches
Mail list logo
