On 2009-02-02 14:50, Nick Coghlan wrote:
Really drastic performance degradations would be on the radar as well -
slowing pprint() down by 10% is unlikely to bother anyone, but slowing
it down by 100% would be a bad thing (not that I think such a
degradation is likely, I'm just trying to give an i
Tres Seaver wrote:
> Nick Coghlan wrote:
>> (and don't worry too much about 3 - it will give me an opportunity to
>> road test the functools patch by using it to refactor pprint and check
>> the performance implications)
>
> /me wonders about the performance-criticality of anything using
> 'pprint
On 29 Jan 2009, at 21:54, Nick Coghlan wrote:
For the "reiterable" cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).
Indeed, instead of having a __pprint__ why not just allow a __repr__
to reformat its output?
dict havin
2009/2/2 Nick Coghlan :
> Paul Moore wrote:
>> 2009/2/2 Nick Coghlan :
>>> A trio of patches that:
>>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>>> documentation and tests)
>>> 2. changed pkgutil to use functools.simplegeneric instead of its current
>>> internal versio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
> Paul Moore wrote:
>> 2009/2/2 Nick Coghlan :
>>> A trio of patches that:
>>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>>> documentation and tests)
>>> 2. changed pkgutil to use functools.simplegeneric
Paul Moore wrote:
> 2009/2/2 Nick Coghlan :
>> A trio of patches that:
>> 1. promoted simplegeneric from pkgutil to functools (with appropriate
>> documentation and tests)
>> 2. changed pkgutil to use functools.simplegeneric instead of its current
>> internal version
>> 3. updated pprint to be a g
2009/2/2 Nick Coghlan :
> A trio of patches that:
> 1. promoted simplegeneric from pkgutil to functools (with appropriate
> documentation and tests)
> 2. changed pkgutil to use functools.simplegeneric instead of its current
> internal version
> 3. updated pprint to be a generic function (and hence
Walter Dörwald wrote:
> Paul Moore wrote:
>> 2009/1/30 Walter Dörwald :
>>> Paul Moore wrote:
>>>
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
>>> http://pypi.python.org/pypi/simplegeneric
>>
>> Thanks, I was
Paul Moore wrote:
2009/1/30 Walter Dörwald :
Paul Moore wrote:
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that.
I wasn't aware of the fact that si
Paul Moore wrote:
> [...]
> In all honesty, I think pkgutil.simplegeneric should be documented,
> exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
> [...]
Servus,
Walter
___
Python-Dev mailing list
Python-De
2009/1/30 Walter Dörwald :
> Paul Moore wrote:
>
>> [...]
>> In all honesty, I think pkgutil.simplegeneric should be documented,
>> exposed, and moved to a library of its own[1].
>
> http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that. I assume that the barrier to getting this
in
Steven D'Aprano wrote:
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would
be no need for the pprint module.
2009/1/30 Steven D'Aprano :
>> But that's beside the
>>
>> point, I don't like __pprint__ in any event. Too special.
>
> I'm not sure what you mean by "too special". It's no more special than any
> other special method. Do you mean the use-case is not common enough? I would
> find this useful. Whet
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I w
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I want to use pprint,
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agree. And when I want to use pprint, there are usually ad
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module.
I agree. And when I want to use pprint, there are usually additional
output
Raymond Hettinger rcn.com> writes:
>
> P.S. My other experience with 3.0 is that my most frequent error has
> changed. It used to be that the number reason for my getting a syntax
> error was leaving-off a colon. Now, my number one reason is
> omitting parens in a print() function call. I tho
Along the lines of what others have said: pprint() cannot consume an
unknown iterator.
Perhaps so. It's nice to have printing be free of side-effects (other than
the actual printing).
I've been working with 3.0 daily for several months (on a book project)
and mostly think it's great. But
On 2009-01-29 08:20, Aahz wrote:
The reason I'm chiming in is that I would welcome a PEP that created a
__pprint__ method as an alternative to special-casing. I think that it
would be generically useful for user-created objects, plus once you've
added this feature other people can easily do som
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module. In any case, it seems that the pprint module
actually calls repr() on objects other than dicts, tuples an
Michael Foord wrote:
> Don't we have a pretty-print API - and isn't it spelled __str__ ?
For the "reiterable" cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).
Whether that is something as simple as ".items()" for an items view,
2009/1/29 Oleg Broytmann :
> On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
>> On Thu, Jan 29, 2009, Michael Foord wrote:
>> > Don't we have a pretty-print API - and isn't it spelled __str__ ?
>>
>> In theory, yes. In practice, we wouldn't be having this discussion if
>> that really worked.
On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
> On Thu, Jan 29, 2009, Michael Foord wrote:
> > Don't we have a pretty-print API - and isn't it spelled __str__ ?
>
> In theory, yes. In practice, we wouldn't be having this discussion if
> that really worked. But it probably would make sens
On Thu, Jan 29, 2009, Michael Foord wrote:
> Aahz wrote:
>> On Tue, Jan 27, 2009, Raymond Hettinger wrote:
>>
>>> It is becoming the norm in 3.x for functions to return iterators,
>>> generators, or views whereever possible.
>>>
>>> I had a thought that pprint() ought to be taught to print itera
Aahz wrote:
On Tue, Jan 27, 2009, Raymond Hettinger wrote:
It is becoming the norm in 3.x for functions to return iterators,
generators, or views whereever possible.
I had a thought that pprint() ought to be taught to print iterators:
pprint(enumerate(seq))
pprint(map(somefunc, someda
On Tue, Jan 27, 2009, Raymond Hettinger wrote:
>
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
>
> I had a thought that pprint() ought to be taught to print iterators:
>
>pprint(enumerate(seq))
>pprint(map(somefunc, somedata))
On Tue, Jan 27, 2009 at 2:24 PM, Raymond Hettinger wrote:
>
> [Guido van Rossum]
>>
>> My only thought is that whatever you do, target Python 3.1, not 3.0.1.
>
> Of course.
> Do you have any thoughts on the most useful display format?
> What do you want to see from pprint(mydict.items())?
Perhaps
[Guido van Rossum]
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
Of course.
Do you have any thoughts on the most useful display format?
What do you want to see from pprint(mydict.items())?
Raymond
___
Python-Dev mailing
On Tue, Jan 27, 2009 at 2:12 PM, Benjamin Peterson wrote:
> On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger wrote:
>> It is becoming the norm in 3.x for functions to return iterators,
>> generators, or views whereever possible.
>
>> Do you guys have any thoughts on the subject?
>
> Maybe a sol
Raymond Hettinger wrote:
>
I quite like the idea of something along those lines. For example:
try:
itr = iter(obj)
except TypeError:
pass
else:
return "" % (obj.__class__.__name__,
))
Doing this only in pprint also reduces the chances of accidentally
con
On Tue, Jan 27, 2009 at 2:06 PM, Oleg Broytmann wrote:
> On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote:
>>
>
> I like the idea, and I prefer this formatting. Also bear in mind there
> are infinite generators, and there are iterators that cannot be reset. For
> infinite ge
On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger wrote:
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
> Do you guys have any thoughts on the subject?
Maybe a solution like this could help with bugs like #2610?
--
Regards,
Ben
On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote:
>
I like the idea, and I prefer this formatting. Also bear in mind there
are infinite generators, and there are iterators that cannot be reset. For
infinite generators pprint() must have a parameter, say, 'max_items', and
pr
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
On Tue, Jan 27, 2009 at 1:46 PM, Raymond Hettinger wrote:
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
>
> I had a thought that pprint() ought to be taught to p
35 matches
Mail list logo
