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
On Feb 5, 2008, at 3:20 PM, Brett Cannon wrote:
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
I'm not aware of these being used with anything but HTTP (including HTTPS), so why not add them into the http package? I think the class names are fair game as well, so we could end up with a merged module as http.cookie. This would have basic parsing functions and then the current classes, appropriately renamed.
And no, I don't think every new package should have a client and server module. =)
Once you achieve your full zen, you'll realize that all client and server are the same, and all packages should have a net module. ;-) -Fred -- Fred Drake <fdrake at acm.org>
On Feb 5, 2008 12:34 PM, Fred Drake
On Feb 5, 2008, at 3:20 PM, Brett Cannon wrote:
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
I'm not aware of these being used with anything but HTTP (including HTTPS), so why not add them into the http package?
Because I don't want http.cookie.client.
I think the class names are fair game as well,
Why do you say that, Fred? That is not something 2to3 can handle very well. It would require a rename within the module along with a deprecation of the old name. Are you on the web SIG? Granted I would rather have this solution. =) I will ask the web SIG.
so we could end up with a merged module as http.cookie. This would have basic parsing functions and then the current classes, appropriately renamed.
And no, I don't think every new package should have a client and server module. =)
Once you achieve your full zen, you'll realize that all client and server are the same, and all packages should have a net module. ;-)
=) I thought zen would mean everything could just be named bruce? -Brett
On Feb 5, 2008, at 5:55 PM, Brett Cannon wrote:
Because I don't want http.cookie.client.
Right. I don't want it that deep either. That's why I suggested a single module, not a sub-package.
Why do you say that, Fred? That is not something 2to3 can handle very well. It would require a rename within the module along with a deprecation of the old name.
I've not played with 2to3 yet.
Are you on the web SIG?
Yes.
=) I thought zen would mean everything could just be named bruce?
Sigh. Your zen is more complete than mine. -Fred -- Fred Drake <fdrake at acm.org>
participants (2)
-
Brett Cannon
-
Fred Drake