Mailman 3 February 2008 - stdlib-sig

Any more packaging suggestions? March 15th deadline for ideas!
by Brett Cannon March 5, 2008

March 5, 2008

On the web-sig I am working on how to handle urllib/urllib2/urlparse and Cookie/cookielib. That ends my list of packages I wanted to create. I thought about cgi/cgitb and thread/threading/dummy_thread/dummy_threading but I don't see how to pull them off in a reasonable manner where the name actually improves across the board, so I am not proposing anything. But if anybody else has ideas on packages to create, feel free to throw them out. I am going to put a cap on new package ideas of March 15th. That is during PyCon but before the sprints so that if someone ends up wanting to sprint on dealing with new packages they can. It also keeps things from dragging on. This deadline does not affect module removals or renamings. Please don't wait until the last minute to suggest something! The more time one has the less chance it will be shot down just because no one wants the conversation to drag on. And if you do suggest something, please start a new email thread. -Brett

2 3

Choosing one of two options for url* in the stdlib reorg
by Brett Cannon Feb. 29, 2008

Feb. 29, 2008

[BCC'ing stdlib-sig and web-sig so that both vote but that I don't have to clear a bunch of replies in the stdlib-sig mailing list from people not on both lists =) ] With PyCon approaching and having other stuff on my plate to deal with I want to try to reach a consensus on the whole urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 and get it settled. So, two options for people to show support for. One is to keep everything and get cute with the naming:: urlparse -> url.parse urllib -> url.fetch urllib2 -> url.request The second option is to ditch urllib, move the handy quoting tools into either their own module or into what is currently urllib2:: urlparse -> url.parse urllib -> GONE urllib's utility functions -> url.quote urllib2 -> url.request So, if you have an opinion please speak up! -Brett

5 4

Re: [stdlib-sig] Any more packaging suggestions? March 15th deadline for ideas!
by Raymond Hettinger Feb. 29, 2008

Feb. 29, 2008

[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

2 1

tk package added to PEP 3108
by Brett Cannon Feb. 25, 2008

Feb. 25, 2008

I added the proposed tk package. I did merging of the modules with similar names but with or without a 'tk' prefix. Might be able to toss some out, but since I never use Tkinter I am not going to bother. -Brett

5 9

PEP 3108 updated with html package
by Brett Cannon Feb. 24, 2008

Feb. 24, 2008

Have it including HTMLParser and htmlentitydefs along with the removal of htmllib and sgmllib. I also updated it to reflect the removal of the various User* modules. -Brett

1 0

Any ideas on how to handle urllib, urllib2, and urlparse?
by Brett Cannon Feb. 20, 2008

Feb. 20, 2008

Dealing with the URL-related modules is the last specific thing I want to deal with in terms of new packages. The problem is that urllib and urllib2 each have a key function that are named the same thing with slightly different parameters and returning objects that have the same base interface but are different classes and provide a different way to overload what gets returned. Doing something like: urllib -> url.fetch (not url.open since url.open.urlopen() looks weird) urllib2 -> url.fetch2 urlparse -> url.parse seems somewhat silly, but the best I can think of right now. I could ask the web-sig if they think we could try to get rid of either urllib or urllib2, but I suspect they will say no. -Brett

7 8

tkinter package idea
by Brett Cannon Feb. 20, 2008

Feb. 20, 2008

While I would rather have a tk package (heck, I would be fine with ditching Tkinter entirely, but I really don't see that happening), but the Tkinter name is so wide-spread I don't think that is reasonable. So here is my current thinking: Tkinter -> tkinter.__init__ Tix -> tkinter.tix turtle -> tkinter.turtle tkSimpleDialog -> tkinter.simpledialog tkMessageBox -> tkinter.messagebox tkFont -> tkinter.font tkFileDialog -> tkinter.filedialog Tkdnd -> tkinter.dnd Tkconstants -> tkinter.constants tkCommonDialog -> tkinter.commondialog tkColorChooser -> tkinter.colorchooser SimpleDialog -> tkinter.simpledialog ScrolledText ->tkinter.scrolledtext FixTk -> tkinter._fix FileDialog -> tkinter.filedialog Dialog -> tkinter.dialog Canvas -> tkinter.canvas I know Guido has said he doesn't like stuffing a bunch of stuff into the __init__ of a package, but considering none of the other modules are worth anything without the main Tkinter module anyway I don't see any issues here. -Brett

3 7

html package idea
by Brett Cannon Feb. 20, 2008

Feb. 20, 2008

Here is an idea for an html package: htmlentitydefs -> html.entities htmllib -> html.tools HTMLParser -> html.parser What do people think? -Brett

5 14

Organizing the cookie modules
by Brett Cannon Feb. 5, 2008

Feb. 5, 2008

We have Cookie and cookielib. Neither are going away it looks like. Combining them doesn't work as Cookie has BaseCookie and SimpleCookie while cookielib has Cookie. Way too much confusion. Since Cookie has to be renamed anyway thanks to its CapWords spelling, I am proposing: Cookie -> cookie.server cookielib -> cookie.client And no, I don't think every new package should have a client and server module. =) I realize this doesn't simplify the names and thus breaks the guiding rule Guido gave us, but since Cookie has to be renamed anyway I am willing to make an exception. -Brett

2 3

Suggested tweaks to http and xmlrpc packages
by Brett Cannon Feb. 5, 2008

Feb. 5, 2008

So the suggestion has come up in a couple separate emails (I know MAL and Kevin at least, maybe even Bill) to do some tweaks to the proposed http and xmlrpc packages. I want to start a separate email on that to more easily collect people's thoughts in a single place. So the suggestions now are: httplib ->http.client http.server proposal stays. xmlrpclib -> xmlrpc.client xmlrpc.server proposal stays. There is also the issue of the cookie-related modules. Ignoring singular vs. plural, we have Cookie and cookielib. Having looked at them I don't think they can be reasonably merged into a single module with their naming the way they are. And on the web-sig they said that Cookie is still widely used. So http.cookie(s) might not be able to happen without reworking cookielib to gain the abilities Cookie has in some reasonable fashion. -Brett

3 5