Re: [Python-Dev] pprint(iterator)
Paul Moore wrote: 2009/1/30 Walter Dörwald wal...@livinglogic.de: 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 simplegeneric is part of the stdlib, albeit in a strange spot. I assume that the barrier to getting this into the stdlib will be higher than to simply exposing an implementation already available in the stdlib. At least we'd need documentation and tests. And of course the code must be stable and there must be someone willing to maintain it (then again it's less than 40 lines of code). There should be enough third-party module that use it to justify making simplegeneric an official part of the stdlib. The best spot for generic() is probably in the functools module. To be honest, all I would like is for these regular let's have another special method discussions to become unnecessary... Me too. Servus, Walter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Paul Moore wrote: 2009/2/2 Nick Coghlan ncogh...@gmail.com: 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 more easily extensible via the ABC mechanism, while still keeping it's current special cases as necessary) would certainly be an interesting thing to see (with patch 3 being the poster child for why patch 1 is a good idea). I'll see what I can do. I can't promise much for (3) as I don't personally have a need for it, so my understanding of the use cases is limited at best. But (1) and (2) should be possible. Can I assign the patches to you (for review, at least)? Sure - I've had plenty to do with functools in the past, and will no doubt have plenty to do with it in the future. Given that I believe Guido was one of the folks whose brain was hurt by PJE's attempts to explain PEP 3124, I'll be bringing the discussion back here before committing anything though :) (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) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Walter Dörwald wrote: Paul Moore wrote: 2009/1/30 Walter Dörwald wal...@livinglogic.de: 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 simplegeneric is part of the stdlib, albeit in a strange spot. Officially, it isn't - it's an implementation detail of pkgutil. As such, a leading underscore wouldn't have hurt, but the lack of mention in the pkgutil documentation (or pkgutil.__all__) is hopefully enough of a hint that it really isn't intended as a general purpose programming tool. I assume that the barrier to getting this into the stdlib will be higher than to simply exposing an implementation already available in the stdlib. At least we'd need documentation and tests. And of course the code must be stable and there must be someone willing to maintain it (then again it's less than 40 lines of code). There should be enough third-party module that use it to justify making simplegeneric an official part of the stdlib. The best spot for generic() is probably in the functools module. To be honest, all I would like is for these regular let's have another special method discussions to become unnecessary... Me too. 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 more easily extensible via the ABC mechanism, while still keeping it's current special cases as necessary) would certainly be an interesting thing to see (with patch 3 being the poster child for why patch 1 is a good idea). The major virtue of such a basic generic framework is that it is much easier to explain than the all-singing all-dancing overloading system described in PEP 3124. Type-based dispatch on the first argument is fairly straightforward to describe in terms that make sense to anyone that is already familiar with dynamic dispatch of class and instance methods. It's only when you get into more exotic dispatch conditions and up-calls and the like that people's eyes start to glaze over. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/2/2 Nick Coghlan ncogh...@gmail.com: Paul Moore wrote: 2009/2/2 Nick Coghlan ncogh...@gmail.com: 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 more easily extensible via the ABC mechanism, while still keeping it's current special cases as necessary) would certainly be an interesting thing to see (with patch 3 being the poster child for why patch 1 is a good idea). I'll see what I can do. I can't promise much for (3) as I don't personally have a need for it, so my understanding of the use cases is limited at best. But (1) and (2) should be possible. Can I assign the patches to you (for review, at least)? Sure - I've had plenty to do with functools in the past, and will no doubt have plenty to do with it in the future. http://bugs.python.org/issue5135 A single patch covering (1) and (2). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 having:
def __repr__(self, pretty=False):
if pretty:
return {\n a: 1\n b: 2\n}
else:
return {a: 1, b: 2}
That way you can specify your own pretty format, intending it to still
be a valid __repr__ and pprint can do:
try:
print(obj.__repr__(pretty=True))
except TypeError:
print(prettify(repr(obj)))
That way it's opt in, doesn't have a special method, and includes the
mental prompt this should eval() to obj
Matt
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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'. Or were you just planning to use it as a means to benchmark the 'simplegeneric' stuff? I would think something with a lot lower intrinsic overhead would be a better benchmark target. Don't read too much into that comment - generics make the most sense in cases (like pprint) where extensibility is a more important feature than raw speed. I'm talking about more subjective impressions of performance as well as things like if I register a handler for Sequence, is there any performance advantage in registering direct handlers for the builtin subclasses?. 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 impression of the magnitude of change I'll be trying to measure). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 impression of the magnitude of change I'll be trying to measure). Using the pretty module I referenced earlier, which basically uses simplegeneric's lookup algorithm: In [11]: %timeit x=pprint.pformat(sys.modules) 10 loops, best of 3: 27.5 ms per loop In [12]: %timeit x=pretty.pretty(sys.modules) 10 loops, best of 3: 39.9 ms per loop In [13]: len(sys.modules) Out[13]: 517 The comparison is somewhat dodgy, though. pretty is not so much a refactoring of pprint as a reimplementation, so the time differences may not be due to the dispatch. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: Paul Moore wrote: 2009/2/2 Nick Coghlan ncogh...@gmail.com: 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 more easily extensible via the ABC mechanism, while still keeping it's current special cases as necessary) would certainly be an interesting thing to see (with patch 3 being the poster child for why patch 1 is a good idea). I'll see what I can do. I can't promise much for (3) as I don't personally have a need for it, so my understanding of the use cases is limited at best. But (1) and (2) should be possible. Can I assign the patches to you (for review, at least)? Sure - I've had plenty to do with functools in the past, and will no doubt have plenty to do with it in the future. Given that I believe Guido was one of the folks whose brain was hurt by PJE's attempts to explain PEP 3124, I'll be bringing the discussion back here before committing anything though :) (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'. Or were you just planning to use it as a means to benchmark the 'simplegeneric' stuff? I would think something with a lot lower intrinsic overhead would be a better benchmark target. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhu6I+gerLs4ltQ4RAvdcAJ4mFTcdfgG7ZVvdKXulIw+fWgLJxwCeOrTO 9rriK3+zyl4K63doUjbckF4= =++qD -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/2/2 Nick Coghlan ncogh...@gmail.com: 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 more easily extensible via the ABC mechanism, while still keeping it's current special cases as necessary) would certainly be an interesting thing to see (with patch 3 being the poster child for why patch 1 is a good idea). I'll see what I can do. I can't promise much for (3) as I don't personally have a need for it, so my understanding of the use cases is limited at best. But (1) and (2) should be possible. Can I assign the patches to you (for review, at least)? The major virtue of such a basic generic framework is that it is much easier to explain than the all-singing all-dancing overloading system described in PEP 3124. Type-based dispatch on the first argument is fairly straightforward to describe in terms that make sense to anyone that is already familiar with dynamic dispatch of class and instance methods. It's only when you get into more exotic dispatch conditions and up-calls and the like that people's eyes start to glaze over. Agreed. And given that the simple case probably covers 90% of the practical requirements, that's a shame. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 want to use pprint, there are usually additional output formatting requirements I need that isn't a one size fits all type of problem. I don't see how you can have a standard interface (like __pprint__), and have additional, per-object formatting parameters. I don't see how you can't. Other standard methods take variable arguments: __init__, __new__, __call__ come to mind. 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. Whether enough people would find it useful enough to add yet another special method is an open question. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/1/30 Steven D'Aprano st...@pearwood.info: 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. Whether enough people would find it useful enough to add yet another special method is an open question. In my view, the issue is that as a special method, *either* it has to be included on all core types (too intrusive for something as non-critical as pprint) *or* pprint has to hard-code the behaviour for core types and still fall back to the special method for non-core types (ugly and a maintenance problem keeping the type tests up to date). Some sort of registry of type-specific implementation functions (whether you call it a generic function or just put together a custom implementation for pprint alone) is more flexible, and less intrusive. It also allows end users to customise the behaviour, even for core types. In all honesty, I think pkgutil.simplegeneric should be documented, exposed, and moved to a library of its own[1]. It's precisely what is needed for this type of situation, which does come up fairly often. I don't think ABCs do what's needed here (although maybe I'm missing something - if so, I'd be interested in knowing what). I'd be willing to look at creating a patch, if the consensus was that this was an appropriate approach and there was a reasonable chance of it being accepted (assuming my code wasn't rubbish :-)) Paul. [1] Note - I have no opinion on the quality of the code, I haven't reviewed it, I am assuming it's OK on the basis that it has been present and in use internally in the pkgutil module for some time now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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)) pprint(permutations(elements)) pprint(mydict.items()) Along the lines of what others have said: pprint() cannot consume an unknown iterator. Therefore, you can pretty up the existing output slightly or special-case certain known iterators. There might also be an API change to pprint() that allowed it to consume iterators. 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 some of the grunt work of extending this through the Python core. (Actually, unless someone objects, I don't think a PEP is required, but it would be good for the usual reasons that PEPs are written, to provide a central place documenting the addition.) This can also be done for Python 2.7, too. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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, somedata)) pprint(permutations(elements)) pprint(mydict.items()) Along the lines of what others have said: pprint() cannot consume an unknown iterator. Therefore, you can pretty up the existing output slightly or special-case certain known iterators. There might also be an API change to pprint() that allowed it to consume iterators. 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 some of the grunt work of extending this through the Python core. (Actually, unless someone objects, I don't think a PEP is required, but it would be good for the usual reasons that PEPs are written, to provide a central place documenting the addition.) This can also be done for Python 2.7, too. Don't we have a pretty-print API - and isn't it spelled __str__ ? Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 iterators: pprint(enumerate(seq)) pprint(map(somefunc, somedata)) pprint(permutations(elements)) pprint(mydict.items()) 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 some of the grunt work of extending this through the Python core. (Actually, unless someone objects, I don't think a PEP is required, but it would be good for the usual reasons that PEPs are written, to provide a central place documenting the addition.) 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 sense to see how far using __str__ can take us -- AFAICT enumobject.c doesn't define __str__ (although I may be missing something, I don't know Python at the C level very well). -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 sense to see how far using __str__ can take us -- AFAICT enumobject.c doesn't define __str__ (although I may be missing something, I don't know Python at the C level very well). Container objects (tuples/lists/dicts/sets) don't define __str__. Is __pprint__ an attempt to redefine __str__? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
2009/1/29 Oleg Broytmann p...@phd.pp.ru: 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 sense to see how far using __str__ can take us -- AFAICT enumobject.c doesn't define __str__ (although I may be missing something, I don't know Python at the C level very well). Container objects (tuples/lists/dicts/sets) don't define __str__. Is __pprint__ an attempt to redefine __str__? Anyone feel like raising the topic of generic functions again? :-) More practically, the undocumented simplegeneric decorator in pkgutil could be used: Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from pkgutil import simplegeneric @simplegeneric ... def f(obj): ...return Object of type %s % type(obj) ... def str_f(s): ...return String: + s ... f.register(str, str_f) function str_f at 0x00B461F0 f(Test) 'String: Test' f(1) Object of type type 'int' To me, that seems better than inventing yet another special method. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 repr of underlying dict.items() for an items view, or something more complicated that more directly shows the content of the view, I'm not sure. For the standard iterators like enumerate and ranged, I would suggest that they be modified to use a repr of the form: reversed(repr of underlying iterable) enumerate(repr of underlying iterable) iter(repr of underlying sequence) iter(repr of callable, repr of sentinel value) While those obviously won't show how much of the iterable has been consumed, neither do the current representations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 and lists. I'm concerned about the number of special methods exploding, but I've also come across times where I needed more than two string representations of an object. Sometimes I solved this by adding a pprint() method, other times I used other names, and it would be nice if there was a standard way of spelling it. So I'm +0.5 on Aahz's suggestion of __pprint__. In my ideal world, __pprint__ should allow (but not require) extra arguments, so that one can do something like the following: pprint(binarytree) # sensible defaults pprint(binarytree, order='preorder') -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 some of the grunt work of extending this through the Python core. (Actually, unless someone objects, I don't think a PEP is required, but it would be good for the usual reasons that PEPs are written, to provide a central place documenting the addition.) I think it's worth looking at Armin Ronacher's pretty.py for a starting point. http://dev.pocoo.org/hg/sandbox/file/tip/pretty I've been using it as my default displayhook under IPython for a few weeks now. It uses a combination of a function registry and a __pretty__ special method to find the right pretty printer. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 sooner or later, we're going to have to address the issue about iterator reprs at the interactive prompt. This is a separate and more general issue than pprint(). My experience so far is that it is that the shift to more things being unviewable at the prompt is bit frustrating and makes the language more opaque. If that has been a source of irritation to me, then it will likely be more acutely felt by people who are starting out and are using the interactive prompt to explore the language. I don't know the right answer here (perhaps an alternate sys.displayhook). Just wanted to provide some early feedback based on my experiences heavily exercising 3.0. Raymond 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 thought I would get used to it quickly, but it still comes up several times a day. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Raymond Hettinger python at 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 thought I would get used to it quickly, but it still comes up several times a day. I find myself with the reverse problem. When I code with 2.x, I often put parens around the argument list of a print staement. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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 additional output formatting requirements I need that isn't a one size fits all type of problem. Like others, I am wary of over-expanding the list of special methods. Perhap format strings could have a fourth conversion specifier, !p (pretty) in addition to !s, !r, and !a. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
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, there are usually additional output formatting requirements I need that isn't a one size fits all type of problem. I don't see how you can have a standard interface (like __pprint__), and have additional, per-object formatting parameters. But that's beside the point, I don't like __pprint__ in any event. Too special. Like others, I am wary of over-expanding the list of special methods. Perhap format strings could have a fourth conversion specifier, !p (pretty) in addition to !s, !r, and !a. What would format() do with !p? With !s, it calls str(o), with !r, it calls repr(o). !p could call o.__pprint__(), but that's the special method you're trying to avoid! (I don't recall if I added !a, and a machine that would know isn't available to me just now.) Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote: enumerate object: 'A', 'B', 'C', 'D', 'E', 'F' 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 print generator: 'A', 'B', 'C', 'D', 'E', 'F', The situation with iterators that cannot be reset should be documented. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger pyt...@rcn.com 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, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
On Tue, Jan 27, 2009 at 2:06 PM, Oleg Broytmann p...@phd.pp.ru wrote: On Tue, Jan 27, 2009 at 01:46:35PM -0800, Raymond Hettinger wrote: enumerate object: 'A', 'B', 'C', 'D', 'E', 'F' 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 print generator: 'A', 'B', 'C', 'D', 'E', 'F', The situation with iterators that cannot be reset should be documented. This pretty much kills the proposal. Calling a print function like pprint() should not have a side effect on the object being printed. I'd be okay of pprint() special-cased the views returned by e.g. dict.keys(), but if all we know is that the argument has a __next__ method, pprint() should *not* be calling that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
Raymond Hettinger wrote: enumerate object: 'A', 'B', 'C', 'D', 'E', 'F' I quite like the idea of something along those lines. For example: try: itr = iter(obj) except TypeError: pass else: return iterable %s: %s % (obj.__class__.__name__, as for list contents)) Doing this only in pprint also reduces the chances of accidentally consuming an iterator (which was a reasonable objection when I suggested changing the __str__ implementation on some of the standard iterators some time ago). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
On Tue, Jan 27, 2009 at 2:12 PM, Benjamin Peterson benja...@python.org wrote: On Tue, Jan 27, 2009 at 3:46 PM, Raymond Hettinger pyt...@rcn.com 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? It would have to special-case range() objects. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
[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 list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pprint(iterator)
On Tue, Jan 27, 2009 at 2:24 PM, Raymond Hettinger pyt...@rcn.com 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 ['a', 'b', ...] ? The list display is familiar to everyone; the surrounding make it clear that it's not really a list without adding much noise. Another idea would be dict_items: ['a', 'b', ...] which helpfully includes the name of the type of the object that was passed into pprint(). Regarding range(), I wonder if we really need to show more than 'range(0, 10)' -- anything besides that would be wasteful IMO. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
