From brett at python.org  Sun Feb  3 03:22:02 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 2 Feb 2008 18:22:02 -0800
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
Message-ID: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>

I just wanted to make sure no one had any issues with the proposed
http or xmlrpc packages before I add them to PEP 3108.

-Brett

From brett at python.org  Sun Feb  3 23:34:57 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 14:34:57 -0800
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <47A63E73.7060704@ibp.de>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de>
Message-ID: <bbaeab100802031434v60a6703bv68cc6a5a5e3f3cbf@mail.gmail.com>

On Feb 3, 2008 2:21 PM, Lars Immisch <lars at ibp.de> wrote:
> Hi,
>
> > I just wanted to make sure no one had any issues with the proposed
> > http or xmlrpc packages before I add them to PEP 3108.
>
> For what it's worth, I like the proposed scheme.

It's worth something. I was afraid my emails were not getting through
to the rest of the list. =) Plus the whole point of this is to make
sure I don't push for something that is too radical.

-Brett

From p.f.moore at gmail.com  Sun Feb  3 23:45:37 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 3 Feb 2008 22:45:37 +0000
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <bbaeab100802031434v60a6703bv68cc6a5a5e3f3cbf@mail.gmail.com>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de>
	<bbaeab100802031434v60a6703bv68cc6a5a5e3f3cbf@mail.gmail.com>
Message-ID: <79990c6b0802031445t742ee345s7578fcedb322a4af@mail.gmail.com>

On 03/02/2008, Brett Cannon <brett at python.org> wrote:
> On Feb 3, 2008 2:21 PM, Lars Immisch <lars at ibp.de> wrote:
> > Hi,
> >
> > > I just wanted to make sure no one had any issues with the proposed
> > > http or xmlrpc packages before I add them to PEP 3108.
> >
> > For what it's worth, I like the proposed scheme.
>
> It's worth something. I was afraid my emails were not getting through
> to the rest of the list. =) Plus the whole point of this is to make
> sure I don't push for something that is too radical.

I'm OK with it.
Paul

From lars at ibp.de  Sun Feb  3 23:21:39 2008
From: lars at ibp.de (Lars Immisch)
Date: Sun, 03 Feb 2008 23:21:39 +0100
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
Message-ID: <47A63E73.7060704@ibp.de>

Hi,

> I just wanted to make sure no one had any issues with the proposed
> http or xmlrpc packages before I add them to PEP 3108.

For what it's worth, I like the proposed scheme.

- Lars

From janssen at parc.com  Mon Feb  4 00:07:27 2008
From: janssen at parc.com (Bill Janssen)
Date: Sun, 3 Feb 2008 15:07:27 PST
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <47A63E73.7060704@ibp.de> 
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de>
Message-ID: <08Feb3.150730pst."58696"@synergy1.parc.xerox.com>

> > I just wanted to make sure no one had any issues with the proposed
> > http or xmlrpc packages before I add them to PEP 3108.
> 
> For what it's worth, I like the proposed scheme.

For what it's worth, I just joined this list.  What does the Web-SIG
think about them?  You might want to post the scheme there for more
feedback.

Bill

From brett at python.org  Mon Feb  4 00:10:16 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Feb 2008 15:10:16 -0800
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <6939371007697487044@unknownmsgid>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de> <6939371007697487044@unknownmsgid>
Message-ID: <bbaeab100802031510l647d7b8dy8b99569d94849164@mail.gmail.com>

On Feb 3, 2008 3:07 PM, Bill Janssen <janssen at parc.com> wrote:
> > > I just wanted to make sure no one had any issues with the proposed
> > > http or xmlrpc packages before I add them to PEP 3108.
> >
> > For what it's worth, I like the proposed scheme.
>
> For what it's worth, I just joined this list.  What does the Web-SIG
> think about them?  You might want to post the scheme there for more
> feedback.

You can if you want, Bill, but I don't want our process getting tied
into other groups. Besides, this is just renaming, not the removal of
any code. I honestly don't see it as part of their domain.

-Brett

From janssen at parc.com  Mon Feb  4 06:06:24 2008
From: janssen at parc.com (Bill Janssen)
Date: Sun, 3 Feb 2008 21:06:24 PST
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <08Feb3.150730pst."58696"@synergy1.parc.xerox.com> 
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de>
	<08Feb3.150730pst."58696"@synergy1.parc.xerox.com>
Message-ID: <08Feb3.210631pst."58696"@synergy1.parc.xerox.com>

I'm good with the proposed HTTP re-org, but I think the XML-RPC
classes should also go into the "http." package (http.tools or
http.server as appropriate) -- there's nothing magical about XML-RPC.

Maybe a subpackage, "http.xmlrpc".

I also think putting server classes into "http.server", but putting
the client-side code, httplib, into "http.tools", is a bit lopsided.
True, httplib is a mix of client-side and general utility functions,
but still...  But that's a minor nit.  On the other hand, if we're
going to mess around with the locations, might as well get it right
the first time.

Bill

From kevin at bud.ca  Mon Feb  4 08:15:42 2008
From: kevin at bud.ca (Kevin Teague)
Date: Sun, 3 Feb 2008 23:15:42 -0800
Subject: [stdlib-sig]  Any feedback on proposed http and xmlrpc packages?
Message-ID: <8238C909-3B8B-4E3B-AA42-C57149DF92DF@bud.ca>

I would prefer xmlrpc.client over xmlrpc.tools and http.client over  
http.tools.

The documentation and comments for these modules refer to them as  
client libraries. They do have some bits that could be used as tools,  
but I would guess that the vast majority of uses are as clients. The  
examples and test suites in these modules also only deals with the  
client use case, they don't test or demonstrate the tools portion of  
the code.

-1 on http.xmlrpc.client. Yes, XML-RPC uses HTTP as a transport, but  
then HTTP uses TCP/IP as a transport, which would suggest  
socket.http.xmlrpc or tcpip.http.xmlrpc. HTTP is an implementation  
detail of XML-RPC. I've trained a number of bioinformaticians to use  
XML-RPC and for better or worse they are usually oblivious to HTTP.  
They can usually solve their XML-RPC needs with the abstraction of  
"XML-RPC communicates over the network to talk to remote servers"  
without needing to know any specifics about HTTP.



http://docs.python.org/lib/module-xmlrpclib.html

"XML-RPC client access"

xmlrpclib.py:
#
# $Id: xmlrpclib.py 38463 2005-02-11 18:00:16Z fdrake $
#
# an XML-RPC client interface for Python.
#
# the marshalling and response parser code can also be used to
# implement XML-RPC servers.
#


http://docs.python.org/lib/module-httplib.html

"HTTP protocol client"

