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 Wed, Jan 7, 2015 at 2:48 PM, Guido van Rossum 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 generators
>
> --
> -
On Fri, Feb 20, 2015 at 12:36 PM, Florian Bruhin wrote:
> * Demian Brecht [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:
>>
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 wrote:
> Here is some proposed wording. Since it is more of a clarification of what
> it takes to garner sup
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 a
* Demian Brecht [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', ''))
> '’
> >>> str
> On Feb 20, 2015, at 8:54 AM, Brett Cannon 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
> practical
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 wit
On Fri Feb 20 2015 at 11:39:11 AM Demian Brecht
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
> possible? For exa
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
...
>>> MyEn
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? I
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 err
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 d
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 Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka
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
> expect X, not Y
>
On Fri, 20 Feb 2015 08:50:10 +
raymond.hettinger wrote:
> https://hg.python.org/cpython/rev/0ba4bcc0a7a6
> changeset: 94696:0ba4bcc0a7a6
> user:Raymond Hettinger
> date:Fri Feb 20 00:50:04 2015 -0800
> summary:
> Improve struct cache locality by bring commonly accessed fie
16 matches
Mail list logo
