Re: [stdlib-sig] Any more packaging suggestions? March 15th deadline for ideas!
[Brett]
On the web-sig I am working on how to handle urllib/urllib2/urlparse and Cookie/cookielib.
Why have a package for cookies? It's not a five module monster. In this case, the additional mental cost of having a package will more than offset the mental savings of having one less top level module. Some of the cookie stuff is long since deprecated or dying from neglect. How about removing the deadwood and rolling it into a single module? IMO, packages are for organizing large amounts of code. That doesn't apply here. Raymond
On Thu, Feb 28, 2008 at 6:00 PM, Raymond Hettinger <python@rcn.com> wrote:
[Brett]
On the web-sig I am working on how to handle urllib/urllib2/urlparse and Cookie/cookielib.
Why have a package for cookies? It's not a five module monster. In this case, the additional mental cost of having a package will more than offset the mental savings of having one less top level module.
Well, Robert Brewer suggested some reasonable names that would make the modules end up in the http package, so it's possible that they won't end up in their own package.
Some of the cookie stuff is long since deprecated or dying from neglect. How about removing the deadwood and rolling it into a single module?
IMO, packages are for organizing large amounts of code. That doesn't apply here.
I am happy to merge them into one, but unlike the other proposed merges, the naming gets funky with both Cookie and cookielib having similarly named classes but with different interfaces and purposed (the guys on the web-sig seem to like Cookie's parsing code). And with both modules being class-heavy there isn't a clear place where one can say "take these functions and these classes, and put them together". In other words I would totally support a merging of the two, but someone is going to have to do the heavy lifting to see it happen. -Brett
participants (2)
-
Brett Cannon -
Raymond Hettinger