httplib.py:
"""HTTP/1.1 client library


From mal at egenix.com  Mon Feb  4 11:13:00 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 04 Feb 2008 11:13:00 +0100
Subject: [stdlib-sig] http package proposal
In-Reply-To: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>
References: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>
Message-ID: <47A6E52C.50902@egenix.com>

On 2008-01-30 00:38, Brett Cannon wrote:
> OK, to keep this ball rolling, here is my suggestion for reorganizing
> HTTP modules:
> 
> httplib -> http.tools

httplib implements the state machine for an HTTP client, so
why not http.client ?

> BaseHTTPServer -> http.server
> SimpleHTTPServer -> http.server
> CGIHTTPServer -> http.server

> cookielib -> http.cookies

Why plural ?

-1 on adding xmlrpc to the http package.

Better to have:

xmlrpclib -> xmlrpc.client
SimpleXMLRPCServer -> xmlrpc.server

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 04 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From christian at cheimes.de  Mon Feb  4 16:02:26 2008
From: christian at cheimes.de (Christian Heimes)
Date: Mon, 04 Feb 2008 16:02:26 +0100
Subject: [stdlib-sig] http package proposal
In-Reply-To: <47A6E52C.50902@egenix.com>
References: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>
	<47A6E52C.50902@egenix.com>
Message-ID: <47A72902.3060600@cheimes.de>

M.-A. Lemburg wrote:
>> cookielib -> http.cookies
> 
> Why plural ?

The plural form feels more natural to me. I haven't seen the singular
form "browser cookie" in a long time.

> -1 on adding xmlrpc to the http package.
> 
> Better to have:
> 
> xmlrpclib -> xmlrpc.client
> SimpleXMLRPCServer -> xmlrpc.server

+1 for xmlrpc package.

Christian



From mal at egenix.com  Mon Feb  4 16:21:16 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 04 Feb 2008 16:21:16 +0100
Subject: [stdlib-sig] http package proposal
In-Reply-To: <47A72902.3060600@cheimes.de>
References: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>	<47A6E52C.50902@egenix.com>
	<47A72902.3060600@cheimes.de>
Message-ID: <47A72D6C.1050904@egenix.com>

On 2008-02-04 16:02, Christian Heimes wrote:
> M.-A. Lemburg wrote:
>>> cookielib -> http.cookies
>> Why plural ?
> 
> The plural form feels more natural to me. I haven't seen the singular
> form "browser cookie" in a long time.

It's actually more about convention than actual use :-)

If we name the module http.cookies, we'd also have to
name the server module http.servers, since there are
multiple server implementations included.

However, you normally don't do this in code libraries (see
e.g Java).

>> -1 on adding xmlrpc to the http package.
>>
>> Better to have:
>>
>> xmlrpclib -> xmlrpc.client
>> SimpleXMLRPCServer -> xmlrpc.server
> 
> +1 for xmlrpc package.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 04 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From janssen at parc.com  Mon Feb  4 16:33:02 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 4 Feb 2008 07:33:02 PST
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <8238C909-3B8B-4E3B-AA42-C57149DF92DF@bud.ca> 
References: <8238C909-3B8B-4E3B-AA42-C57149DF92DF@bud.ca>
Message-ID: <08Feb4.073307pst."58696"@synergy1.parc.xerox.com>

> Yes, XML-RPC uses HTTP as a transport, but  
> then HTTP uses TCP/IP as a transport, which would suggest  
> socket.http.xmlrpc or tcpip.http.xmlrpc.

Ah, good suggestion :-).  tcpip.http.xmlrpc, I'd think.

Why not make the top-level package "web" instead  of "http"?

Bill

From solipsis at pitrou.net  Mon Feb  4 16:38:26 2008
From: solipsis at pitrou.net (Antoine)
Date: Mon, 4 Feb 2008 16:38:26 +0100 (CET)
Subject: [stdlib-sig] http package proposal
In-Reply-To: <47A72D6C.1050904@egenix.com>
References: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>	<47A6E52C.50902@egenix.com>
	<47A72902.3060600@cheimes.de> <47A72D6C.1050904@egenix.com>
Message-ID: <33432.82.66.243.168.1202139506.squirrel@webmail.nerim.net>

> It's actually more about convention than actual use :-)
>
> If we name the module http.cookies, we'd also have to
> name the server module http.servers, since there are
> multiple server implementations included.

http.cookies is about managing cookies, i.e. you often manage several
cookies at a time. On the other hand you seldom launch several HTTP
servers in the same program. The difference looks natural to me.




From mal at egenix.com  Mon Feb  4 18:09:15 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 04 Feb 2008 18:09:15 +0100
Subject: [stdlib-sig] http package proposal
In-Reply-To: <33432.82.66.243.168.1202139506.squirrel@webmail.nerim.net>
References: <bbaeab100801291538y38b8cefbl320d0ed8af8f7ea4@mail.gmail.com>	<47A6E52C.50902@egenix.com>	<47A72902.3060600@cheimes.de>
	<47A72D6C.1050904@egenix.com>
	<33432.82.66.243.168.1202139506.squirrel@webmail.nerim.net>
Message-ID: <47A746BB.1030100@egenix.com>

On 2008-02-04 16:38, Antoine wrote:
>> It's actually more about convention than actual use :-)
>>
>> If we name the module http.cookies, we'd also have to
>> name the server module http.servers, since there are
>> multiple server implementations included.
> 
> http.cookies is about managing cookies, i.e. you often manage several
> cookies at a time. On the other hand you seldom launch several HTTP
> servers in the same program. The difference looks natural to me.

Like I said: it's a matter of convention.

There are other instances in the stdlib where one or the other
style is used, e.g. codecs, types, pipes, collestions vs. re,
decimal, datetime, Queue.

While we're at it, we could cleanup those as well and stick
with one naming scheme.

I don't have a clear favorite, except that other language
libraries use the singular form throughout.

Perhaps all that's needed is a spelled-out more complex convention
which makes it clear why http.server uses the singular form, while
http.cookies is plural.

Another nit: some modules are named ...lib, while others do not
include this suffix. It's not quite clear why a modules that's
already part of the standard lib needs to have the "...lib" suffix.
This is also not handled in a consistent manner, e.g.
hashlib, ftplib, htmllib vs. xml, subprocess, shelve.

I'd be in favor of dropping the "lib" suffixes.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 04 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Mon Feb  4 20:13:30 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 11:13:30 -0800
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <363393071777541167@unknownmsgid>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de> <363393071777541167@unknownmsgid>
Message-ID: <bbaeab100802041113k5c0cfdf2i5181260b11484997@mail.gmail.com>

On Feb 3, 2008 9:06 PM, Bill Janssen <janssen at parc.com> wrote:
> I'm good with the proposed HTTP re-org, but I think the XML-RPC
> classes should also go into the "http." package (http.tools or
> http.server as appropriate) -- there's nothing magical about XML-RPC.
>

Well, it's an RPC protocol, not something specific to HTTP. It might
use HTTP as its transport agent, but that's its only connection. When
I think "XML-RPC", I don't automatically think, "I should look in the
HTTP section of the standard library". I think either XML-RPC or RPC
protocols.

> Maybe a subpackage, "http.xmlrpc".
>

Problem with that is Guido said he wants any renaming to make the name
as simple if not simpler. Sticking XML-RPC libraries into http does
not do that. Plus there is a general agreement that these new packages
will only be one level deep.

> I also think putting server classes into "http.server", but putting
> the client-side code, httplib, into "http.tools", is a bit lopsided.
> True, httplib is a mix of client-side and general utility functions,
> but still...  But that's a minor nit.  On the other hand, if we're
> going to mess around with the locations, might as well get it right
> the first time.
>

Sure, but what is right? The reason it has taken this long and led to
the creation of a separate mailing list is because everyone's "right"
is different. We are going to end up with a better solution, but there
is not right solution.

-Brett

From janssen at parc.com  Mon Feb  4 20:28:27 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 4 Feb 2008 11:28:27 PST
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <bbaeab100802041113k5c0cfdf2i5181260b11484997@mail.gmail.com> 
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de> <363393071777541167@unknownmsgid>
	<bbaeab100802041113k5c0cfdf2i5181260b11484997@mail.gmail.com>
Message-ID: <08Feb4.112833pst."58696"@synergy1.parc.xerox.com>

> Well, it's an RPC protocol, not something specific to HTTP. It might
> use HTTP as its transport agent, but that's its only connection.

Huh?  That's its main distinction -- it uses (badly) a buggy slow
inefficient but perceived-to-be-easy-to-implement RPC subsystem, HTTP.
I guess I'm just looking at it from the perspective of an RPC guy.

> Sure, but what is right? The reason it has taken this long and led to
> the creation of a separate mailing list is because everyone's "right"
> is different. We are going to end up with a better solution, but there
> is not right solution.

Actually, two different separate mailing lists.

> We are going to end up with a better solution, but there
> is not right solution.

It has to be enough better to be worth doing.  I'm not sure we're
there yet, and just trying to help us get there.

Bill

From brett at python.org  Mon Feb  4 20:31:23 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 11:31:23 -0800
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <3942393226181917335@unknownmsgid>
References: <8238C909-3B8B-4E3B-AA42-C57149DF92DF@bud.ca>
	<3942393226181917335@unknownmsgid>
Message-ID: <bbaeab100802041131v6b0db191o47393daa1ffe1a6c@mail.gmail.com>

On Feb 4, 2008 7:33 AM, Bill Janssen <janssen at parc.com> wrote:
> > Yes, XML-RPC uses HTTP as a transport, but
> > then HTTP uses TCP/IP as a transport, which would suggest
> > socket.http.xmlrpc or tcpip.http.xmlrpc.
>
> Ah, good suggestion :-).  tcpip.http.xmlrpc, I'd think.
>
> Why not make the top-level package "web" instead  of "http"?

Because not every web-based module can be put into a web package with
it's name being improved. Think of the groupings as along the lines of
concrete connections like HTTP, not abstract ideas like the web.

-Brett

From brett at python.org  Mon Feb  4 20:38:00 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 11:38:00 -0800
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
Message-ID: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>

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

From alexandre at peadrop.com  Mon Feb  4 20:54:24 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 4 Feb 2008 14:54:24 -0500
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <363393071777541167@unknownmsgid>
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de> <363393071777541167@unknownmsgid>
Message-ID: <acd65fa20802041154y26479c32ya72c440619d78a2@mail.gmail.com>

On Feb 4, 2008 12:06 AM, Bill Janssen <janssen at parc.com> wrote:
> Maybe a subpackage, "http.xmlrpc".
>

Yuck. That is just unnecessary duplication of information. XML-RPC, by
definition, uses HTTP as the transport mechanism. So, I see no point
in adding yet another level of packaging. Remember, the subpackages
are meant to make the module names shorter, not longer.

-- Alexandre

From janssen at parc.com  Mon Feb  4 21:44:28 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 4 Feb 2008 12:44:28 PST
Subject: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
In-Reply-To: <acd65fa20802041154y26479c32ya72c440619d78a2@mail.gmail.com> 
References: <bbaeab100802021822o44fb9f45ud3217a7e5e4124c9@mail.gmail.com>
	<47A63E73.7060704@ibp.de> <363393071777541167@unknownmsgid>
	<acd65fa20802041154y26479c32ya72c440619d78a2@mail.gmail.com>
Message-ID: <08Feb4.124429pst."58696"@synergy1.parc.xerox.com>

> Remember, the subpackages
> are meant to make the module names shorter, not longer.

Ah!  I'd thought it was to organize things a bit -- I hadn't realized
shortness was a prime criterion.

Bill

From alexandre at peadrop.com  Mon Feb  4 22:03:11 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 4 Feb 2008 16:03:11 -0500
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
In-Reply-To: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
References: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
Message-ID: <acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>

On Feb 4, 2008 2:38 PM, Brett Cannon <brett at python.org> wrote:
> So the suggestions now are:
>
> httplib ->http.client
> http.server proposal stays.
>
> xmlrpclib -> xmlrpc.client
> xmlrpc.server proposal stays.
>

`xmlrpclib` also contains (un)marshaling tools, so it's not strictly a
client library. Anyway, I like the "client" subpackage name more than
"tools."

> 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.

Well, I never used either cookie modules, so I can't really comment
about them. However, I found by reading through the documentation and
the code that both modules have a fairly different purpose.
`cookielib` is used for collecting cookies on the client-side (often
with urllib2), while `Cookie` is used to generate cookie on the
server-side.

-- Alexandre

From brett at python.org  Mon Feb  4 22:12:38 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 13:12:38 -0800
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
In-Reply-To: <acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
References: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
	<acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
Message-ID: <bbaeab100802041312s2657772jee009b93c4ae9c53@mail.gmail.com>

On Feb 4, 2008 1:03 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On Feb 4, 2008 2:38 PM, Brett Cannon <brett at python.org> wrote:
> > So the suggestions now are:
> >
> > httplib ->http.client
> > http.server proposal stays.
> >
> > xmlrpclib -> xmlrpc.client
> > xmlrpc.server proposal stays.
> >
>
> `xmlrpclib` also contains (un)marshaling tools, so it's not strictly a
> client library. Anyway, I like the "client" subpackage name more than
> "tools."
>
> > 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.
>
> Well, I never used either cookie modules, so I can't really comment
> about them. However, I found by reading through the documentation and
> the code that both modules have a fairly different purpose.
> `cookielib` is used for collecting cookies on the client-side (often
> with urllib2), while `Cookie` is used to generate cookie on the
> server-side.

That is what I am starting to realize. If I had my way I would want to
rename them:

cookielib -> cookie.client
Cookie -> cookie.server

But that does not exactly follow Guido's shorter name desire. But
considering Cookie breaks the naming scheme as it is and thus will
have to be renamed and cookie is rather generic, we might be able to
get away with this renaming. What do people think?

-Brett

From solipsis at pitrou.net  Mon Feb  4 23:02:42 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 04 Feb 2008 23:02:42 +0100
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
In-Reply-To: <bbaeab100802041312s2657772jee009b93c4ae9c53@mail.gmail.com>
References: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
	<acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
	<bbaeab100802041312s2657772jee009b93c4ae9c53@mail.gmail.com>
Message-ID: <1202162562.7740.11.camel@fsol>


Le lundi 04 f?vrier 2008 ? 13:12 -0800, Brett Cannon a ?crit :
> That is what I am starting to realize. If I had my way I would want to
> rename them:
> 
> cookielib -> cookie.client
> Cookie -> cookie.server
> 
> But that does not exactly follow Guido's shorter name desire. But
> considering Cookie breaks the naming scheme as it is and thus will
> have to be renamed and cookie is rather generic, we might be able to
> get away with this renaming. What do people think?

It sounds a bit bizarre to me. There is no such thing as a "cookie
server" or "cookie client". On the other hand "cookie.clientstorage" and
"cookie.serverstorage" is certainly too long.

It is also strange that Cookie and cookielib do not seem to share any
code (not even for parsing or encoding cookies).




From brett at python.org  Mon Feb  4 23:07:34 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 4 Feb 2008 14:07:34 -0800
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
In-Reply-To: <1202162562.7740.11.camel@fsol>
References: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
	<acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
	<bbaeab100802041312s2657772jee009b93c4ae9c53@mail.gmail.com>
	<1202162562.7740.11.camel@fsol>
Message-ID: <bbaeab100802041407r63efb1dfp7023e4c8e38e5ab3@mail.gmail.com>

On Feb 4, 2008 2:02 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le lundi 04 f?vrier 2008 ? 13:12 -0800, Brett Cannon a ?crit :
> > That is what I am starting to realize. If I had my way I would want to
> > rename them:
> >
> > cookielib -> cookie.client
> > Cookie -> cookie.server
> >
> > But that does not exactly follow Guido's shorter name desire. But
> > considering Cookie breaks the naming scheme as it is and thus will
> > have to be renamed and cookie is rather generic, we might be able to
> > get away with this renaming. What do people think?
>
> It sounds a bit bizarre to me. There is no such thing as a "cookie
> server" or "cookie client". On the other hand "cookie.clientstorage" and
> "cookie.serverstorage" is certainly too long.
>
> It is also strange that Cookie and cookielib do not seem to share any
> code (not even for parsing or encoding cookies).

Different authors and they were added at different times in Python's
history. If we can expose what is needed to replace Cookie from
cookielib we can probably work to toss Cookie in Py3K.

-Brett

From brett at python.org  Tue Feb  5 21:16:42 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 5 Feb 2008 12:16:42 -0800
Subject: [stdlib-sig] Suggested tweaks to http and xmlrpc packages
In-Reply-To: <acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
References: <bbaeab100802041138r40a081b9xeaa73a37b9b2c6a9@mail.gmail.com>
	<acd65fa20802041303v483e4d65nfb1b786271b9e218@mail.gmail.com>
Message-ID: <bbaeab100802051216j11938592g9979b18b408fafac@mail.gmail.com>

On Feb 4, 2008 1:03 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On Feb 4, 2008 2:38 PM, Brett Cannon <brett at python.org> wrote:
> > So the suggestions now are:
> >
> > httplib ->http.client
> > http.server proposal stays.
> >
> > xmlrpclib -> xmlrpc.client
> > xmlrpc.server proposal stays.
> >
>
> `xmlrpclib` also contains (un)marshaling tools, so it's not strictly a
> client library. Anyway, I like the "client" subpackage name more than
> "tools."
>

Well, I went ahead and made the change in the PEP (since the renamings
won't happen until Guido clears the PEP none of this is in stone,
although I don't want to constantly change the PEP either).

-Brett

From brett at python.org  Tue Feb  5 21:20:28 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 5 Feb 2008 12:20:28 -0800
Subject: [stdlib-sig] Organizing the cookie modules
Message-ID: <bbaeab100802051220x275a550ei5bc77f764933fcc8@mail.gmail.com>

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

From fdrake at acm.org  Tue Feb  5 21:34:42 2008
From: fdrake at acm.org (Fred Drake)
Date: Tue, 5 Feb 2008 15:34:42 -0500
Subject: [stdlib-sig] Organizing the cookie modules
In-Reply-To: <bbaeab100802051220x275a550ei5bc77f764933fcc8@mail.gmail.com>
References: <bbaeab100802051220x275a550ei5bc77f764933fcc8@mail.gmail.com>
Message-ID: <200C98DC-5131-4C59-8502-32A7E0A3415E@acm.org>

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>





From brett at python.org  Tue Feb  5 23:55:42 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 5 Feb 2008 14:55:42 -0800
Subject: [stdlib-sig] Organizing the cookie modules
In-Reply-To: <200C98DC-5131-4C59-8502-32A7E0A3415E@acm.org>
References: <bbaeab100802051220x275a550ei5bc77f764933fcc8@mail.gmail.com>
	<200C98DC-5131-4C59-8502-32A7E0A3415E@acm.org>
Message-ID: <bbaeab100802051455p6dc21c2ehf5c5da6f83a47ddf@mail.gmail.com>

On Feb 5, 2008 12:34 PM, Fred Drake <fdrake at acm.org> wrote:
> 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

From fdrake at acm.org  Wed Feb  6 00:03:33 2008
From: fdrake at acm.org (Fred Drake)
Date: Tue, 5 Feb 2008 18:03:33 -0500
Subject: [stdlib-sig] Organizing the cookie modules
In-Reply-To: <bbaeab100802051455p6dc21c2ehf5c5da6f83a47ddf@mail.gmail.com>
References: <bbaeab100802051220x275a550ei5bc77f764933fcc8@mail.gmail.com>
	<200C98DC-5131-4C59-8502-32A7E0A3415E@acm.org>
	<bbaeab100802051455p6dc21c2ehf5c5da6f83a47ddf@mail.gmail.com>
Message-ID: <F6512F54-B9AD-4A88-92BA-1E2253BFE3A6@acm.org>

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>





From brett at python.org  Wed Feb 20 10:49:32 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 01:49:32 -0800
Subject: [stdlib-sig] html package idea
Message-ID: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>

Here is an idea for an html package:

htmlentitydefs -> html.entities
htmllib -> html.tools
HTMLParser -> html.parser

What do people think?

-Brett

From mal at egenix.com  Wed Feb 20 10:51:08 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 10:51:08 +0100
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
Message-ID: <47BBF80C.30809@egenix.com>

On 2008-02-20 10:49, Brett Cannon wrote:
> Here is an idea for an html package:
> 
> htmlentitydefs -> html.entities
> htmllib -> html.tools
> HTMLParser -> html.parser
> 
> What do people think?

+1

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From christian at cheimes.de  Wed Feb 20 10:59:10 2008
From: christian at cheimes.de (Christian Heimes)
Date: Wed, 20 Feb 2008 10:59:10 +0100
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
Message-ID: <47BBF9EE.9030905@cheimes.de>

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

+1

What about markupbase and sgml?

markupbase -> html.markup ?

or:

sgmllib -> sgml.parser
markupbase -> sgml.base

with aliases sgml.SGMLParser and sgml.SGMLParserError

Christian

From brett at python.org  Wed Feb 20 11:05:51 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 02:05:51 -0800
Subject: [stdlib-sig] tkinter package idea
Message-ID: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>

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

From brett at python.org  Wed Feb 20 11:15:20 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 02:15:20 -0800
Subject: [stdlib-sig] html package idea
In-Reply-To: <47BBF9EE.9030905@cheimes.de>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<47BBF9EE.9030905@cheimes.de>
Message-ID: <bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>

On Feb 20, 2008 1:59 AM, Christian Heimes <christian at cheimes.de> wrote:
>
> Brett Cannon wrote:
> > Here is an idea for an html package:
> >
> > htmlentitydefs -> html.entities
> > htmllib -> html.tools
> > HTMLParser -> html.parser
> >
> > What do people think?
>
> +1
>
> What about markupbase and sgml?
>

markupbase has no public API and has already been renamed _markupbase.

As for sgmllib, since it only exists for htmllib, I say it should be
merged into html.tools since there is no naming conflicts.

But I just realized htmllib itself is a parser for html. So naming it
html.tools seems wrong.

Perhaps it should be:

htmlentitydefs -> html.entities
htmllib -> html.parser
sgmllib -> html.parser
HTMLParser -> html.xparser

That way the two different parsers are both delineated as parsers, but
the fact that HTMLParser handles XHTML is covered.

I will also ask the web-sig if both parsers are really needed.

-Brett

From mal at egenix.com  Wed Feb 20 11:27:14 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 11:27:14 +0100
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
Message-ID: <47BC0082.1030006@egenix.com>

On 2008-02-20 11:05, Brett Cannon wrote:
> 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.

Hey, it's Py3k...

> 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.

I usually put all the package top-level code into a separate
module with the same name as the package.

__init__.py then imports all the necessary symbols from that
module.

These are problems I've had with putting code into __init__.py:

* if there's a bug in __init__.py it's impossible to load
  sub-modules/packages; if you import the code from another
  module, you can wrap that into try-except and still get
  access to the sub-modules

* a user will typically not look into __init__.py to find
  code


If you name the package "tk" you could name the main module
"inter" and then end up with "tk.inter" which again resembles
the widespread Tkinter name.

I'd much rather see Tkinter and all the other bits be split
from the core and placed into a separate distribution, but the
IDLE fans would probably not like that.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Wed Feb 20 11:32:31 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 02:32:31 -0800
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <47BC0082.1030006@egenix.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
	<47BC0082.1030006@egenix.com>
Message-ID: <bbaeab100802200232p1bb80f5bj6ba39f88da0f63b3@mail.gmail.com>

On Feb 20, 2008 2:27 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 2008-02-20 11:05, Brett Cannon wrote:
> > 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.
>
> Hey, it's Py3k...
>
> > 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.
>
> I usually put all the package top-level code into a separate
> module with the same name as the package.
>
> __init__.py then imports all the necessary symbols from that
> module.
>

Right. tkinter.__init__ would just import * from _tkinter anyway.

> These are problems I've had with putting code into __init__.py:
>
> * if there's a bug in __init__.py it's impossible to load
>   sub-modules/packages; if you import the code from another
>   module, you can wrap that into try-except and still get
>   access to the sub-modules
>
> * a user will typically not look into __init__.py to find
>   code
>
>
> If you name the package "tk" you could name the main module
> "inter" and then end up with "tk.inter" which again resembles
> the widespread Tkinter name.
>

FIne by me. What do other people think?

> I'd much rather see Tkinter and all the other bits be split
> from the core and placed into a separate distribution, but the
> IDLE fans would probably not like that.

Perhaps its time to move IDLE out of the core and into its own
project. idlefork seemed to do fine when it was a separate project on
SF. I know it has been cute to have an IDE included with Python, but
we can also just make it an easy download as well to continue to have
a simple IDE available for new programmers to use.

-Brett

From brett at python.org  Wed Feb 20 11:39:09 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 02:39:09 -0800
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
Message-ID: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>

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

From python at rcn.com  Wed Feb 20 11:29:24 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 20 Feb 2008 02:29:24 -0800
Subject: [stdlib-sig] html package idea
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
Message-ID: <001401c873ab$775c7910$6800a8c0@RaymondLaptop1>

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

That looks like a very reasonable grouping and naming convention.


Raymond

From mal at egenix.com  Wed Feb 20 11:59:43 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 11:59:43 +0100
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>	<47BBF9EE.9030905@cheimes.de>
	<bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>
Message-ID: <47BC081F.1040005@egenix.com>

On 2008-02-20 11:15, Brett Cannon wrote:
> On Feb 20, 2008 1:59 AM, Christian Heimes <christian at cheimes.de> wrote:
>> Brett Cannon wrote:
>>> Here is an idea for an html package:
>>>
>>> htmlentitydefs -> html.entities
>>> htmllib -> html.tools
>>> HTMLParser -> html.parser
>>>
>>> What do people think?
>> +1
>>
>> What about markupbase and sgml?
>>
> 
> markupbase has no public API and has already been renamed _markupbase.
> 
> As for sgmllib, since it only exists for htmllib, I say it should be
> merged into html.tools since there is no naming conflicts.

-1. SGML is a much more general markup language than HTML.

It's true that only htmllib does use sgmllib in the std lib,
but there are applications out there that rely on sgmllib
for the SGML part, e.g. ones implementing the DocBook tool
chain.

> But I just realized htmllib itself is a parser for html. So naming it
> html.tools seems wrong.
> 
> Perhaps it should be:
> 
> htmlentitydefs -> html.entities
> htmllib -> html.parser
> sgmllib -> html.parser
> HTMLParser -> html.xparser
> 
> That way the two different parsers are both delineated as parsers, but
> the fact that HTMLParser handles XHTML is covered.
> 
> I will also ask the web-sig if both parsers are really needed.
> 
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From rrr at ronadam.com  Wed Feb 20 14:14:51 2008
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 20 Feb 2008 07:14:51 -0600
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <47BC0082.1030006@egenix.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
	<47BC0082.1030006@egenix.com>
Message-ID: <47BC27CB.6020704@ronadam.com>



M.-A. Lemburg wrote:
> On 2008-02-20 11:05, Brett Cannon wrote:
>> 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.
> 
> Hey, it's Py3k...

+ 1


>> So here is my current thinking:
>>
>> Tkinter -> tkinter.__init__

Possibly

    Tkinter -> tk.tkinter

and have tk.__init__ import it with "from tk.tkinter import *"?


From facundobatista at gmail.com  Wed Feb 20 16:45:36 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Wed, 20 Feb 2008 12:45:36 -0300
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
In-Reply-To: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
Message-ID: <e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>

2008/2/20, Brett Cannon <brett at python.org>:

>  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.

OTOH, I think that having a module called urllib, and other called
urllib2 is a result of the evolution and not the best configuration.

The web-sig or python-dev should pronounce what to do with this.

IMHO, the best is to have one module, with the best of both worlds.

What to do with the methods that will be lost because of keeping a
slightly different one with the same functionality? We could keep them
with a deprecation warning, or simply let them disappear (+0 for the
former, even considering we're in 3k).

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From christian at cheimes.de  Wed Feb 20 17:22:57 2008
From: christian at cheimes.de (Christian Heimes)
Date: Wed, 20 Feb 2008 17:22:57 +0100
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
 and urlparse?
In-Reply-To: <e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
Message-ID: <47BC53E1.60104@cheimes.de>

Facundo Batista wrote:
> What to do with the methods that will be lost because of keeping a
> slightly different one with the same functionality? We could keep them
> with a deprecation warning, or simply let them disappear (+0 for the
> former, even considering we're in 3k).

Merging urllib and urllib2 into a completely new module with a (although
slightly) different API is a good thing. But it also increases the
burden and workload for Python users. We should keep the original
modules around if a change can't be handled by a 2to3 fixer. We can
always deprecate a module for 3.1.

For urllib/urllib2 I propose:

* merge the functionality into a new, improved module
* keep the original ones around for 3.0 and schedule them for removal in
3.1.

Christian

From mal at egenix.com  Wed Feb 20 17:47:40 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 17:47:40 +0100
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
 and urlparse?
In-Reply-To: <47BC53E1.60104@cheimes.de>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
	<47BC53E1.60104@cheimes.de>
Message-ID: <47BC59AC.1010508@egenix.com>

Christian Heimes wrote:
> Facundo Batista wrote:
>> What to do with the methods that will be lost because of keeping a
>> slightly different one with the same functionality? We could keep them
>> with a deprecation warning, or simply let them disappear (+0 for the
>> former, even considering we're in 3k).
> 
> Merging urllib and urllib2 into a completely new module with a (although
> slightly) different API is a good thing. But it also increases the
> burden and workload for Python users. We should keep the original
> modules around if a change can't be handled by a 2to3 fixer. We can
> always deprecate a module for 3.1.
> 
> For urllib/urllib2 I propose:
> 
> * merge the functionality into a new, improved module
> * keep the original ones around for 3.0 and schedule them for removal in
> 3.1.

I'm not sure that would work: urllib is one of the most used modules
in Python when it comes to doing even only slightly web-related
work.

I've never used urllib2 and am not sure what the reason was for
adding it. It doesn't appear to offer more or better things than
urllib... to late to argue, I guess ;-)

In any case, deprecating a module after the jump to 3.0 is more
problematic than during the major version number change.

How about using the following mapping:

urllib  -> url.fetch
urllib2 -> url.request

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From fdrake at acm.org  Wed Feb 20 18:24:01 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 12:24:01 -0500
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
Message-ID: <8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>

On Feb 20, 2008, at 4:49 AM, Brett Cannon wrote:
> htmlentitydefs -> html.entities
> htmllib -> html.tools
> HTMLParser -> html.parser

Drop htmllib (html.tools) completely, and you're good to go.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From fdrake at acm.org  Wed Feb 20 18:40:39 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 12:40:39 -0500
Subject: [stdlib-sig] html package idea
In-Reply-To: <47BC081F.1040005@egenix.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>	<47BBF9EE.9030905@cheimes.de>
	<bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>
	<47BC081F.1040005@egenix.com>
Message-ID: <40403B86-6E9F-43C8-8C53-BDB415CBA9BA@acm.org>

On Feb 20, 2008, at 5:59 AM, M.-A. Lemburg wrote:
> -1. SGML is a much more general markup language than HTML.

Certainly.  sgmllib doesn't handle the general case, and is unlikely  
to be reasonably extensible to support a substantial subset of SGML.

> It's true that only htmllib does use sgmllib in the std lib,
> but there are applications out there that rely on sgmllib
> for the SGML part, e.g. ones implementing the DocBook tool
> chain.

I'd strongly encourage anyone who wants to use Python for general SGML  
parsing to either fork sgmllib (with a new name) and give it a real  
go, or integrate an existing SGML parser.  Pretending that sgmllib is  
really a usable SGML parser doesn't seem like a good idea.  It's also  
not widely enough used that it makes sense to have such a beast in the  
standard library.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From steven.bethard at gmail.com  Wed Feb 20 19:12:19 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Wed, 20 Feb 2008 11:12:19 -0700
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
In-Reply-To: <47BC59AC.1010508@egenix.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
	<47BC53E1.60104@cheimes.de> <47BC59AC.1010508@egenix.com>
Message-ID: <d11dcfba0802201012u34df8744vb58272c62f1666a1@mail.gmail.com>

On Feb 20, 2008 9:47 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Christian Heimes wrote:
> > Facundo Batista wrote:
> >> What to do with the methods that will be lost because of keeping a
> >> slightly different one with the same functionality? We could keep them
> >> with a deprecation warning, or simply let them disappear (+0 for the
> >> former, even considering we're in 3k).
> >
> > Merging urllib and urllib2 into a completely new module with a (although
> > slightly) different API is a good thing. But it also increases the
> > burden and workload for Python users. We should keep the original
> > modules around if a change can't be handled by a 2to3 fixer. We can
> > always deprecate a module for 3.1.
> >
> > For urllib/urllib2 I propose:
> >
> > * merge the functionality into a new, improved module
> > * keep the original ones around for 3.0 and schedule them for removal in
> > 3.1.
>
> I'm not sure that would work: urllib is one of the most used modules
> in Python when it comes to doing even only slightly web-related
> work.
>
> I've never used urllib2 and am not sure what the reason was for
> adding it. It doesn't appear to offer more or better things than
> urllib... to late to argue, I guess ;-)

I'm pretty sure the intent of urllib2 is to give better error messages
than urllib.  I only use urllib2 in my own code for that reason.  (I
don't remember what confusing error I got from urllib that made me
switch, but I remember that there was one.)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From brett at python.org  Wed Feb 20 21:16:23 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:16:23 -0800
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <47BC27CB.6020704@ronadam.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
	<47BC0082.1030006@egenix.com> <47BC27CB.6020704@ronadam.com>
Message-ID: <bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>

On Feb 20, 2008 5:14 AM, Ron Adam <rrr at ronadam.com> wrote:
>
>
> M.-A. Lemburg wrote:
> > On 2008-02-20 11:05, Brett Cannon wrote:
> >> 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.
> >
> > Hey, it's Py3k...
>
> + 1
>

Is that for the removal or the package name of tk? Question applies to
MAL as well as I forgot to ask that of him when he made the Py3K
comment.

>
> >> So here is my current thinking:
> >>
> >> Tkinter -> tkinter.__init__
>
> Possibly
>
>     Tkinter -> tk.tkinter
>
> and have tk.__init__ import it with "from tk.tkinter import *"?

I would rather do tk.inter than that amount of repetition in the
package/module name.

-Brett

From brett at python.org  Wed Feb 20 21:18:36 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:18:36 -0800
Subject: [stdlib-sig] html package idea
In-Reply-To: <8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
Message-ID: <bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>

On Feb 20, 2008 9:24 AM, Fred Drake <fdrake at acm.org> wrote:
> On Feb 20, 2008, at 4:49 AM, Brett Cannon wrote:
> > htmlentitydefs -> html.entities
> > htmllib -> html.tools
> > HTMLParser -> html.parser
>
> Drop htmllib (html.tools) completely, and you're good to go.
>

I have not finished reading my email, but I hope the web-sig likes
that idea since that is what I would like to see happen as well.

-Brett

From brett at python.org  Wed Feb 20 21:20:16 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:20:16 -0800
Subject: [stdlib-sig] html package idea
In-Reply-To: <40403B86-6E9F-43C8-8C53-BDB415CBA9BA@acm.org>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<47BBF9EE.9030905@cheimes.de>
	<bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>
	<47BC081F.1040005@egenix.com>
	<40403B86-6E9F-43C8-8C53-BDB415CBA9BA@acm.org>
Message-ID: <bbaeab100802201220h7951a7e4p4bf44e4da67f1805@mail.gmail.com>

On Feb 20, 2008 9:40 AM, Fred Drake <fdrake at acm.org> wrote:
> On Feb 20, 2008, at 5:59 AM, M.-A. Lemburg wrote:
> > -1. SGML is a much more general markup language than HTML.
>
> Certainly.  sgmllib doesn't handle the general case, and is unlikely
> to be reasonably extensible to support a substantial subset of SGML.
>

This is why I suggested moving it. Since the docs for sgmllib
explicitly state it does not provide full support for SGML as-is I
figured it should just get shifted. Heck, it might be a prime
candidate for API removal since it is not a complete implementation.

> > It's true that only htmllib does use sgmllib in the std lib,
> > but there are applications out there that rely on sgmllib
> > for the SGML part, e.g. ones implementing the DocBook tool
> > chain.
>
> I'd strongly encourage anyone who wants to use Python for general SGML
> parsing to either fork sgmllib (with a new name) and give it a real
> go, or integrate an existing SGML parser.  Pretending that sgmllib is
> really a usable SGML parser doesn't seem like a good idea.  It's also
> not widely enough used that it makes sense to have such a beast in the
> standard library.

I am definitely adding sgmllib to the list of possible module to
remove, but that is a separate email for another day. =)

-Brett

From brett at python.org  Wed Feb 20 21:25:29 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:25:29 -0800
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
In-Reply-To: <47BC59AC.1010508@egenix.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
	<47BC53E1.60104@cheimes.de> <47BC59AC.1010508@egenix.com>
Message-ID: <bbaeab100802201225t385b366fj7891d8650b8b4984@mail.gmail.com>

On Feb 20, 2008 8:47 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>
> Christian Heimes wrote:
> > Facundo Batista wrote:
> >> What to do with the methods that will be lost because of keeping a
> >> slightly different one with the same functionality? We could keep them
> >> with a deprecation warning, or simply let them disappear (+0 for the
> >> former, even considering we're in 3k).
> >
> > Merging urllib and urllib2 into a completely new module with a (although
> > slightly) different API is a good thing. But it also increases the
> > burden and workload for Python users. We should keep the original
> > modules around if a change can't be handled by a 2to3 fixer. We can
> > always deprecate a module for 3.1.
> >
> > For urllib/urllib2 I propose:
> >
> > * merge the functionality into a new, improved module
> > * keep the original ones around for 3.0 and schedule them for removal in
> > 3.1.
>
> I'm not sure that would work: urllib is one of the most used modules
> in Python when it comes to doing even only slightly web-related
> work.
>

That is I figured no one would be willing to see urllib or urllib2 go.

> I've never used urllib2 and am not sure what the reason was for
> adding it. It doesn't appear to offer more or better things than
> urllib... to late to argue, I guess ;-)
>

I actually use urllib2 over urllib because I find it easier to
overload with custom HTTP headers.

> In any case, deprecating a module after the jump to 3.0 is more
> problematic than during the major version number change.
>

I agree, but it is certainly doable.

> How about using the following mapping:
>
> urllib  -> url.fetch
> urllib2 -> url.request
>

I can live with that. What do other people think?

-Brett

From brett at python.org  Wed Feb 20 21:30:11 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:30:11 -0800
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
	<bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>
Message-ID: <bbaeab100802201230m77329ea3rdd91177be14fcb82@mail.gmail.com>

On Feb 20, 2008 12:18 PM, Brett Cannon <brett at python.org> wrote:
> On Feb 20, 2008 9:24 AM, Fred Drake <fdrake at acm.org> wrote:
> > On Feb 20, 2008, at 4:49 AM, Brett Cannon wrote:
> > > htmlentitydefs -> html.entities
> > > htmllib -> html.tools
> > > HTMLParser -> html.parser
> >
> > Drop htmllib (html.tools) completely, and you're good to go.
> >
>
> I have not finished reading my email, but I hope the web-sig likes
> that idea since that is what I would like to see happen as well.

So I read my mail and both Fred and Guido supported the idea on the
web-sig which works for me. =)

So the currently winning idea is:

HTMLParser -> html.parser
htmlentitydefs -> html.entities
htmllib -> *removed*
sgmllib -> *removed*

-Brett

From mal at egenix.com  Wed Feb 20 21:33:53 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 21:33:53 +0100
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>	<47BC0082.1030006@egenix.com>
	<47BC27CB.6020704@ronadam.com>
	<bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>
Message-ID: <47BC8EB1.6070701@egenix.com>

On 2008-02-20 21:16, Brett Cannon wrote:
> On Feb 20, 2008 5:14 AM, Ron Adam <rrr at ronadam.com> wrote:
>>
>> M.-A. Lemburg wrote:
>>> On 2008-02-20 11:05, Brett Cannon wrote:
>>>> 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.
>>> Hey, it's Py3k...
>> + 1

My reply was meant to say: it's P3k, so we're allowed to make changes
even if a module name is in wide-spread use. Besides, we're not
breaking the code itself.

> Is that for the removal or the package name of tk? Question applies to
> MAL as well as I forgot to ask that of him when he made the Py3K
> comment.
> 
>>>> So here is my current thinking:
>>>>
>>>> Tkinter -> tkinter.__init__
>> Possibly
>>
>>     Tkinter -> tk.tkinter
>>
>> and have tk.__init__ import it with "from tk.tkinter import *"?
> 
> I would rather do tk.inter than that amount of repetition in the
> package/module name.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From mal at egenix.com  Wed Feb 20 21:35:58 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 21:35:58 +0100
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802201220h7951a7e4p4bf44e4da67f1805@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>	<47BBF9EE.9030905@cheimes.de>	<bbaeab100802200215x1bdea36ay4dc89819c394e55f@mail.gmail.com>	<47BC081F.1040005@egenix.com>	<40403B86-6E9F-43C8-8C53-BDB415CBA9BA@acm.org>
	<bbaeab100802201220h7951a7e4p4bf44e4da67f1805@mail.gmail.com>
Message-ID: <47BC8F2E.7050704@egenix.com>

On 2008-02-20 21:20, Brett Cannon wrote:
> On Feb 20, 2008 9:40 AM, Fred Drake <fdrake at acm.org> wrote:
>> On Feb 20, 2008, at 5:59 AM, M.-A. Lemburg wrote:
>>> -1. SGML is a much more general markup language than HTML.
>> Certainly.  sgmllib doesn't handle the general case, and is unlikely
>> to be reasonably extensible to support a substantial subset of SGML.
>>
> 
> This is why I suggested moving it. Since the docs for sgmllib
> explicitly state it does not provide full support for SGML as-is I
> figured it should just get shifted. Heck, it might be a prime
> candidate for API removal since it is not a complete implementation.

Ok, remove my -1 :-)

>>> It's true that only htmllib does use sgmllib in the std lib,
>>> but there are applications out there that rely on sgmllib
>>> for the SGML part, e.g. ones implementing the DocBook tool
>>> chain.
>> I'd strongly encourage anyone who wants to use Python for general SGML
>> parsing to either fork sgmllib (with a new name) and give it a real
>> go, or integrate an existing SGML parser.  Pretending that sgmllib is
>> really a usable SGML parser doesn't seem like a good idea.  It's also
>> not widely enough used that it makes sense to have such a beast in the
>> standard library.
> 
> I am definitely adding sgmllib to the list of possible module to
> remove, but that is a separate email for another day. =)

Are there any wrappers for OpenJade and OpenSP out there ?

http://openjade.sourceforge.net/

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From fdrake at acm.org  Wed Feb 20 21:42:36 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 15:42:36 -0500
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802201230m77329ea3rdd91177be14fcb82@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
	<bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>
	<bbaeab100802201230m77329ea3rdd91177be14fcb82@mail.gmail.com>
Message-ID: <0D838479-1E68-4612-B556-ED825DF866A4@acm.org>

On Feb 20, 2008, at 3:30 PM, Brett Cannon wrote:
> So the currently winning idea is:

Another semi-related module is "formatter".  While the interfaces are  
general, I'd be curious to find out if that's being used for anything  
other than formatting HTML.  htmllib and pydoc appear to be the main  
users of this module in the standard library.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From brett at python.org  Wed Feb 20 21:52:21 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 12:52:21 -0800
Subject: [stdlib-sig] html package idea
In-Reply-To: <0D838479-1E68-4612-B556-ED825DF866A4@acm.org>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
	<bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>
	<bbaeab100802201230m77329ea3rdd91177be14fcb82@mail.gmail.com>
	<0D838479-1E68-4612-B556-ED825DF866A4@acm.org>
Message-ID: <bbaeab100802201252i72ac7f49m97f05b273c4b8373@mail.gmail.com>

On Feb 20, 2008 12:42 PM, Fred Drake <fdrake at acm.org> wrote:
> On Feb 20, 2008, at 3:30 PM, Brett Cannon wrote:
> > So the currently winning idea is:
>
> Another semi-related module is "formatter".  While the interfaces are
> general, I'd be curious to find out if that's being used for anything
> other than formatting HTML.  htmllib and pydoc appear to be the main
> users of this module in the standard library.

Google Code Search turned up two places that seem to be using it in a
non-HTML way:

http://www.google.com/codesearch?hl=en&q=+lang:python+%22import+formatter%22+show:8GkSOvDsbvA:ZD7wF8p7IcE:W6eAjEYIQ_M&sa=N&cd=18&ct=rc&cs_p=http://osx.freshmeat.net/redir/ftpcube/20073/url_tgz/ftpcube-0.5.1.tar.gz&cs_f=ftpcube-0.5.1/libftpcube/txtwrapper.py#first
http://www.google.com/codesearch?hl=en&q=+lang:python+%22from+formatter%22+show:xMrpNMMr5lM:bdNE19lGChs:6z9ZtePjddc&sa=N&cd=10&ct=rc&cs_p=http://freshmeat.net/redir/issuedealer/38032/url_tgz/IssueDealer-0.9.120.tar.gz&cs_f=IssueDealer/rest.py#first

-Brett

From fdrake at acm.org  Wed Feb 20 22:16:43 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 16:16:43 -0500
Subject: [stdlib-sig] html package idea
In-Reply-To: <bbaeab100802201252i72ac7f49m97f05b273c4b8373@mail.gmail.com>
References: <bbaeab100802200149j51153b82m9e00ba0ab218edf1@mail.gmail.com>
	<8F37D972-CC4A-4EB3-9E8A-45091427E381@acm.org>
	<bbaeab100802201218r5c25ab6dw8270d16e254b4b3a@mail.gmail.com>
	<bbaeab100802201230m77329ea3rdd91177be14fcb82@mail.gmail.com>
	<0D838479-1E68-4612-B556-ED825DF866A4@acm.org>
	<bbaeab100802201252i72ac7f49m97f05b273c4b8373@mail.gmail.com>
Message-ID: <DACC213B-1260-4961-B1F2-07C5BEC10D35@acm.org>

On Feb 20, 2008, at 3:52 PM, Brett Cannon wrote:
> Google Code Search turned up two places that seem to be using it in a
> non-HTML way:


Well!  I guess it shouldn't be considered a candidate for a html  
package, then.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From rrr at ronadam.com  Wed Feb 20 22:42:23 2008
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 20 Feb 2008 15:42:23 -0600
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>	
	<47BC0082.1030006@egenix.com> <47BC27CB.6020704@ronadam.com>
	<bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>
Message-ID: <47BC9EBF.3040109@ronadam.com>



Brett Cannon wrote:
 > On Feb 20, 2008 5:14 AM, Ron Adam <rrr at ronadam.com> wrote:
 >>
 >> M.-A. Lemburg wrote:
 >>> On 2008-02-20 11:05, Brett Cannon wrote:
 >>>> 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.
 >>> Hey, it's Py3k...
 >> + 1
 >>
 >
 > Is that for the removal or the package name of tk? Question applies to
 > MAL as well as I forgot to ask that of him when he made the Py3K
 > comment.

+1 on a tk package vs tkinter package.  It's much shorter and most of the 
modules are still spelled nearly the same.

    TkMessageBox -> tk.messagebox
    TkFileDialog -> tk.filedialog


 >>>> So here is my current thinking:
 >>>>
 >>>> Tkinter -> tkinter.__init__
 >> Possibly
 >>
 >>     Tkinter -> tk.tkinter
 >>
 >> and have tk.__init__ import it with "from tk.tkinter import *"?
 >
 > I would rather do tk.inter than that amount of repetition in the
 > package/module name.

    Maybe it should be tk.interface?

Ron

From brett at python.org  Wed Feb 20 22:46:12 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Feb 2008 13:46:12 -0800
Subject: [stdlib-sig] tkinter package idea
In-Reply-To: <47BC9EBF.3040109@ronadam.com>
References: <bbaeab100802200205r74e6f6daj9711da7a6ab755d5@mail.gmail.com>
	<47BC0082.1030006@egenix.com> <47BC27CB.6020704@ronadam.com>
	<bbaeab100802201216s11723ab0pad1e972953980a3b@mail.gmail.com>
	<47BC9EBF.3040109@ronadam.com>
Message-ID: <bbaeab100802201346j57f8471djbbded71a6799ea2d@mail.gmail.com>

On Wed, Feb 20, 2008 at 1:42 PM, Ron Adam <rrr at ronadam.com> wrote:
>
>
>  Brett Cannon wrote:
>   > On Feb 20, 2008 5:14 AM, Ron Adam <rrr at ronadam.com> wrote:
>   >>
>   >> M.-A. Lemburg wrote:
>   >>> On 2008-02-20 11:05, Brett Cannon wrote:
>   >>>> 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.
>   >>> Hey, it's Py3k...
>   >> + 1
>   >>
>   >
>   > Is that for the removal or the package name of tk? Question applies to
>   > MAL as well as I forgot to ask that of him when he made the Py3K
>   > comment.
>
>  +1 on a tk package vs tkinter package.  It's much shorter and most of the
>  modules are still spelled nearly the same.
>
>     TkMessageBox -> tk.messagebox
>     TkFileDialog -> tk.filedialog
>
>
>
>   >>>> So here is my current thinking:
>   >>>>
>   >>>> Tkinter -> tkinter.__init__
>   >> Possibly
>   >>
>   >>     Tkinter -> tk.tkinter
>   >>
>   >> and have tk.__init__ import it with "from tk.tkinter import *"?
>   >
>   > I would rather do tk.inter than that amount of repetition in the
>   > package/module name.
>
>     Maybe it should be tk.interface?

Yeah, but tk.inter has the perk of being so close to Tkinter that all
of the name references out there will still (roughly) work. I would
really like to prevent from killing Tkinter's name recognition if
possible.

-Brett

From qgallet at gmail.com  Wed Feb 20 23:11:40 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Wed, 20 Feb 2008 23:11:40 +0100
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
In-Reply-To: <bbaeab100802201225t385b366fj7891d8650b8b4984@mail.gmail.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
	<47BC53E1.60104@cheimes.de> <47BC59AC.1010508@egenix.com>
	<bbaeab100802201225t385b366fj7891d8650b8b4984@mail.gmail.com>
Message-ID: <8b943f2b0802201411n17985867j9fa23bc344719fce@mail.gmail.com>

On Wed, Feb 20, 2008 at 9:25 PM, Brett Cannon <brett at python.org> wrote:

> On Feb 20, 2008 8:47 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>
> > How about using the following mapping:
> >
> > urllib  -> url.fetch
> > urllib2 -> url.request
> >
>
> I can live with that. What do other people think?
>


I'm fine with it, if both packages are kept.
But since it looks like urllib is considered inferior to urllib2, shouldn't
it be possible to improve the latter (integrating whatever can be salvaged
from urllib) and removing the former, in the spirit of Christian's
suggestion ?

Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080220/c93fc1db/attachment.htm 

From fdrake at acm.org  Wed Feb 20 23:23:44 2008
From: fdrake at acm.org (Fred Drake)
Date: Wed, 20 Feb 2008 17:23:44 -0500
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
	and urlparse?
In-Reply-To: <8b943f2b0802201411n17985867j9fa23bc344719fce@mail.gmail.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>
	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>
	<47BC53E1.60104@cheimes.de> <47BC59AC.1010508@egenix.com>
	<bbaeab100802201225t385b366fj7891d8650b8b4984@mail.gmail.com>
	<8b943f2b0802201411n17985867j9fa23bc344719fce@mail.gmail.com>
Message-ID: <0F10501E-187C-47A3-AE53-D6C3383E1291@acm.org>

On Feb 20, 2008, at 5:11 PM, Quentin Gallet-Gilles wrote:
> I'm fine with it, if both packages are kept.
> But since it looks like urllib is considered inferior to urllib2,  
> shouldn't it be possible to improve the latter (integrating whatever  
> can be salvaged from urllib) and removing the former, in the spirit  
> of Christian's suggestion ?


I'd go so far as to say that any use case for urllib that can't be  
supported by urllib2 suggests a bug in urllib2.  :-)  I don't think  
I've encountered a situation that I couldn't solve easily with urllib2  
where I'd have used urllib in the past (pre-urllib2 days).


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From mal at egenix.com  Wed Feb 20 23:40:55 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Feb 2008 23:40:55 +0100
Subject: [stdlib-sig] Any ideas on how to handle urllib, urllib2,
 and urlparse?
In-Reply-To: <8b943f2b0802201411n17985867j9fa23bc344719fce@mail.gmail.com>
References: <bbaeab100802200239n2f200914vdcad593608b207ef@mail.gmail.com>	<e04bdf310802200745m899c666ma54072439f0ae513@mail.gmail.com>	<47BC53E1.60104@cheimes.de>
	<47BC59AC.1010508@egenix.com>	<bbaeab100802201225t385b366fj7891d8650b8b4984@mail.gmail.com>
	<8b943f2b0802201411n17985867j9fa23bc344719fce@mail.gmail.com>
Message-ID: <47BCAC77.2090404@egenix.com>

Quentin Gallet-Gilles wrote:
> On Wed, Feb 20, 2008 at 9:25 PM, Brett Cannon <brett at python.org> wrote:
> 
>> On Feb 20, 2008 8:47 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>>> How about using the following mapping:
>>>
>>> urllib  -> url.fetch
>>> urllib2 -> url.request
>>>
>> I can live with that. What do other people think?
>>
> 
> 
> I'm fine with it, if both packages are kept.
> But since it looks like urllib is considered inferior to urllib2, shouldn't
> it be possible to improve the latter (integrating whatever can be salvaged
> from urllib) and removing the former, in the spirit of Christian's
> suggestion ?

I wouldn't say it's inferior... it just uses a different approach
(plug in handlers rather than overriding methods).

BTW: Google Code Search gives 10000 hits for "import urllib2" and
38100 for "import urllib".

I bet most just use urllib[2]?.urlopen() anyway, without going into
any of the details.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 20 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611

From brett at python.org  Sun Feb 24 05:34:56 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 23 Feb 2008 20:34:56 -0800
Subject: [stdlib-sig] PEP 3108 updated with html package
Message-ID: <bbaeab100802232034h11ae104fjc429a4ebe4384362@mail.gmail.com>

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

From brett at python.org  Sun Feb 24 07:12:18 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 23 Feb 2008 22:12:18 -0800
Subject: [stdlib-sig] tk package added to PEP 3108
Message-ID: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>

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

From fdrake at acm.org  Sun Feb 24 09:37:49 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 24 Feb 2008 03:37:49 -0500
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
Message-ID: <73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>

On Feb 24, 2008, at 1:12 AM, Brett Cannon wrote:
> 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.


The specific re-naming proposals sound reasonable to me, though it's  
been a long time since I've used Tkinter.

The open issue you added to the PEP, regarding removing Tkinter (by  
whatever name) from the core, allowing it to be independently  
maintained, makes a lot of sense.  Tk isn't used so much on Unix/Linux  
as it once was, and has never received a great welcome on Windows.   
The rationale for removing it, allowing it to more closely follow Tk,  
makes a lot of sense to me as well.

And that would make the standard library smaller, and easier to  
maintain.  Always a good thing.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From brett at python.org  Sun Feb 24 10:11:24 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 24 Feb 2008 01:11:24 -0800
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
Message-ID: <bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>

On Sun, Feb 24, 2008 at 12:37 AM, Fred Drake <fdrake at acm.org> wrote:
>
> On Feb 24, 2008, at 1:12 AM, Brett Cannon wrote:
>  > 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.
>
>
>  The specific re-naming proposals sound reasonable to me, though it's
>  been a long time since I've used Tkinter.
>
>  The open issue you added to the PEP, regarding removing Tkinter (by
>  whatever name) from the core, allowing it to be independently
>  maintained, makes a lot of sense.  Tk isn't used so much on Unix/Linux
>  as it once was, and has never received a great welcome on Windows.
>  The rationale for removing it, allowing it to more closely follow Tk,
>  makes a lot of sense to me as well.
>
>  And that would make the standard library smaller, and easier to
>  maintain.  Always a good thing.

That all sounds reasonable (and the reason I think it is a good idea),
but convincing python-dev in general might be tough. Especially since
that would cause IDLE to not be part of the stdlib.

-Brett

From fdrake at acm.org  Sun Feb 24 18:57:54 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 24 Feb 2008 12:57:54 -0500
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
Message-ID: <7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>

On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
> That all sounds reasonable (and the reason I think it is a good idea),
> but convincing python-dev in general might be tough. Especially since
> that would cause IDLE to not be part of the stdlib.


I've no hope of convincing python-dev myself; the response to my  
suggestion about moving email out was... disappointing.  I just don't  
have the time needed to champion any large changes these days, and a  
"Lean Python" is a hard sell.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From brett at python.org  Sun Feb 24 20:42:52 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 24 Feb 2008 11:42:52 -0800
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
	<7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>
Message-ID: <bbaeab100802241142o51b160b1h7b085dd3a4053c9@mail.gmail.com>

On Sun, Feb 24, 2008 at 9:57 AM, Fred Drake <fdrake at acm.org> wrote:
> On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
>  > That all sounds reasonable (and the reason I think it is a good idea),
>  > but convincing python-dev in general might be tough. Especially since
>  > that would cause IDLE to not be part of the stdlib.
>
>
>  I've no hope of convincing python-dev myself; the response to my
>  suggestion about moving email out was... disappointing.  I just don't
>  have the time needed to champion any large changes these days, and a
>  "Lean Python" is a hard sell.

It is definitely a hard sell. There is a reason this is the third time
I am trying to reorganize everything. =) I think the "batteries
included" philosophy is too heavily ingrained in the community to ever
let us take large strides towards being more like Perl. Getting rid of
anything is going to require that it be obsolete or so externally tied
to something that it is just more practical to move it out. Otherwise
the chances of taking something out (e.g., email) is going to be damn
near impossible.

-Brett

From mal at egenix.com  Sun Feb 24 22:58:23 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 24 Feb 2008 22:58:23 +0100
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <bbaeab100802241142o51b160b1h7b085dd3a4053c9@mail.gmail.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>	<7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>
	<bbaeab100802241142o51b160b1h7b085dd3a4053c9@mail.gmail.com>
Message-ID: <47C1E87F.2040408@egenix.com>

On 2008-02-24 20:42, Brett Cannon wrote:
> On Sun, Feb 24, 2008 at 9:57 AM, Fred Drake <fdrake at acm.org> wrote:
>> On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
>>  > That all sounds reasonable (and the reason I think it is a good idea),
>>  > but convincing python-dev in general might be tough. Especially since
>>  > that would cause IDLE to not be part of the stdlib.
>>
>>
>>  I've no hope of convincing python-dev myself; the response to my
>>  suggestion about moving email out was... disappointing.  I just don't
>>  have the time needed to champion any large changes these days, and a
>>  "Lean Python" is a hard sell.
> 
> It is definitely a hard sell. There is a reason this is the third time
> I am trying to reorganize everything. =) I think the "batteries
> included" philosophy is too heavily ingrained in the community to ever
> let us take large strides towards being more like Perl. Getting rid of
> anything is going to require that it be obsolete or so externally tied
> to something that it is just more practical to move it out. Otherwise
> the chances of taking something out (e.g., email) is going to be damn
> near impossible.

I think that essential things like the email package should
be part of the standard library.

Non-essential things like e.g. the tk package or the audio/image/etc.
libs can well be separated out into stand-alone packages.

They may still be supported and maintained by the PSF, but
getting them would require an extra install step.

I actually think that this would benefit the stand-alone packages:
mostly because they would no longer be tied to the Python release
cycle, rather strict development scheme and strong focus on
certain aspects of Python's application space.

In any case, I agree that putting energy into such an effort is
better spent elsewhere.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 24 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From fdrake at acm.org  Sun Feb 24 23:39:46 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 24 Feb 2008 17:39:46 -0500
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <47C1E87F.2040408@egenix.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>	<7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>
	<bbaeab100802241142o51b160b1h7b085dd3a4053c9@mail.gmail.com>
	<47C1E87F.2040408@egenix.com>
Message-ID: <BCEA6281-7DAE-4D2F-A6DA-C82A3F6F2868@acm.org>

On Feb 24, 2008, at 4:58 PM, M.-A. Lemburg wrote:
> I think that essential things like the email package should
> be part of the standard library.
>
> Non-essential things like e.g. the tk package or the audio/image/etc.
> libs can well be separated out into stand-alone packages.

What's essential is a judgement call.  You & I would draw the line in  
different places.

Things that are tightly coupled with the Python runtime do seem to  
belong in the standard library.  A feature that I hear requests for  
frequently that would be tightly coupled would be deferred imports.

> They may still be supported and maintained by the PSF, but
> getting them would require an extra install step.

I think supported & maintained by the PSF is fine; I'm not in favor of  
throwing out useful packages.

> In any case, I agree that putting energy into such an effort is
> better spent elsewhere.


Interestingly, I didn't see either myself or Brett say anything like  
this.  I only said I don't have the time to champion such an idea, not  
that I had anything else to do (there's work, there's family, and  
then... I'm wiped out).


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From mal at egenix.com  Mon Feb 25 12:21:33 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 25 Feb 2008 12:21:33 +0100
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <BCEA6281-7DAE-4D2F-A6DA-C82A3F6F2868@acm.org>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>	<7D7C0BB3-FEF3-492C-8278-52B63BB735F7@acm.org>	<bbaeab100802241142o51b160b1h7b085dd3a4053c9@mail.gmail.com>	<47C1E87F.2040408@egenix.com>
	<BCEA6281-7DAE-4D2F-A6DA-C82A3F6F2868@acm.org>
Message-ID: <47C2A4BD.9090704@egenix.com>

On 2008-02-24 23:39, Fred Drake wrote:
> On Feb 24, 2008, at 4:58 PM, M.-A. Lemburg wrote:
>> I think that essential things like the email package should
>> be part of the standard library.
>>
>> Non-essential things like e.g. the tk package or the audio/image/etc.
>> libs can well be separated out into stand-alone packages.
> 
> What's essential is a judgement call.  You & I would draw the line in
> different places.

Right, and that's what causes endless discussions.

> Things that are tightly coupled with the Python runtime do seem to
> belong in the standard library.  A feature that I hear requests for
> frequently that would be tightly coupled would be deferred imports.

Then we have a different idea of scope of the std lib. We'd
have to remove the tk package, the html package, the dbm
package, etc. if we were to follow your idea of what the
std lib should be and only very few modules would be left
in such a std lib.

Other languages split such modules into a "core" or "lang"
package. Perhaps that's what you're after ?

>> They may still be supported and maintained by the PSF, but
>> getting them would require an extra install step.
> 
> I think supported & maintained by the PSF is fine; I'm not in favor of
> throwing out useful packages.
> 
>> In any case, I agree that putting energy into such an effort is
>> better spent elsewhere.
> 
> 
> Interestingly, I didn't see either myself or Brett say anything like
> this.  I only said I don't have the time to champion such an idea, not
> that I had anything else to do (there's work, there's family, and
> then... I'm wiped out).

That's essentially what I meant.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 25 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

From p.f.moore at gmail.com  Mon Feb 25 13:47:06 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 25 Feb 2008 12:47:06 +0000
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
Message-ID: <79990c6b0802250447l861c6d2t98ec6b96cdf03f2a@mail.gmail.com>

On 24/02/2008, Brett Cannon <brett at python.org> wrote:
>  >  And that would make the standard library smaller, and easier to
>  >  maintain.  Always a good thing.
>
> That all sounds reasonable (and the reason I think it is a good idea),
>  but convincing python-dev in general might be tough. Especially since
>  that would cause IDLE to not be part of the stdlib.

I've no real opinion myself, but I believe one of the sticking points
is that without tk, there's no way in core Python of putting up a
simple GUI. The pydoc server installed with Windows Python ("Module
Docs" on the start menu) and the Twisted installer use this, I
believe.

Paul.

From solipsis at pitrou.net  Mon Feb 25 14:23:52 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 25 Feb 2008 14:23:52 +0100
Subject: [stdlib-sig] tk package added to PEP 3108
In-Reply-To: <79990c6b0802250447l861c6d2t98ec6b96cdf03f2a@mail.gmail.com>
References: <bbaeab100802232212y74cc41f3oa86d909efb605ada@mail.gmail.com>
	<73EA10D5-4578-43A4-9D31-74C50B6E01AB@acm.org>
	<bbaeab100802240111s32ecae3dsfbd31e657c7e1b5d@mail.gmail.com>
	<79990c6b0802250447l861c6d2t98ec6b96cdf03f2a@mail.gmail.com>
Message-ID: <1203945832.7623.8.camel@fsol>


Le lundi 25 f?vrier 2008 ? 12:47 +0000, Paul Moore a ?crit :
> I've no real opinion myself, but I believe one of the sticking points
> is that without tk, there's no way in core Python of putting up a
> simple GUI. The pydoc server installed with Windows Python ("Module
> Docs" on the start menu) and the Twisted installer use this, I
> believe.

Hmm, each time I've installed Twisted, it was just "python setup.py
install".




From brett at python.org  Fri Feb 29 01:47:22 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 28 Feb 2008 16:47:22 -0800
Subject: [stdlib-sig] Choosing one of two options for url* in the stdlib
	reorg
Message-ID: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>

[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

From brett at python.org  Fri Feb 29 02:33:45 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 28 Feb 2008 17:33:45 -0800
Subject: [stdlib-sig] Any more packaging suggestions? March 15th deadline
	for ideas!
Message-ID: <bbaeab100802281733w2423a880ud163a0d40ee34bb7@mail.gmail.com>

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

From python at rcn.com  Fri Feb 29 03:00:59 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 28 Feb 2008 21:00:59 -0500 (EST)
Subject: [stdlib-sig] Any more packaging suggestions? March 15th
 deadline	for ideas!
Message-ID: <20080228210059.AHU19713@ms19.lnh.mail.rcn.net>

[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

From brett at python.org  Fri Feb 29 03:16:48 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 28 Feb 2008 18:16:48 -0800
Subject: [stdlib-sig] Any more packaging suggestions? March 15th
	deadline for ideas!
In-Reply-To: <20080228210059.AHU19713@ms19.lnh.mail.rcn.net>
References: <20080228210059.AHU19713@ms19.lnh.mail.rcn.net>
Message-ID: <bbaeab100802281816v33197a47v5fdd36fddd07e30@mail.gmail.com>

On Thu, Feb 28, 2008 at 6:00 PM, Raymond Hettinger <python at 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

From steven.bethard at gmail.com  Fri Feb 29 04:23:09 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 28 Feb 2008 20:23:09 -0700
Subject: [stdlib-sig] Choosing one of two options for url* in the stdlib
	reorg
In-Reply-To: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>
References: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>
Message-ID: <d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>

On Thu, Feb 28, 2008 at 5:47 PM, Brett Cannon <brett at python.org> wrote:
>  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

+1 for the second option.  I'd also be happy if there were fewer than
3 modules in the package, but mainly I'd like to see urllib gone with
urllib2 in its place.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From fdrake at acm.org  Fri Feb 29 04:30:11 2008
From: fdrake at acm.org (Fred Drake)
Date: Thu, 28 Feb 2008 22:30:11 -0500
Subject: [stdlib-sig] Choosing one of two options for url* in the stdlib
	reorg
In-Reply-To: <d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>
References: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>
	<d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>
Message-ID: <23D363D0-B948-4AC8-933B-D413D7C48A4F@acm.org>

On Feb 28, 2008, at 10:23 PM, Steven Bethard wrote:
>>  urlparse -> url.parse
>>  urllib -> GONE
>>  urllib's utility functions -> url.quote
>>  urllib2 -> url.request
>
> +1 for the second option.  I'd also be happy if there were fewer than
> 3 modules in the package, but mainly I'd like to see urllib gone with
> urllib2 in its place.

Agreed.

As far asl urllib's useful utility functions, they're all about  
quoting and unquoting, which is related to parsing.  I'd be happy to  
see them in url.parse; the current urlparse contains both parsing and  
re-assembly functions, and I think it reasonable for the quote- 
handling functions to co-habit with those.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From qgallet at gmail.com  Fri Feb 29 09:35:34 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Fri, 29 Feb 2008 09:35:34 +0100
Subject: [stdlib-sig] Choosing one of two options for url* in the stdlib
	reorg
In-Reply-To: <d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>
References: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>
	<d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>
Message-ID: <8b943f2b0802290035i5ace3ffdjd609288b729e4494@mail.gmail.com>

On Fri, Feb 29, 2008 at 4:23 AM, Steven Bethard <steven.bethard at gmail.com>
wrote:

> On Thu, Feb 28, 2008 at 5:47 PM, Brett Cannon <brett at python.org> wrote:
> >  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
>
> +1 for the second option.  I'd also be happy if there were fewer than
> 3 modules in the package, but mainly I'd like to see urllib gone with
> urllib2 in its place.
>

Agreed, +1 for ditching urllib.

Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080229/7dacbe3d/attachment.htm 

From ronaldoussoren at mac.com  Fri Feb 29 09:42:23 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 29 Feb 2008 09:42:23 +0100
Subject: [stdlib-sig] Choosing one of two options for url* in the stdlib
	reorg
In-Reply-To: <8b943f2b0802290035i5ace3ffdjd609288b729e4494@mail.gmail.com>
References: <bbaeab100802281647x1442fa7p89ffd8404ed37d9e@mail.gmail.com>
	<d11dcfba0802281923h3f489ee2w15590f83fb5a0a73@mail.gmail.com>
	<8b943f2b0802290035i5ace3ffdjd609288b729e4494@mail.gmail.com>
Message-ID: <80660EE5-669A-4E2F-859B-7A472A68F5AC@mac.com>


On 29 Feb, 2008, at 9:35, Quentin Gallet-Gilles wrote:

>
>
> On Fri, Feb 29, 2008 at 4:23 AM, Steven Bethard <steven.bethard at gmail.com 
> > wrote:
> On Thu, Feb 28, 2008 at 5:47 PM, Brett Cannon <brett at python.org>  
> wrote:
> >  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
>
> +1 for the second option.  I'd also be happy if there were fewer than
> 3 modules in the package, but mainly I'd like to see urllib gone with
> urllib2 in its place.
>
> Agreed, +1 for ditching urllib.

The same here.  It would be odd to reorganize the stdlib and then keep  
two confusingly simular modules.

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080229/7edd0f0a/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/stdlib-sig/attachments/20080229/7edd0f0a/attachment-0001.bin