On Monday 21 December 2009 17:20:33 Ben Firshman wrote: > > * What is going to happen to feeds.Feed? Is it deprecated or > > not? (there is no PendingDeprecationWarning AFAICS). > > I for one have a lot of code that uses feeds.Feed directly, > > bypassing the 'high level' framework that provided the view > > function. > > I wasn't sure whether to add a warning to that, since it is always > used through the feed() view. Though to be clear, I've added one.
No, it's not only used through the feed() view. It can be used directly, and it has been fully documented as a public class. > > If it is deprecated, what is the migration path? It really > > would need to be specified in painstaking detail. > > I've documented it in some detail in the release notes. Is this > painstaking enough? Unless I'm missing something, it's not nearly there (but some of this may be the 'formal stuff' that Jacob doesn't mind being missing for now). First, views.Feed.get_object() takes different arguments to feeds.Feed.get_object(). This is pretty confusing, and really needs to be *much* clearer in the documentation (not just the release notes). The same goes for the get_feed() method. The release notes imply that I can just switch from subclassing feeds.Feed to view.Feed and change get_object(), and it will all work. I can't see how that is possible: - I might have code that calls the constructor of feeds.Feed (or a subclass) directly. But views.Feed has a different signature altogether, and feeds.Feed.__init__() does a bit of work that my own code is going to have to do once feeds.Feed disappears. Obviously that code is doing something that will have to be done differently with views.Feed. But how exactly? - I might have code that calls the get_feed() method of feeds.Feed (or a subclass) directly. That method does extra work compared to views.Feed.get_feed(). When feeds.Feed goes away, what does my code need to be changed to? What I'm looking for is *step by step* instructions on how to update my code, and a list of *all* the differences between views.Feed and feeds.Feed, since the former is supposed to be the replacement for the latter. I shouldn't have to look at *any* of the code or previous documentation to work out what has changed. *All* the hard work should have been done for me. This is about maintenance programmers, who have been given a promise of backwards compatibility, who just want their application to carry on working. I'm insisting on this, because until we see it, it's very difficult to work out how "backwards compatible" this really is, and whether we should deprecate feeds.Feed at all. Jacob was happy for this to go in without the formal stuff of documenting all this, so I guess we can punt the decision about whether to deprecate feeds.Feed or not, but we do need those docs at some point so we can see the implications of deprecating feeds.Feed. So for now, maybe just update the release notes so they don't say that the new LatestEntries class is identical to before, or a caveat like "if you are only using the high level feed framework (the feed() view)" or something. Regards, Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
