On Wed, May 09, 2007 at 05:08:01PM -0700, Philip Jenvey wrote: > On May 8, 2007, at 12:14 AM, Christoph Haas wrote: > > > > > On Mon, May 07, 2007 at 02:49:24PM -0700, Philip Jenvey wrote: > >> On May 5, 2007, at 1:07 PM, Christoph Haas wrote: > >>> as some of you already know I have never been very happy with > >>> Webhelpers' built-in pagination module. So I wrote my own (that > >>> is NOT > >>> compatible with the existing one) and I love it so far. > >>> > >>> Interested? Get it from http://workaround.org/pylons/paginator/ and > >>> let me know what you think. Some of the features: > >>> > >> Without having compared your paginator and WebHelpers', would it be > >> possible to rewrite the WebHelpers' paginator to use your code > >> (maintaining the old API)? > > > > It would be. You probably mean adding features to it while keeping the > > API. But IMHO my paginator is both simpler to use and has more > > features. > > Where the original paginator uses three classes for Paginator, Page > > and > > Window I just have one. You can use my paginator to iterate over it > > directly because it subclasses the "list" class. While it would be > > possible to make it backwards-compatible it would not help much. I can > > imagine having it included in the Webhelpers as a module that is > > called > > differently ("paginator2" or whatever) though. > > I was thinking if we wanted to replace the old one with it, we could > rewrite the old API to use your code and issue a deprecation warning > directing users to use the new API calls. We could just issue the > deprecation warning without rewriting it too.
IMHO although the functionality is similar the API is very different. I'd personally accept that the API changes as long as the module is called something else. The Python standard library has a lot of examples where old modules became deprecated with the time and modules with similar names appeared that has different APIs. I don't mean to say that my intention is to deprecate the built-in paginator. That's e.g. Ben's decision. :) > The paginate and your Page class's __init__ function prototype look > almost identical is why I asked. But the methods are different. > Is there any reason why the Page class is a list as opposed to being > an iterator (i.e. implementing __iter__) No real reason. I was glad that I managed to subclass "list" at all. :) Wouldn't that mean that people can't access any element any more? Since the elements of a page get pulled from the database anyway I wouldn't mind having them kept in memory. I'd rather use an iterator if I'm walking through a long list of lines where I don't even know if all elements fit into memory. The page is supposed to contain no more items than what fits on a screen I'd say a list is nice. But I'm no Python professional and willing to learn. > Note I haven't used either Paginator so beware, I probably don't know > what I'm talking about =] I get your points anyway. :) Christoph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
