From mark at qtrac.eu  Mon Mar  3 11:46:06 2008
From: mark at qtrac.eu (Mark Summerfield)
Date: Mon, 3 Mar 2008 10:46:06 +0000
Subject: [stdlib-sig] poss. naming inconsistency: fractions
Message-ID: <200803031046.06508.mark@qtrac.eu>

Hi,

In Py30a3 the rational module seems to have been renamed 'fractions'.
This module provides an additional numeric data type
"fractions.Fraction".
But there is an existing module that provides a numeric data type:
"decimal.Decimal".
Wouldn't it be more consistent to have
"fraction.Fraction"
to match?

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From jyasskin at gmail.com  Mon Mar  3 15:41:26 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Mon, 3 Mar 2008 06:41:26 -0800
Subject: [stdlib-sig] poss. naming inconsistency: fractions
In-Reply-To: <200803031046.06508.mark@qtrac.eu>
References: <200803031046.06508.mark@qtrac.eu>
Message-ID: <5d44f72f0803030641q107dabe9n343403e08d0bf0b1@mail.gmail.com>

Guido suggested fractions in http://bugs.python.org/msg62254.

On Mon, Mar 3, 2008 at 2:46 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> Hi,
>
>  In Py30a3 the rational module seems to have been renamed 'fractions'.
>  This module provides an additional numeric data type
>  "fractions.Fraction".
>  But there is an existing module that provides a numeric data type:
>  "decimal.Decimal".
>  Wouldn't it be more consistent to have
>  "fraction.Fraction"
>  to match?
>
>  --
>  Mark Summerfield, Qtrac Ltd., www.qtrac.eu
>
>  _______________________________________________
>  stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

From brett at python.org  Mon Mar  3 20:34:48 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 3 Mar 2008 11:34:48 -0800
Subject: [stdlib-sig] poss. naming inconsistency: fractions
In-Reply-To: <5d44f72f0803030641q107dabe9n343403e08d0bf0b1@mail.gmail.com>
References: <200803031046.06508.mark@qtrac.eu>
	<5d44f72f0803030641q107dabe9n343403e08d0bf0b1@mail.gmail.com>
Message-ID: <bbaeab100803031134x4c6cca97x99e0fb40b8c5c12c@mail.gmail.com>

On Mon, Mar 3, 2008 at 6:41 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> Guido suggested fractions in http://bugs.python.org/msg62254.
>
>
>
>  On Mon, Mar 3, 2008 at 2:46 AM, Mark Summerfield <mark at qtrac.eu> wrote:
>  > Hi,
>  >
>  >  In Py30a3 the rational module seems to have been renamed 'fractions'.
>  >  This module provides an additional numeric data type
>  >  "fractions.Fraction".
>  >  But there is an existing module that provides a numeric data type:
>  >  "decimal.Decimal".
>  >  Wouldn't it be more consistent to have
>  >  "fraction.Fraction"
>  >  to match?

I agree with Guido. 'decimals' just sounds weird. But 'fractions' is fine.

-Brett

From brett at python.org  Wed Mar  5 07:49:28 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 4 Mar 2008 22:49:28 -0800
Subject: [stdlib-sig] The solution for urllib and the url package
Message-ID: <bbaeab100803042249r22295ef8y8934e1ae2ea00696@mail.gmail.com>

OK, here is the stuff that is not disputed:

 urllib2 -> url.request
 urlparse -> url.parse
 urllib quoting-related functions -> url.parse

The thing up for debate is the rest of urllib. I have decided MAL can
have what he wants and have URLOpener and FancyURLOpener put in
url.request if the documentation for both classes is completely
updated to expose the proper API for both classes for 2.6. May 1st is
the deadline to get this to happen.

If this does not occur then the non-quoting code gets made external
for people download and use if they want but is not kept in the
stdlib.

-Brett

From rrr at ronadam.com  Wed Mar  5 22:49:03 2008
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 05 Mar 2008 15:49:03 -0600
Subject: [stdlib-sig] pydoc enhancements
In-Reply-To: <bbaeab100802281733w2423a880ud163a0d40ee34bb7@mail.gmail.com>
References: <bbaeab100802281733w2423a880ud163a0d40ee34bb7@mail.gmail.com>
Message-ID: <47CF154F.9030504@ronadam.com>



A few weeks ago I created a patch for pydoc which removes it's dependency 
on tk by adding a navigation bar to the top of the pages served to the browser.


http://bugs.python.org/issue2001

The patch applies to python 2.6, but does not apply to 3.0 cleanly at this 
time. (Use the newest one, the older 2 patches can be deleted.)



To make these changes, the html server in pydoc was altered to be less 
independent on other parts of pydoc, ie.. more general use.  It's possible 
that this part could fit into http module.  This server serves generated 
strings instead of files.  Possibly SimpleHTTPServer should be 
SimpleHTTPFIleServer... or the py3k equivalent, http.server and 
http.fileserver?  The http file server could possibly subclass the http.server?




Back to the PyDoc enhancements...

The served html page headers has a compact navbar that includes the 
following elements.

     + The python version being used.

     + A get field that accepts most things you would type at the 
interactive prompt.  This allows you to "get" a specific items docs without 
  searching if you know the name.

     + A search field that returns the same list as the "modules 
search_term" at interactive help prompt.  (or list all modules if no 
search_term is given.)

     + An "index" link that returns the main module index page.

     + A "keywords" and "topics" link that returns the same list as typing 
keywords or topics in interactive help.  And those links work if the html 
docs are installed.

     + The "file" links on each pydoc page reads the *.py file in text mode 
and inserts the listing into an html page rather than relying on the 
browser to do the right thing with the file.  This is much much safer and 
personally I think this is a bug (poor design) that needs fixing.

     + Starting "python -g" opens up the browser directly to the module 
index page. From there you can either click on a module in the index or use 
the added navbar header to get more specific help.



All of these enhancements make moving around in the browser and looking at 
python module docs very nice and easy.  No more switching back and forth 
between a tk control window and the browser.  I think it would be nice to 
have this in python 2.6 and later.

Note: The navbar header is not added to the generated html files as they 
won't use the same interactive server.



Unfortunately, I will be starting a trip tomorrow and will be away from my 
computer for a week to two weeks.  But I wanted to get this in before the 
14th idea deadline.  I will try to work on it more and include any 
suggestions when I get back, or maybe someone else would like to finish it 
up.  I think python docs will need to be updated.  Also it needs to be 
checked to be sure it works correctly across platforms/browsers.  There is 
currently no tests for the pydoc module although there is a file to 
manually check pydoc output in the Lib/test directory that could possibly 
be used to create a test with.


Cheers,
    Ron














From brett at python.org  Wed Mar  5 22:53:02 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 5 Mar 2008 13:53:02 -0800
Subject: [stdlib-sig] pydoc enhancements
In-Reply-To: <47CF154F.9030504@ronadam.com>
References: <bbaeab100802281733w2423a880ud163a0d40ee34bb7@mail.gmail.com>
	<47CF154F.9030504@ronadam.com>
Message-ID: <bbaeab100803051353j3b8fd329nea20398d62b2e894@mail.gmail.com>

The deadline is for creating new packages, not adding to them. If a
new module comes in and belongs in one of the new packages, adding is
not a problem.

In other words you have nothing to worry about, Ron, unless you wanted
to turn pydoc into a package or something.

-Brett

On Wed, Mar 5, 2008 at 1:49 PM, Ron Adam <rrr at ronadam.com> wrote:
>
>
>  A few weeks ago I created a patch for pydoc which removes it's dependency
>  on tk by adding a navigation bar to the top of the pages served to the browser.
>
>
>  http://bugs.python.org/issue2001
>
>  The patch applies to python 2.6, but does not apply to 3.0 cleanly at this
>  time. (Use the newest one, the older 2 patches can be deleted.)
>
>
>
>  To make these changes, the html server in pydoc was altered to be less
>  independent on other parts of pydoc, ie.. more general use.  It's possible
>  that this part could fit into http module.  This server serves generated
>  strings instead of files.  Possibly SimpleHTTPServer should be
>  SimpleHTTPFIleServer... or the py3k equivalent, http.server and
>  http.fileserver?  The http file server could possibly subclass the http.server?
>
>
>
>
>  Back to the PyDoc enhancements...
>
>  The served html page headers has a compact navbar that includes the
>  following elements.
>
>      + The python version being used.
>
>      + A get field that accepts most things you would type at the
>  interactive prompt.  This allows you to "get" a specific items docs without
>   searching if you know the name.
>
>      + A search field that returns the same list as the "modules
>  search_term" at interactive help prompt.  (or list all modules if no
>  search_term is given.)
>
>      + An "index" link that returns the main module index page.
>
>      + A "keywords" and "topics" link that returns the same list as typing
>  keywords or topics in interactive help.  And those links work if the html
>  docs are installed.
>
>      + The "file" links on each pydoc page reads the *.py file in text mode
>  and inserts the listing into an html page rather than relying on the
>  browser to do the right thing with the file.  This is much much safer and
>  personally I think this is a bug (poor design) that needs fixing.
>
>      + Starting "python -g" opens up the browser directly to the module
>  index page. From there you can either click on a module in the index or use
>  the added navbar header to get more specific help.
>
>
>
>  All of these enhancements make moving around in the browser and looking at
>  python module docs very nice and easy.  No more switching back and forth
>  between a tk control window and the browser.  I think it would be nice to
>  have this in python 2.6 and later.
>
>  Note: The navbar header is not added to the generated html files as they
>  won't use the same interactive server.
>
>
>
>  Unfortunately, I will be starting a trip tomorrow and will be away from my
>  computer for a week to two weeks.  But I wanted to get this in before the
>  14th idea deadline.  I will try to work on it more and include any
>  suggestions when I get back, or maybe someone else would like to finish it
>  up.  I think python docs will need to be updated.  Also it needs to be
>  checked to be sure it works correctly across platforms/browsers.  There is
>  currently no tests for the pydoc module although there is a file to
>  manually check pydoc output in the Lib/test directory that could possibly
>  be used to create a test with.
>
>
>  Cheers,
>     Ron

From rrr at ronadam.com  Wed Mar  5 23:30:58 2008
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 05 Mar 2008 16:30:58 -0600
Subject: [stdlib-sig] pydoc enhancements
In-Reply-To: <bbaeab100803051353j3b8fd329nea20398d62b2e894@mail.gmail.com>
References: <bbaeab100802281733w2423a880ud163a0d40ee34bb7@mail.gmail.com>	
	<47CF154F.9030504@ronadam.com>
	<bbaeab100803051353j3b8fd329nea20398d62b2e894@mail.gmail.com>
Message-ID: <47CF1F22.4020503@ronadam.com>



Brett Cannon wrote:
> The deadline is for creating new packages, not adding to them. If a
> new module comes in and belongs in one of the new packages, adding is
> not a problem.
> 
> In other words you have nothing to worry about, Ron, unless you wanted
> to turn pydoc into a package or something.
> 
> -Brett

Good to know. Thanks.

Making it a package was discussed a while back with mixed results.

I think it doesn't need to be a package, but some of it's parts can be 
moved to other modules or packages.  For example the console pager section 
may be useful as part of the cmd package which is used to create 
interactive command interpreters.  And as mentioned, the server could be 
moved to the http package/module.  This patch should make those moves 
easier, so I think it's a good first step.

It's also makes it a handy tool to interactively browse the standard 
library in the process of reorganizing the standard library. ;-)

Ron



> On Wed, Mar 5, 2008 at 1:49 PM, Ron Adam <rrr at ronadam.com> wrote:
>>
>>  A few weeks ago I created a patch for pydoc which removes it's dependency
>>  on tk by adding a navigation bar to the top of the pages served to the browser.
>>
>>
>>  http://bugs.python.org/issue2001
>>
>>  The patch applies to python 2.6, but does not apply to 3.0 cleanly at this
>>  time. (Use the newest one, the older 2 patches can be deleted.)
>>
>>
>>
>>  To make these changes, the html server in pydoc was altered to be less
>>  independent on other parts of pydoc, ie.. more general use.  It's possible
>>  that this part could fit into http module.  This server serves generated
>>  strings instead of files.  Possibly SimpleHTTPServer should be
>>  SimpleHTTPFIleServer... or the py3k equivalent, http.server and
>>  http.fileserver?  The http file server could possibly subclass the http.server?
>>
>>
>>
>>
>>  Back to the PyDoc enhancements...
>>
>>  The served html page headers has a compact navbar that includes the
>>  following elements.
>>
>>      + The python version being used.
>>
>>      + A get field that accepts most things you would type at the
>>  interactive prompt.  This allows you to "get" a specific items docs without
>>   searching if you know the name.
>>
>>      + A search field that returns the same list as the "modules
>>  search_term" at interactive help prompt.  (or list all modules if no
>>  search_term is given.)
>>
>>      + An "index" link that returns the main module index page.
>>
>>      + A "keywords" and "topics" link that returns the same list as typing
>>  keywords or topics in interactive help.  And those links work if the html
>>  docs are installed.
>>
>>      + The "file" links on each pydoc page reads the *.py file in text mode
>>  and inserts the listing into an html page rather than relying on the
>>  browser to do the right thing with the file.  This is much much safer and
>>  personally I think this is a bug (poor design) that needs fixing.
>>
>>      + Starting "python -g" opens up the browser directly to the module
>>  index page. From there you can either click on a module in the index or use
>>  the added navbar header to get more specific help.
>>
>>
>>
>>  All of these enhancements make moving around in the browser and looking at
>>  python module docs very nice and easy.  No more switching back and forth
>>  between a tk control window and the browser.  I think it would be nice to
>>  have this in python 2.6 and later.
>>
>>  Note: The navbar header is not added to the generated html files as they
>>  won't use the same interactive server.
>>
>>
>>
>>  Unfortunately, I will be starting a trip tomorrow and will be away from my
>>  computer for a week to two weeks.  But I wanted to get this in before the
>>  14th idea deadline.  I will try to work on it more and include any
>>  suggestions when I get back, or maybe someone else would like to finish it
>>  up.  I think python docs will need to be updated.  Also it needs to be
>>  checked to be sure it works correctly across platforms/browsers.  There is
>>  currently no tests for the pydoc module although there is a file to
>>  manually check pydoc output in the Lib/test directory that could possibly
>>  be used to create a test with.
>>
>>
>>  Cheers,
>>     Ron
> 

From brett at python.org  Sun Mar  9 04:33:12 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 8 Mar 2008 19:33:12 -0800
Subject: [stdlib-sig] Dealt with Cookie and cookiejar
Message-ID: <bbaeab100803081933t50f7c50di7da27fc99d49db7d@mail.gmail.com>

Cookie -> http.cookies
cookielib -> http.cookiejar

-Brett

From brett at python.org  Sun Mar  9 23:13:38 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 15:13:38 -0700
Subject: [stdlib-sig] new package idea: zip
Message-ID: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>

We have to files related to zip files: zipfile and zipimport. Should
we bother to consolidate? The problem is the obvious names conflict
with built-in type  and a keyword, respectively. A possibility is:

zipfile -> zip.filer
zipimport -> zip.importer

But I don't know if that is really an improvement. What do other people think?

-Brett

From brett at python.org  Sun Mar  9 23:15:08 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 15:15:08 -0700
Subject: [stdlib-sig] new package idea: socket
Message-ID: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>

So this one kind of is screaming at me:

socket -> socket.__init__
SocketServer -> socket.server
ssl -> socket.ssl

I know Guido has expressed his dislike of putting much code in a
package's __init__, but since every module that would go in this
package is dependent on the socket module anyway, I see no harm.

What do people think?

-Brett

From santagada at gmail.com  Mon Mar 10 00:21:42 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Sun, 9 Mar 2008 20:21:42 -0300
Subject: [stdlib-sig] new package idea: zip
In-Reply-To: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
Message-ID: <3836D783-6A51-4855-B5D4-2F73F5477355@gmail.com>


On 09/03/2008, at 19:13, Brett Cannon wrote:

> We have to files related to zip files: zipfile and zipimport. Should
> we bother to consolidate? The problem is the obvious names conflict
> with built-in type  and a keyword, respectively. A possibility is:
>
> zipfile -> zip.filer
> zipimport -> zip.importer
>
> But I don't know if that is really an improvement. What do other  
> people think?


Although both modules somehow work with zip files they do completely  
different thing. Better would be to put zipimport with the import  
machinery and zipfile with tar or something.


--
Leonardo Santagada




From santagada at gmail.com  Mon Mar 10 00:25:03 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Sun, 9 Mar 2008 20:25:03 -0300
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
Message-ID: <C2941C52-540B-425D-B583-4A6D4308733F@gmail.com>


On 09/03/2008, at 19:15, Brett Cannon wrote:

> So this one kind of is screaming at me:
>
> socket -> socket.__init__
> SocketServer -> socket.server
> ssl -> socket.ssl
>
> I know Guido has expressed his dislike of putting much code in a
> package's __init__, but since every module that would go in this
> package is dependent on the socket module anyway, I see no harm.


I think this would be better:

socket -> socket.socket

and maybe in the __init__ it could call socket.socket and expose  
things to a client so he only needs to import socket.


--
Leonardo Santagada




From solipsis at pitrou.net  Mon Mar 10 00:46:48 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 10 Mar 2008 00:46:48 +0100
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
Message-ID: <1205106408.7780.17.camel@fsol>


Le dimanche 09 mars 2008 ? 15:15 -0700, Brett Cannon a ?crit :
> So this one kind of is screaming at me:
> 
> socket -> socket.__init__
> SocketServer -> socket.server
> ssl -> socket.ssl

If there are different kinds of sockets in it, perhaps the package
should be named "sockets" instead?




From solipsis at pitrou.net  Mon Mar 10 00:47:54 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 10 Mar 2008 00:47:54 +0100
Subject: [stdlib-sig] new package idea: zip
In-Reply-To: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
Message-ID: <1205106474.7780.20.camel@fsol>


Le dimanche 09 mars 2008 ? 15:13 -0700, Brett Cannon a ?crit :
> We have to files related to zip files: zipfile and zipimport. Should
> we bother to consolidate? The problem is the obvious names conflict
> with built-in type  and a keyword, respectively. A possibility is:
> 
> zipfile -> zip.filer
> zipimport -> zip.importer
> 
> But I don't know if that is really an improvement. What do other people think?

I don't see the point since the functionality is so different (and I
don't think zipimport in used in much application-level code). Also,
"filer" sounds horrible.




From fdrake at acm.org  Mon Mar 10 00:53:49 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 9 Mar 2008 19:53:49 -0400
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <C2941C52-540B-425D-B583-4A6D4308733F@gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<C2941C52-540B-425D-B583-4A6D4308733F@gmail.com>
Message-ID: <91E86885-D135-4D3F-A3F4-E1E9673E3470@acm.org>

On Mar 9, 2008, at 7:25 PM, Leonardo Santagada wrote:
> I think this would be better:
>
> socket -> socket.socket


With this modification, +1 on this proposal.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From fdrake at acm.org  Mon Mar 10 00:54:51 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 9 Mar 2008 19:54:51 -0400
Subject: [stdlib-sig] new package idea: zip
In-Reply-To: <3836D783-6A51-4855-B5D4-2F73F5477355@gmail.com>
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
	<3836D783-6A51-4855-B5D4-2F73F5477355@gmail.com>
Message-ID: <39F7B665-D9C9-4F27-9C5F-A11435A55F01@acm.org>

On Mar 9, 2008, at 7:21 PM, Leonardo Santagada wrote:
> Although both modules somehow work with zip files they do completely
> different thing. Better would be to put zipimport with the import
> machinery and zipfile with tar or something.


Agreed on this as well.  The modules have no substantial usage  
similarities.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From brett at python.org  Mon Mar 10 01:10:27 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 17:10:27 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <1205106408.7780.17.camel@fsol>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol>
Message-ID: <bbaeab100803091710y2ac36476kb871b03c54bda031@mail.gmail.com>

On Sun, Mar 9, 2008 at 4:46 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>  Le dimanche 09 mars 2008 ? 15:15 -0700, Brett Cannon a ?crit :
>
> > So this one kind of is screaming at me:
>  >
>  > socket -> socket.__init__
>  > SocketServer -> socket.server
>  > ssl -> socket.ssl
>
>  If there are different kinds of sockets in it, perhaps the package
>  should be named "sockets" instead?

Eh, I don't see a benefit in making it plural. And isn't it
traditionally called the socket library, even under C?

-Brett

From brett at python.org  Mon Mar 10 01:13:10 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 17:13:10 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <91E86885-D135-4D3F-A3F4-E1E9673E3470@acm.org>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<C2941C52-540B-425D-B583-4A6D4308733F@gmail.com>
	<91E86885-D135-4D3F-A3F4-E1E9673E3470@acm.org>
Message-ID: <bbaeab100803091713r7143cc9cn7d1fcb7843e57724@mail.gmail.com>

On Sun, Mar 9, 2008 at 4:53 PM, Fred Drake <fdrake at acm.org> wrote:
> On Mar 9, 2008, at 7:25 PM, Leonardo Santagada wrote:
>  > I think this would be better:
>  >
>  > socket -> socket.socket
>
>
>  With this modification, +1 on this proposal.

Problem with that is it goes against name simplification;
'socket.socket' is not as simple as 'socket'. So why do the two of you
think this is better than just importing 'socket'?

-Brett

From fdrake at acm.org  Mon Mar 10 01:19:03 2008
From: fdrake at acm.org (Fred Drake)
Date: Sun, 9 Mar 2008 20:19:03 -0400
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803091713r7143cc9cn7d1fcb7843e57724@mail.gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<C2941C52-540B-425D-B583-4A6D4308733F@gmail.com>
	<91E86885-D135-4D3F-A3F4-E1E9673E3470@acm.org>
	<bbaeab100803091713r7143cc9cn7d1fcb7843e57724@mail.gmail.com>
Message-ID: <1FC39474-F297-4A2F-AD42-FF3FE1558C11@acm.org>

On Mar 9, 2008, at 8:13 PM, Brett Cannon wrote:
> Problem with that is it goes against name simplification;
> 'socket.socket' is not as simple as 'socket'. So why do the two of you
> think this is better than just importing 'socket'?

With the proposal, you still just import socket, but the  
implementation for the names in socket is in socket.socket.

The motivation is more of a pattern that I've seen work well in  
practice:  __init__.py is pretty minimal, and the implementations are  
all in "normal" modules with package.module names.  The real advantage  
is that all real code is in a file with a descriptive name; __init__  
doesn't describe package contents, but package initialization.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From alexandre at peadrop.com  Mon Mar 10 01:50:48 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sun, 9 Mar 2008 20:50:48 -0400
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
Message-ID: <acd65fa20803091750g3c6b2ea9jb45219fd59bcc2dd@mail.gmail.com>

On Sun, Mar 9, 2008 at 6:15 PM, Brett Cannon <brett at python.org> wrote:
> So this one kind of is screaming at me:
>
>  socket -> socket.__init__
>  SocketServer -> socket.server
>  ssl -> socket.ssl
>
>  I know Guido has expressed his dislike of putting much code in a
>  package's __init__, but since every module that would go in this
>  package is dependent on the socket module anyway, I see no harm.
>
>  What do people think?
>

I like it. Also, I think it make sense to put socket's code in
socket.__init__. Doing otherwise, would be redundant for the users.
Imagine:

import socket.socket
s = socket.socket.socket(socket.socket.AF_INET, socket.socket.SOCK_STREAM)

Ugh! (Of course, you could do use a from-import, to avoid this)

-- Alexandre

From alexandre at peadrop.com  Mon Mar 10 01:52:29 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sun, 9 Mar 2008 20:52:29 -0400
Subject: [stdlib-sig] new package idea: zip
In-Reply-To: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
Message-ID: <acd65fa20803091752g4d5263bctc0e13bf7928b992a@mail.gmail.com>

On Sun, Mar 9, 2008 at 6:13 PM, Brett Cannon <brett at python.org> wrote:
> We have to files related to zip files: zipfile and zipimport. Should
>  we bother to consolidate? The problem is the obvious names conflict
>  with built-in type  and a keyword, respectively. A possibility is:
>
>  zipfile -> zip.filer
>  zipimport -> zip.importer
>
>  But I don't know if that is really an improvement. What do other people think?
>

I don't think it's an improvement either.

-- Alexandre

From brett at python.org  Mon Mar 10 02:20:25 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 18:20:25 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <acd65fa20803091750g3c6b2ea9jb45219fd59bcc2dd@mail.gmail.com>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<acd65fa20803091750g3c6b2ea9jb45219fd59bcc2dd@mail.gmail.com>
Message-ID: <bbaeab100803091820q11e30164va1c5a5c1fab17826@mail.gmail.com>

On Sun, Mar 9, 2008 at 5:50 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
>
> On Sun, Mar 9, 2008 at 6:15 PM, Brett Cannon <brett at python.org> wrote:
>  > So this one kind of is screaming at me:
>  >
>  >  socket -> socket.__init__
>  >  SocketServer -> socket.server
>  >  ssl -> socket.ssl
>  >
>  >  I know Guido has expressed his dislike of putting much code in a
>  >  package's __init__, but since every module that would go in this
>  >  package is dependent on the socket module anyway, I see no harm.
>  >
>  >  What do people think?
>  >
>
>  I like it. Also, I think it make sense to put socket's code in
>  socket.__init__. Doing otherwise, would be redundant for the users.
>  Imagine:
>
>  import socket.socket
>  s = socket.socket.socket(socket.socket.AF_INET, socket.socket.SOCK_STREAM)
>
>  Ugh! (Of course, you could do use a from-import, to avoid this)

I think that is the currently running argument, which is valid.

Fred's comment about reserving package initialization instead of
contents for __init__ makes sense. Question is whether Guido will go
for this. =)

And do we care about asyncore and asynchat? I figured they should stay out.

-Brett

From brett at python.org  Mon Mar 10 02:21:01 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 9 Mar 2008 18:21:01 -0700
Subject: [stdlib-sig] new package idea: zip
In-Reply-To: <acd65fa20803091752g4d5263bctc0e13bf7928b992a@mail.gmail.com>
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
	<acd65fa20803091752g4d5263bctc0e13bf7928b992a@mail.gmail.com>
Message-ID: <bbaeab100803091821r79ab5369n1e1e8df11af2d8c7@mail.gmail.com>

On Sun, Mar 9, 2008 at 5:52 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
>
> On Sun, Mar 9, 2008 at 6:13 PM, Brett Cannon <brett at python.org> wrote:
>  > We have to files related to zip files: zipfile and zipimport. Should
>  >  we bother to consolidate? The problem is the obvious names conflict
>  >  with built-in type  and a keyword, respectively. A possibility is:
>  >
>  >  zipfile -> zip.filer
>  >  zipimport -> zip.importer
>  >
>  >  But I don't know if that is really an improvement. What do other people think?
>  >
>
>  I don't think it's an improvement either.

OK. It was a shot in the dark anyway. It was the only other package
idea I could think of that had any form of a chance of working.

-Brett

From python at rcn.com  Mon Mar 10 03:29:59 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 9 Mar 2008 19:29:59 -0700
Subject: [stdlib-sig] new package idea: zip
References: <bbaeab100803091513u33174acby2414db66ed22ddcf@mail.gmail.com>
Message-ID: <002e01c88256$a3d283e0$6800a8c0@RaymondLaptop1>

> We have to files related to zip files: zipfile and zipimport. Should
> we bother to consolidate? The problem is the obvious names conflict
> with built-in type  and a keyword, respectively. A possibility is:
>
> zipfile -> zip.filer
> zipimport -> zip.importer
>
> But I don't know if that is really an improvement. What do other people think?

If you go down this road, then make it a compression  package and add bz2, gzip, etc.   There was a definite improvement when 
hashlib was introduced and a common API for hashing routines was enforced.  But, simply packaging two completely different zip 
modules is of dubious benefit.

Here's a general comment on the new package proposals like zip and cookie.  When people are looking for stdlib improvements, I don't 
think they had in mind introducing a new package everytime there were two related modules.  Packaging is not free -- it complicates 
importing, searching for source files, and makes the user have to rememember both the module name and the package name.

For me, the searching part really bites.  At work, we have a utils package which consists of a dozen unrelated utility files.  When 
you see code like "from utils import reversedict" you don't automatically know which module to look at to find the source code to 
see what it does.  Likewise, the multilayer directory structure complicates using grep (it's no fun always writing find . -name 
"*py" | xargs grep 'sometext').

Also, packaging exacerbate the existing annoyance that occurs when a class name closely corresponds to a module name.  It already 
feels redundant to write "from zipfile import ZipFile".  It will be even more annoying to write "from zip.zipfile import ZipFile". 
Yucko!

IOW, the conceptual benefits of grouping theme related modules can be more than offset by the expense of introducing another level 
of indirection.  Packaging should be a last resort rather than a first resort.


Raymond


From janssen at parc.com  Mon Mar 10 17:28:58 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 10 Mar 2008 09:28:58 PDT
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <1205106408.7780.17.camel@fsol> 
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol>
Message-ID: <08Mar10.092903pdt."58696"@synergy1.parc.xerox.com>

I just dug SSL out of the socket module; not eager to put it back in.

Bill

From brett at python.org  Mon Mar 10 22:00:54 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 10 Mar 2008 14:00:54 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <-3959530544800838063@unknownmsgid>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol> <-3959530544800838063@unknownmsgid>
Message-ID: <bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com>

On Mon, Mar 10, 2008 at 9:28 AM, Bill Janssen <janssen at parc.com> wrote:
> I just dug SSL out of the socket module; not eager to put it back in.

As in you don't like the idea of making it a module in the package?
This is not explicitly about merging code into the same file;
sslmodule.c would stay separate like it is.

-Brett

From janssen at parc.com  Mon Mar 10 22:46:02 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 10 Mar 2008 14:46:02 PDT
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com> 
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol> <-3959530544800838063@unknownmsgid>
	<bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com>
Message-ID: <08Mar10.144606pdt."58696"@synergy1.parc.xerox.com>

> On Mon, Mar 10, 2008 at 9:28 AM, Bill Janssen <janssen at parc.com> wrote:
> > I just dug SSL out of the socket module; not eager to put it back in.
> 
> As in you don't like the idea of making it a module in the package?

Yes.

> This is not explicitly about merging code into the same file;
> sslmodule.c would stay separate like it is.

As it was before.

Bill

From brett at python.org  Mon Mar 10 23:05:28 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 10 Mar 2008 15:05:28 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <-5132147026674008645@unknownmsgid>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol> <-3959530544800838063@unknownmsgid>
	<bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com>
	<-5132147026674008645@unknownmsgid>
Message-ID: <bbaeab100803101505h6c9aa63dqce09029a5f051a7f@mail.gmail.com>

On Mon, Mar 10, 2008 at 2:46 PM, Bill Janssen <janssen at parc.com> wrote:
> > On Mon, Mar 10, 2008 at 9:28 AM, Bill Janssen <janssen at parc.com> wrote:
>  > > I just dug SSL out of the socket module; not eager to put it back in.
>  >
>  > As in you don't like the idea of making it a module in the package?
>
>  Yes.
>
>
>  > This is not explicitly about merging code into the same file;
>  > sslmodule.c would stay separate like it is.
>
>  As it was before.

OK, I must be missing something, Bill, as I did not follow your SSL
rewrite carefully. You created the ssl module which is separate from
the socket module. It sounds like you did some untangling from the
socket module to make it a separate module.

And so you are objecting to having a socket package with the ssl
module in it because there used to be a socket.ssl or somehow the SSL
code was part of the socket module?

-Brett

From janssen at parc.com  Tue Mar 11 00:35:17 2008
From: janssen at parc.com (Bill Janssen)
Date: Mon, 10 Mar 2008 16:35:17 PDT
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <bbaeab100803101505h6c9aa63dqce09029a5f051a7f@mail.gmail.com> 
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol> <-3959530544800838063@unknownmsgid>
	<bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com>
	<-5132147026674008645@unknownmsgid>
	<bbaeab100803101505h6c9aa63dqce09029a5f051a7f@mail.gmail.com>
Message-ID: <08Mar10.163521pdt."58696"@synergy1.parc.xerox.com>

> And so you are objecting to having a socket package with the ssl
> module in it because there used to be a socket.ssl or somehow the SSL
> code was part of the socket module?

If you look at 2.6, you'll see that using the old "socket.ssl" is now
deprecated, to shift over to the new top-level ssl module.  Would be
max confusing to shift back to the bad old ssl module.  In addition,
this ruins the porting scheme we worked out, which is to be able to
deploy the new shiny ssl module in parallel with the old bad
socket.ssl module.

Bill

From brett at python.org  Tue Mar 11 00:45:08 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 10 Mar 2008 16:45:08 -0700
Subject: [stdlib-sig] new package idea: socket
In-Reply-To: <-9086921752995550928@unknownmsgid>
References: <bbaeab100803091515p4c99b8bavf94563f244cce540@mail.gmail.com>
	<1205106408.7780.17.camel@fsol> <-3959530544800838063@unknownmsgid>
	<bbaeab100803101400x18d922ecke7ea089368b29895@mail.gmail.com>
	<-5132147026674008645@unknownmsgid>
	<bbaeab100803101505h6c9aa63dqce09029a5f051a7f@mail.gmail.com>
	<-9086921752995550928@unknownmsgid>
Message-ID: <bbaeab100803101645q29214ed2u1734fb4da937db07@mail.gmail.com>

On Mon, Mar 10, 2008 at 4:35 PM, Bill Janssen <janssen at parc.com> wrote:
> > And so you are objecting to having a socket package with the ssl
>  > module in it because there used to be a socket.ssl or somehow the SSL
>  > code was part of the socket module?
>
>  If you look at 2.6, you'll see that using the old "socket.ssl" is now
>  deprecated, to shift over to the new top-level ssl module.  Would be
>  max confusing to shift back to the bad old ssl module.  In addition,
>  this ruins the porting scheme we worked out, which is to be able to
>  deploy the new shiny ssl module in parallel with the old bad
>  socket.ssl module.

Yeah, that kills it. Plus socket.socket.socket is just too
unreasonable to allow.

Damn, that's really too bad.

-Brett

From python at rcn.com  Tue Mar 11 01:00:50 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 10 Mar 2008 20:00:50 -0400 (EDT)
Subject: [stdlib-sig] new package idea: socket
Message-ID: <20080310200050.AIJ56862@ms19.lnh.mail.rcn.net>

> Plus socket.socket.socket is just too
> unreasonable to allow.

import socket ** 3


 ~ _
 @ @
 \_/

From brett at python.org  Fri Mar 14 20:39:27 2008
From: brett at python.org (Brett Cannon)
Date: Fri, 14 Mar 2008 14:39:27 -0500
Subject: [stdlib-sig] Problem with removing urllib
Message-ID: <bbaeab100803141239i225e7849nbaf7be86eb0073ce@mail.gmail.com>

I just realized there is an issue with the planned removal of urllib.
Up to this point all renamings have been a direct mapping of one
module to another one that had all the previously available objects.
The removal of urllib would break this. This would be especially
troublesome in the situation where someone was using urllib for its
parsing functions:

  from url import parse as urllib

That could leave to odd looks from users wondering why
urllib.URLOpener no longer exists. And you can't tack on another
import to get at URLOpener:

  from url import parse as urllib
  from url import requeset as urllib  # Overwrites previous import!

It seems to me that either we have to pretend urllib is not moved over
to Python 3.0 at all and have people manually move over code, or we
stick urllib into url.fetch and also copy the parse code over to
url.parse (and possibly cgi's one useful parsing function). That way
previous urllib owners can have 2to3 do:

  from url import fetch as urllib

and not end up with confusing AttributeErrors. And consolidating all
the parse functions into url.parse now will also allow for an eventual
deprecation of urllib the old-fashioned way in 3.x.

Does this all make sense? Or am I worrying too much?

-Brett

From facundobatista at gmail.com  Fri Mar 14 21:04:25 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 14 Mar 2008 15:04:25 -0500
Subject: [stdlib-sig] Problem with removing urllib
In-Reply-To: <bbaeab100803141239i225e7849nbaf7be86eb0073ce@mail.gmail.com>
References: <bbaeab100803141239i225e7849nbaf7be86eb0073ce@mail.gmail.com>
Message-ID: <e04bdf310803141304x5646b3ffp768bc03edcee6680@mail.gmail.com>

2008/3/14, Brett Cannon <brett at python.org>:

>  stick urllib into url.fetch and also copy the parse code over to
>  url.parse (and possibly cgi's one useful parsing function). That way

The one cgi's useful parsing function is "cgi.parse_qs" (the qs is
from "query string"). I saw zillion times people using urrlib and
import cgi only for this function.


>  and not end up with confusing AttributeErrors. And consolidating all
>  the parse functions into url.parse now will also allow for an eventual
>  deprecation of urllib the old-fashioned way in 3.x.
>
>  Does this all make sense? Or am I worrying too much?

I strongly prefer an error (or some additional work) in the migration,
than get some confusing states.

Regards,

--
.    Facundo

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

From jnoller at gmail.com  Tue Mar 18 16:44:10 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Tue, 18 Mar 2008 11:44:10 -0400
Subject: [stdlib-sig] Processing module inclusion into the stdlib proposal
Message-ID: <4222a8490803180844h2b1615d3o7c56448582cdff4a@mail.gmail.com>

I have started work on a PEP for the inclusion of the PyProcessing
module (http://pypi.python.org/pypi/processing/ and
http://developer.berlios.de/projects/pyprocessing) for inclusion into
the stdlib in an upcoming release.

The pyprocessing module "mostly mimicks" the threading module API to
provide a "drop in" process-based approach to concurrency allowing
applications within python to utilize multiple cores. For example:

from threading import Thread
class threads_object(Thread):
    def run(self):
        function_to_run()

becomes:

from processing import Process
class process_object(Process):
    def run(self):
        function_to_run()

Currently, the module runs on Unix/Linux/OSX and Windows. It supports
the following features:

* Objects can be transferred between processes using pipes or
  multi-producer/multi-consumer queues.

* Objects can be shared between processes using a server process or
  (for simple data) shared memory.

* Equivalents of all the synchronization primitives in ``threading``
  are available.

* A ``Pool`` class makes it easy to submit tasks to a pool of worker
  processes.

In addition to local concurrency ala "just like threading" model - the
processing module allows users to also share data and processes across
a cluster of machines via the server Managers and Proxy objects
(secured data transfer is supported, data is transferred via pickles).
I believe that prior/during inclusion, additional tests will be
desired to enhance coverage - but the tests which are already provided
test and showcase the module well.

I have spoken to the writer, Richard Oudkerk about his willingness to
maintain the processing module according to normal stdlib requirements
and he is more than willing to do so.

I believe inclusion into the standard library will be very beneficial
for a lot of people looking to larger-scale applications and for a
method to side-step the current threading/GIL implementation. This
module easily allows users to exploit their "$N core" machines, in a
fashion they are already familiar with.

I would suggest that the module is placed at the top-level next to the
threading module, however, there is the thought that both this module,
and the threading module should be moved to a concurrent.* namespace
(i.e: concurrent.threading, concurrent.processing) to allow for
additional library inclusion at a later date.

IMHO: I think this is simply a "first step" in the evolution of the
python stdlib to support these sorts of things - but I also believe it
is an excellent first step.

Please feel free to ask any questions, comments, etc. The more
feedback the better the PEP will be!

-jesse

From brett at python.org  Wed Mar 19 21:22:23 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 15:22:23 -0500
Subject: [stdlib-sig] All Mac modules listed for removal
Message-ID: <bbaeab100803191322o692c97f3u676275853ff23c55@mail.gmail.com>

So I just updated PEP 3108 to remove every Mac-specific module. Since
OS X includes Python and PyObjC then the usefulness of Mac-specific
modules is really minimal. And with bgen still not supporting UCS-4
builds and basically being unusable that really kills the modules.

-Brett

From ronaldoussoren at mac.com  Wed Mar 19 21:49:02 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 19 Mar 2008 21:49:02 +0100
Subject: [stdlib-sig] All Mac modules listed for removal
In-Reply-To: <bbaeab100803191322o692c97f3u676275853ff23c55@mail.gmail.com>
References: <bbaeab100803191322o692c97f3u676275853ff23c55@mail.gmail.com>
Message-ID: <E866025E-2FA7-45C7-AA40-2475EC7265CB@mac.com>


On 19 Mar, 2008, at 21:22, Brett Cannon wrote:
> So I just updated PEP 3108 to remove every Mac-specific module. Since
> OS X includes Python and PyObjC then the usefulness of Mac-specific
> modules is really minimal. And with bgen still not supporting UCS-4
> builds and basically being unusable that really kills the modules.

For the record: I mostly agree, most of the stuff in the Carbon  
namespace is deprecated by Apple and hasn't been updated since OSX  
10.0. You even need the OS9 SDK headers to regenerate those modules.

That said, urllib uses a Carbon APIs to detect proxy settings on OSX  
(urllib.getproxies_internetconfig) and IMHO that functionality should  
be maintained. That functionality is no reason to keep all of the  
Carbon bindings, we could add a simple extention module provides just  
this functionality (just like _winreg wraps just enough of the windows  
registry APIs).

I'll ask on the pythonmac-sig if anyone is really attached to bits of  
Lib/plat-mac and Mac/Modules, if anyone is attached they can help  
merging the useful functionality in PyObjC.

BTW. I don't agree with the second sentence, PyObjC and the Mac- 
specific modules barely overlap. There are much better reasons for  
dropping the mac-specific modules: (1) they are for the most part  
unmaintained and (2) platform bindings need to be outside of the core  
distribution to allow adapting to a changing platform without being  
bound by the stability requirements of the stdlib.

Ronald

-------------- 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/20080319/9802ae11/attachment.bin 

From brett at python.org  Wed Mar 19 21:59:55 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 15:59:55 -0500
Subject: [stdlib-sig] All Mac modules listed for removal
In-Reply-To: <E866025E-2FA7-45C7-AA40-2475EC7265CB@mac.com>
References: <bbaeab100803191322o692c97f3u676275853ff23c55@mail.gmail.com>
	<E866025E-2FA7-45C7-AA40-2475EC7265CB@mac.com>
Message-ID: <bbaeab100803191359o6ab0f33fv3ccd8bb43d2e10de@mail.gmail.com>

On Wed, Mar 19, 2008 at 3:49 PM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
>  On 19 Mar, 2008, at 21:22, Brett Cannon wrote:
>  > So I just updated PEP 3108 to remove every Mac-specific module. Since
>  > OS X includes Python and PyObjC then the usefulness of Mac-specific
>  > modules is really minimal. And with bgen still not supporting UCS-4
>  > builds and basically being unusable that really kills the modules.
>
>  For the record: I mostly agree, most of the stuff in the Carbon
>  namespace is deprecated by Apple and hasn't been updated since OSX
>  10.0. You even need the OS9 SDK headers to regenerate those modules.
>
>  That said, urllib uses a Carbon APIs to detect proxy settings on OSX
>  (urllib.getproxies_internetconfig) and IMHO that functionality should
>  be maintained. That functionality is no reason to keep all of the
>  Carbon bindings, we could add a simple extention module provides just
>  this functionality (just like _winreg wraps just enough of the windows
>  registry APIs).
>

Works for me.

>  I'll ask on the pythonmac-sig if anyone is really attached to bits of
>  Lib/plat-mac and Mac/Modules, if anyone is attached they can help
>  merging the useful functionality in PyObjC.
>
>  BTW. I don't agree with the second sentence, PyObjC and the Mac-
>  specific modules barely overlap. There are much better reasons for
>  dropping the mac-specific modules: (1) they are for the most part
>  unmaintained and (2) platform bindings need to be outside of the core
>  distribution to allow adapting to a changing platform without being
>  bound by the stability requirements of the stdlib.

No problem. I will change the PEP now.

-Brett

From brett at python.org  Thu Mar 20 05:16:25 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 23:16:25 -0500
Subject: [stdlib-sig] April 15th deadline to propose module removal
Message-ID: <bbaeab100803192116n2b047433m79fc55b30ae8bb7d@mail.gmail.com>

To make sure this all gets done I am putting a deadline of April 15th
for proposing module removals.

With the release schedule that Barry has drawn up, we have until June
1 to get the stdlib reorg. I don't see any big issues with meeting
this deadline, but it is something to keep in the back of everyone's
head. I think the biggest headache will be getting a 2to3 fixer to
work, but I think the fix_imports one is pretty close to being what we
need.

-Brett

From brett at python.org  Thu Mar 20 05:27:44 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 23:27:44 -0500
Subject: [stdlib-sig] proposed removal: netrc
Message-ID: <bbaeab100803192127t401acec4r4a11a001cee28623@mail.gmail.com>

Who even uses this stuff anymore? FTP itself is suspect, let alone
storing your password in a plaintext file.

-Brett

From brett at python.org  Thu Mar 20 05:29:43 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 23:29:43 -0500
Subject: [stdlib-sig] proposed removal: ftplib
Message-ID: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>

There is a better implementation in Twisted. FTP is inherently unsafe.
And the interface is pretty crappy.

-Brett

From brett at python.org  Thu Mar 20 05:50:04 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 23:50:04 -0500
Subject: [stdlib-sig] proposed removal: colorsys
Message-ID: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>

No one can remember what the module is for (pretty much no one here at
the sprint right now could remember what the module is for). Plus the
stdlib does not really aim towards image work.

-Brett

From brett at python.org  Thu Mar 20 05:59:24 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Mar 2008 23:59:24 -0500
Subject: [stdlib-sig] proposed removal: linecache
Message-ID: <bbaeab100803192159x515d371ax653c1c2499b5457b@mail.gmail.com>

Caching files is not a common thing. And even when you do it, it isn't
exactly hard to read a file into a list. Plus it isn't thread-safe.

-Brett

From brett at python.org  Thu Mar 20 06:02:40 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 20 Mar 2008 00:02:40 -0500
Subject: [stdlib-sig] proposed remoal: dircache
Message-ID: <bbaeab100803192202u759856e3l4804a7842d2d035f@mail.gmail.com>

dirache is less useful than linecache as getting the directory
contents is typically a very cheap operation. And implementing the
feature if you need is really cheap and not difficult to get right.

-Brett

From facundobatista at gmail.com  Thu Mar 20 06:20:46 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 20 Mar 2008 00:20:46 -0500
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
References: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
Message-ID: <e04bdf310803192220t63660c5fi6f50d5c217052239@mail.gmail.com>

2008/3/19, Brett Cannon <brett at python.org>:

> There is a better implementation in Twisted. FTP is inherently unsafe.
>  And the interface is pretty crappy.

But works, and I've seen a lot of code that does simple FTP pushing or
pulling files.

If we take this out, we'll lose this functionality from stdlib.

I'm -1 on this removal.

Furthermore: I propose that if you explicit more the "crappiness" of
it, I'd take a serious look at it.

Regards,

-- 
.    Facundo

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

From facundobatista at gmail.com  Thu Mar 20 06:25:00 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 20 Mar 2008 00:25:00 -0500
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <e04bdf310803192224n7d47084cpc03b23027a7c9159@mail.gmail.com>
References: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
	<e04bdf310803192220t63660c5fi6f50d5c217052239@mail.gmail.com>
	<e04bdf310803192224n7d47084cpc03b23027a7c9159@mail.gmail.com>
Message-ID: <e04bdf310803192225i70fcc837v50f560bccc38c632@mail.gmail.com>

2008/3/20, Facundo Batista <facundobatista at gmail.com>:

 >  Furthermore: I propose that if you explicit more the "crappiness" of
 >  it, I'd take a serious look at it.

If we can come with a nice API for it, maybe it'd be a good job for the GSoC...

 Do you think there's a good semantic anywhere to be stolen?

 Regards,

 --
 .    Facundo

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


-- 

.    Facundo

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

From python at rcn.com  Thu Mar 20 06:30:05 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 19 Mar 2008 22:30:05 -0700
Subject: [stdlib-sig]  proposed removal: ftplib
Message-ID: <012901c88a4b$748ae8a0$6800a8c0@RaymondLaptop1>

-1  Until there is a better implementation in the stdlib, I think this module needs to be kept. My company uses it and I've seen it 
used elsewhere.


 Raymond



From python at rcn.com  Thu Mar 20 06:36:13 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 19 Mar 2008 22:36:13 -0700
Subject: [stdlib-sig] proposed removal: netrc
References: <bbaeab100803192127t401acec4r4a11a001cee28623@mail.gmail.com>
Message-ID: <014201c88a4c$5006f540$6800a8c0@RaymondLaptop1>

I think these ought to be discussed on comp.lang.python.
ISTM, the most recent proposals are a bit cavalier
and need a fair hearing among potential constituents
before tossing out other peoples batteries 


Raymond




----- Original Message ----- 
From: "Brett Cannon" <brett at python.org>
To: "stdlib-sig" <stdlib-sig at python.org>
Sent: Wednesday, March 19, 2008 9:27 PM
Subject: [stdlib-sig] proposed removal: netrc


> Who even uses this stuff anymore? FTP itself is suspect, let alone
> storing your password in a plaintext file.
> 
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

From python at rcn.com  Thu Mar 20 07:12:10 2008
From: python at rcn.com (Raymond Hettinger)
Date: Wed, 19 Mar 2008 23:12:10 -0700
Subject: [stdlib-sig] proposed remoal: dircache
References: <bbaeab100803192202u759856e3l4804a7842d2d035f@mail.gmail.com>
Message-ID: <016d01c88a51$55b57ac0$6800a8c0@RaymondLaptop1>

+1 on removal.  The tiny bit of code is of neglible interest.

Raymond


----- Original Message ----- 
From: "Brett Cannon" <brett at python.org>
To: "stdlib-sig" <stdlib-sig at python.org>
Sent: Wednesday, March 19, 2008 10:02 PM
Subject: [stdlib-sig] proposed remoal: dircache


> dirache is less useful than linecache as getting the directory
> contents is typically a very cheap operation. And implementing the
> feature if you need is really cheap and not difficult to get right.
> 
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

From ronaldoussoren at mac.com  Thu Mar 20 08:12:40 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 20 Mar 2008 08:12:40 +0100
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
References: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
Message-ID: <FBBA8778-1BA0-4015-BE37-3D6E2E594508@mac.com>


On 20 Mar, 2008, at 5:29, Brett Cannon wrote:
> There is a better implementation in Twisted. FTP is inherently unsafe.
> And the interface is pretty crappy.

I'm -1 on this. FTP is still used to access embedded devices and  
Twisted is overkill for small scripts.

One usecase I use ftplib for is automaticly downloading configuration  
and error-logs from a number of devices that only offer FTP access to  
the raw data (and at best a crummy HTTP interface with a GUI).

Ronald

-------------- 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/20080320/ea1f83ea/attachment.bin 

From python at rcn.com  Thu Mar 20 08:27:23 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 20 Mar 2008 00:27:23 -0700
Subject: [stdlib-sig] proposed removal: linecache
References: <bbaeab100803192159x515d371ax653c1c2499b5457b@mail.gmail.com>
Message-ID: <018301c88a5b$d7d0c6e0$6800a8c0@RaymondLaptop1>

+1 for removal.
May need to move some of its code into the traceback module.

----- Original Message ----- 
From: "Brett Cannon" <brett at python.org>
To: "stdlib-sig" <stdlib-sig at python.org>
Sent: Wednesday, March 19, 2008 9:59 PM
Subject: [stdlib-sig] proposed removal: linecache


> Caching files is not a common thing. And even when you do it, it isn't
> exactly hard to read a file into a list. Plus it isn't thread-safe.
> 
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

From python at rcn.com  Thu Mar 20 08:28:20 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 20 Mar 2008 00:28:20 -0700
Subject: [stdlib-sig] proposed removal: colorsys
References: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>
Message-ID: <018801c88a5b$f96fa640$6800a8c0@RaymondLaptop1>

+1 for removal.


----- Original Message ----- 
From: "Brett Cannon" <brett at python.org>
To: "stdlib-sig" <stdlib-sig at python.org>
Sent: Wednesday, March 19, 2008 9:50 PM
Subject: [stdlib-sig] proposed removal: colorsys


> No one can remember what the module is for (pretty much no one here at
> the sprint right now could remember what the module is for). Plus the
> stdlib does not really aim towards image work.
> 
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

From python at rcn.com  Thu Mar 20 08:32:04 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 20 Mar 2008 00:32:04 -0700
Subject: [stdlib-sig] proposed removal: netrc
References: <bbaeab100803192127t401acec4r4a11a001cee28623@mail.gmail.com>
Message-ID: <018d01c88a5c$7f27d3c0$6800a8c0@RaymondLaptop1>

netrc is used in a fair amount of code:
http://www.google.com/codesearch?q=lang%3Apython+import+netrc&hl=en&btnG=Search+Code


Raymond


From qgallet at gmail.com  Thu Mar 20 09:26:16 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Thu, 20 Mar 2008 09:26:16 +0100
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
References: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
Message-ID: <8b943f2b0803200126t2aa25fe9i9b59b9fba1418605@mail.gmail.com>

-1 (as everyone else, apparently).

This is a useful module, that I regularly use, even if most of the time I'm
only pulling/pushing files.
I agree with Facundo, we'd rather improve it.

Quentin

On Thu, Mar 20, 2008 at 5:29 AM, Brett Cannon <brett at python.org> wrote:

> There is a better implementation in Twisted. FTP is inherently unsafe.
> And the interface is pretty crappy.
>
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080320/512ab3d2/attachment.htm 

From qgallet at gmail.com  Thu Mar 20 09:33:42 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Thu, 20 Mar 2008 09:33:42 +0100
Subject: [stdlib-sig] proposed remoal: dircache
In-Reply-To: <bbaeab100803192202u759856e3l4804a7842d2d035f@mail.gmail.com>
References: <bbaeab100803192202u759856e3l4804a7842d2d035f@mail.gmail.com>
Message-ID: <8b943f2b0803200133p7934d8a9n5997429952068921@mail.gmail.com>

+1 for removing it.

Quentin

On Thu, Mar 20, 2008 at 6:02 AM, Brett Cannon <brett at python.org> wrote:

> dirache is less useful than linecache as getting the directory
> contents is typically a very cheap operation. And implementing the
> feature if you need is really cheap and not difficult to get right.
>
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080320/30602786/attachment.htm 

From mal at egenix.com  Thu Mar 20 10:29:41 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 20 Mar 2008 10:29:41 +0100
Subject: [stdlib-sig] proposed removal: linecache
In-Reply-To: <018301c88a5b$d7d0c6e0$6800a8c0@RaymondLaptop1>
References: <bbaeab100803192159x515d371ax653c1c2499b5457b@mail.gmail.com>
	<018301c88a5b$d7d0c6e0$6800a8c0@RaymondLaptop1>
Message-ID: <47E22E85.50807@egenix.com>

On 2008-03-20 08:27, Raymond Hettinger wrote:
> +1 for removal.
> May need to move some of its code into the traceback module.

linecache has code that is specifically used for reading Python
modules. It's really just a helper for being able to print
tracebacks. Thread-safety is not a priority for this - module
code doesn't change that often ;-)

Moving the code to the traceback module seems fine.

> ----- Original Message ----- 
> From: "Brett Cannon" <brett at python.org>
> To: "stdlib-sig" <stdlib-sig at python.org>
> Sent: Wednesday, March 19, 2008 9:59 PM
> Subject: [stdlib-sig] proposed removal: linecache
> 
> 
>> Caching files is not a common thing. And even when you do it, it isn't
>> exactly hard to read a file into a list. Plus it isn't thread-safe.
>>
>> -Brett
>> _______________________________________________
>> stdlib-sig mailing list
>> stdlib-sig at python.org
>> http://mail.python.org/mailman/listinfo/stdlib-sig
> _______________________________________________
> 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, Mar 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  Thu Mar 20 10:31:03 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 20 Mar 2008 10:31:03 +0100
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
References: <bbaeab100803192129v2073392biac8b592b293d8619@mail.gmail.com>
Message-ID: <47E22ED7.8050703@egenix.com>

On 2008-03-20 05:29, Brett Cannon wrote:
> There is a better implementation in Twisted. FTP is inherently unsafe.
> And the interface is pretty crappy.

-1 for much the same reasons given by others.

The stdlib should provide basic interfaces for most common
Internet protocols. FTP is one of them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 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  Thu Mar 20 10:36:34 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 20 Mar 2008 10:36:34 +0100
Subject: [stdlib-sig] proposed removal: colorsys
In-Reply-To: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>
References: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>
Message-ID: <47E23022.9040809@egenix.com>

On 2008-03-20 05:50, Brett Cannon wrote:
> No one can remember what the module is for (pretty much no one here at
> the sprint right now could remember what the module is for). 

Just read the code: it's for converting between color systems, e.g.
HLS -> RGB.

> Plus the stdlib does not really aim towards image work.

True, but you need RGB values for most color values defined in web
standards and things like luminance are a lot easier to change in
HLS than in RGB.

-0 on removing it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 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 facundobatista at gmail.com  Thu Mar 20 17:11:39 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 20 Mar 2008 11:11:39 -0500
Subject: [stdlib-sig] proposed removal: colorsys
In-Reply-To: <47E23022.9040809@egenix.com>
References: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>
	<47E23022.9040809@egenix.com>
Message-ID: <e04bdf310803200911t86b493dv2530e48fe76e0e4d@mail.gmail.com>

2008/3/20, M.-A. Lemburg <mal at egenix.com>:

> Just read the code: it's for converting between color systems, e.g.
>  HLS -> RGB.

Or documentation [1], ;)

-0 to removing it.

Regards,

[1] http://docs.python.org/lib/module-colorsys.html

-- 
.    Facundo

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

From p.f.moore at gmail.com  Thu Mar 20 17:32:26 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 20 Mar 2008 16:32:26 +0000
Subject: [stdlib-sig] proposed removal: ftplib
In-Reply-To: <012901c88a4b$748ae8a0$6800a8c0@RaymondLaptop1>
References: <012901c88a4b$748ae8a0$6800a8c0@RaymondLaptop1>
Message-ID: <79990c6b0803200932se5b1a90lc56d1cb6dc08d612@mail.gmail.com>

On 20/03/2008, Raymond Hettinger <python at rcn.com> wrote:
> -1  Until there is a better implementation in the stdlib, I think this module needs to be kept.
> My company uses it and I've seen it used elsewhere.

-1 also. I use it.

As a general point, any module removal should note an acceptable
replacement, even if it's 3rd party.

Paul.

From p.f.moore at gmail.com  Thu Mar 20 17:44:45 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 20 Mar 2008 16:44:45 +0000
Subject: [stdlib-sig] proposed removal: colorsys
In-Reply-To: <47E23022.9040809@egenix.com>
References: <bbaeab100803192150o2a188ee3lb7a5c840c1d45bd7@mail.gmail.com>
	<47E23022.9040809@egenix.com>
Message-ID: <79990c6b0803200944j37884753l74fccc57316ac52e@mail.gmail.com>

On 20/03/2008, M.-A. Lemburg <mal at egenix.com> wrote:
>
> Just read the code: it's for converting between color systems, e.g.
>  HLS -> RGB.
>
>  > Plus the stdlib does not really aim towards image work.
>
> True, but you need RGB values for most color values defined in web
>  standards and things like luminance are a lot easier to change in
>  HLS than in RGB.
>
>  -0 on removing it.

I've never used it, but there have been cases where I could imagine
being glad of a HSV->RGB converter. And having it in the stdlib is
much better than having to hunt through PyPI trying to understand
specialist imaging libraries.

It's also only 126 lines of code[1], for pity's sake!

-0 on removing it.

Paul.

[1] Which I wouldn't know how to write, so I really appreciate someone
having done it for me!

From brett at python.org  Thu Mar 20 18:10:39 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 20 Mar 2008 12:10:39 -0500
Subject: [stdlib-sig] proposed removal: netrc
In-Reply-To: <014201c88a4c$5006f540$6800a8c0@RaymondLaptop1>
References: <bbaeab100803192127t401acec4r4a11a001cee28623@mail.gmail.com>
	<014201c88a4c$5006f540$6800a8c0@RaymondLaptop1>
Message-ID: <bbaeab100803201010i165a58bakf54170003a66b6c2@mail.gmail.com>

On Thu, Mar 20, 2008 at 12:36 AM, Raymond Hettinger <python at rcn.com> wrote:
> I think these ought to be discussed on comp.lang.python.
>  ISTM, the most recent proposals are a bit cavalier
>  and need a fair hearing among potential constituents
>  before tossing out other peoples batteries
>

That would make this SIG worthless if I can't get initial feedback here first.

And yes they are cavalier, but if someone doesn't propose something to
go then how am I supposed to know what is reasonable for it to go? My
assumptions about modules might be wrong and so proposing a removal
and having people just say "that goes too far" then that's fine.

And every removal is going to remove someone's batteries. It's a balancing act.

-Brett



>
>  Raymond
>
>
>
>
>
>
>  ----- Original Message -----
>  From: "Brett Cannon" <brett at python.org>
>  To: "stdlib-sig" <stdlib-sig at python.org>
>  Sent: Wednesday, March 19, 2008 9:27 PM
>  Subject: [stdlib-sig] proposed removal: netrc
>
>
>  > Who even uses this stuff anymore? FTP itself is suspect, let alone
>  > storing your password in a plaintext file.
>  >
>  > -Brett
>  > _______________________________________________
>  > stdlib-sig mailing list
>  > stdlib-sig at python.org
>  > http://mail.python.org/mailman/listinfo/stdlib-sig
>

From facundobatista at gmail.com  Thu Mar 20 18:47:25 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 20 Mar 2008 12:47:25 -0500
Subject: [stdlib-sig] Fwd: [New-bugs-announce] [issue2433] Merge audio
	modules
In-Reply-To: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
References: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
	<1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
Message-ID: <e04bdf310803201047r16dedb00k81e0c0f0abcd37d1@mail.gmail.com>

FYI

---------- Forwarded message ----------
From: Michael Bishop <report at bugs.python.org>
Date: 20-mar-2008 12:20
Subject: [New-bugs-announce] [issue2433] Merge  audio modules
To: new-bugs-announce at python.org



 New submission from Michael Bishop <michaelsplace at gmail.com>:

 There are many duplicate functions throughout the many audio modules. I
 plan to merge relevant functions into 2 modules; a C module and a py
 module. Once I go through the audio modules in detail, I'll post my plan
 here.

 Reference:
 http://www.python.org/dev/peps/pep-3108/
 http://mail.python.org/pipermail/python-3000/2007-January/005295.html

 ----------
 components: Library (Lib)
 messages: 64182
 nosy: MichaelBishop, brett.cannon
 severity: normal
 status: open
 title: Merge  audio modules
 type: behavior
 versions: Python 2.6, Python 3.0

 __________________________________
 Tracker <report at bugs.python.org>
 <http://bugs.python.org/issue2433>
 __________________________________
 _______________________________________________
 New-bugs-announce mailing list
 New-bugs-announce at python.org
 http://mail.python.org/mailman/listinfo/new-bugs-announce


-- 

.    Facundo

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

From brett at python.org  Fri Mar 21 03:53:51 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 20 Mar 2008 19:53:51 -0700
Subject: [stdlib-sig] Fwd: [New-bugs-announce] [issue2433] Merge audio
	modules
In-Reply-To: <e04bdf310803201047r16dedb00k81e0c0f0abcd37d1@mail.gmail.com>
References: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za>
	<e04bdf310803201047r16dedb00k81e0c0f0abcd37d1@mail.gmail.com>
Message-ID: <bbaeab100803201953s77dd9d1ap614c0cc6021bb9ac@mail.gmail.com>

On Thu, Mar 20, 2008 at 10:47 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> FYI
>

Thanks, Facundo. Michael talked to me while at the PyCon sprint so I
am aware of his idea.

-Brett

>
>
>  ---------- Forwarded message ----------
>  From: Michael Bishop <report at bugs.python.org>
>  Date: 20-mar-2008 12:20
>  Subject: [New-bugs-announce] [issue2433] Merge  audio modules
>  To: new-bugs-announce at python.org
>
>
>
>   New submission from Michael Bishop <michaelsplace at gmail.com>:
>
>   There are many duplicate functions throughout the many audio modules. I
>   plan to merge relevant functions into 2 modules; a C module and a py
>   module. Once I go through the audio modules in detail, I'll post my plan
>   here.
>
>   Reference:
>   http://www.python.org/dev/peps/pep-3108/
>   http://mail.python.org/pipermail/python-3000/2007-January/005295.html
>
>   ----------
>   components: Library (Lib)
>   messages: 64182
>   nosy: MichaelBishop, brett.cannon
>   severity: normal
>   status: open
>   title: Merge  audio modules
>   type: behavior
>   versions: Python 2.6, Python 3.0
>
>   __________________________________
>   Tracker <report at bugs.python.org>
>   <http://bugs.python.org/issue2433>
>   __________________________________
>   _______________________________________________
>   New-bugs-announce mailing list
>   New-bugs-announce at python.org
>   http://mail.python.org/mailman/listinfo/new-bugs-announce
>
>
>  --
>
>  .    Facundo
>
>  Blog: http://www.taniquetil.com.ar/plog/
>  PyAr: http://www.python.org/ar/
>  _______________________________________________
>  stdlib-sig mailing list
>  stdlib-sig at python.org
>  http://mail.python.org/mailman/listinfo/stdlib-sig
>

From solipsis at pitrou.net  Thu Mar 20 14:24:01 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 20 Mar 2008 14:24:01 +0100
Subject: [stdlib-sig] Processing module inclusion into the
	stdlib	proposal
In-Reply-To: <4222a8490803180844h2b1615d3o7c56448582cdff4a@mail.gmail.com>
References: <4222a8490803180844h2b1615d3o7c56448582cdff4a@mail.gmail.com>
Message-ID: <1206019441.7719.5.camel@fsol>


Le mardi 18 mars 2008 ? 11:44 -0400, Jesse Noller a ?crit :
> I have started work on a PEP for the inclusion of the PyProcessing
> module (http://pypi.python.org/pypi/processing/ and
> http://developer.berlios.de/projects/pyprocessing) for inclusion into
> the stdlib in an upcoming release.

I've never used the processing module, but I think including a
high-level cross-platform process-based concurrency mechanism to the
stdlib is a great idea. The API also seems very nice to me.

The only small remark I can make just by reading the doc is that
"Manager" is a very poor class name - couldn't it be something more
descriptive ? :-)

regards

Antoine.



From alexandre at peadrop.com  Sat Mar 22 05:44:17 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 22 Mar 2008 00:44:17 -0400
Subject: [stdlib-sig] Depreciation warnings in 2.6 for removed modules in 3.x
Message-ID: <acd65fa20803212144s3d36ca7dh6327564a8df03fda@mail.gmail.com>

Hi,

I would like to know what is the plan for the removal warnings in
2.6. PEP 3108 states:

   For the removal of modules that are continuing to exist in the
   Python 2.x series (i.e., not deprecated explicitly in the 2.x
   series), a proper warning will be set that is silenced by default;
   PendingDeprecationWarning initially, moving over to a Py3K-specific
   warning later if one comes into existence.

So if I understand correctly, this means that modules that already are
depreciated won't have an extra 3.x warning, right? And for other,
something like the following should be added, right?

   from warnings import warnpy3k as _warnpy3k
   _warnpy3k("The 'x' module is not supported in 3.x", stacklevel=2)

Finally, would it be a good idea to add tests for the added
warnings in test_py3kwarns? If so, what would be the best way to do it?
Does something like this would fit?

   def test_removed_modules(self):
       # For superseded modules, state the replacement
       expected = "The '%s' module is not supported in 3.x, use %s instead."
       replacements = {
          "hotshot": "the 'profile' module",
          "cProfile": "the 'profile' module",
          "cPickle": "the 'pickle' module",
          "rexec": "the exec statement",
          ...
       }
       for m, r in replacements:
           with catch_warning() as w:
               self.assertWarning(__import__(m), w, expected % (m, r))

Thanks,
-- Alexandre

From brett at python.org  Sat Mar 22 09:41:36 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 22 Mar 2008 01:41:36 -0700
Subject: [stdlib-sig] Depreciation warnings in 2.6 for removed modules
	in 3.x
In-Reply-To: <acd65fa20803212144s3d36ca7dh6327564a8df03fda@mail.gmail.com>
References: <acd65fa20803212144s3d36ca7dh6327564a8df03fda@mail.gmail.com>
Message-ID: <bbaeab100803220141j762193edr75aa2a45512e86a@mail.gmail.com>

On Fri, Mar 21, 2008 at 9:44 PM, Alexandre Vassalotti
<alexandre at peadrop.com> wrote:
> Hi,
>
>  I would like to know what is the plan for the removal warnings in
>  2.6. PEP 3108 states:
>
>    For the removal of modules that are continuing to exist in the
>    Python 2.x series (i.e., not deprecated explicitly in the 2.x
>    series), a proper warning will be set that is silenced by default;
>    PendingDeprecationWarning initially, moving over to a Py3K-specific
>    warning later if one comes into existence.
>
>  So if I understand correctly, this means that modules that already are
>  depreciated won't have an extra 3.x warning, right? And for other,
>  something like the following should be added, right?
>

Yes. To be ready for Py3K no warning, no matter the type, should be
raised in your code. So only one warning is really needed.

>    from warnings import warnpy3k as _warnpy3k
>    _warnpy3k("The 'x' module is not supported in 3.x", stacklevel=2)
>
>  Finally, would it be a good idea to add tests for the added
>  warnings in test_py3kwarns? If so, what would be the best way to do it?
>  Does something like this would fit?
>
>    def test_removed_modules(self):
>        # For superseded modules, state the replacement
>        expected = "The '%s' module is not supported in 3.x, use %s instead."
>        replacements = {
>           "hotshot": "the 'profile' module",
>           "cProfile": "the 'profile' module",
>           "cPickle": "the 'pickle' module",
>           "rexec": "the exec statement",
>           ...
>        }
>        for m, r in replacements:
>            with catch_warning() as w:
>                self.assertWarning(__import__(m), w, expected % (m, r))

Yeah, more or less.

-Brett

From mark at qtrac.eu  Wed Mar 26 08:15:53 2008
From: mark at qtrac.eu (Mark Summerfield)
Date: Wed, 26 Mar 2008 07:15:53 +0000
Subject: [stdlib-sig] Py3K bsddb name query
Message-ID: <200803260715.53293.mark@qtrac.eu>

Hi,

I notice that in PEP 3108 the dbm modules are going to be in package
dbm:

    New		Old
    ----------- --------------------------------------------
    dbm.tools	anydbm + whichdb
    dbm.db	db.hash (actually bsd db so presumably using
		bsddb.hashopen() behind the scenes?)
    dbm.ndbm	dbm
    dbm.dumb	dumbdbm 
    dbm.gnu	gdbm

This leaves bsddb as a separate package. As far as I can tell bsddb is
not so different from the others. I presume (although the documentation
for bsddbobject.keys() denies it) that btopen() gives lexicographical
ordering and rnopen() give insertion order ordering by keys, whereas
hashopen() is unordered like a dict and like the other dbms provided.

In any case the name dbm.db seems wrong to me (too generic when the
others are specific to their dbm type), so at the least shouldn't dbm.db
be renamed dbm.bsd?

If consistency were wanted, dbm.bsd.open() could be a wrapper for
dbm.bsd.hashopen() but only with filenname, flag and mode arguments so
as to match the other dbms, and with dbm.bsd.hashopen(),
dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific
functions available in the module as usual?

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From brett at python.org  Wed Mar 26 20:30:29 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 26 Mar 2008 12:30:29 -0700
Subject: [stdlib-sig] Py3K bsddb name query
In-Reply-To: <200803260715.53293.mark@qtrac.eu>
References: <200803260715.53293.mark@qtrac.eu>
Message-ID: <bbaeab100803261230g5d7ab130g1abb695b4deacaff@mail.gmail.com>

On Wed, Mar 26, 2008 at 12:15 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> Hi,
>
>  I notice that in PEP 3108 the dbm modules are going to be in package
>  dbm:
>
>     New         Old
>     ----------- --------------------------------------------
>     dbm.tools   anydbm + whichdb
>     dbm.db      db.hash (actually bsd db so presumably using
>                 bsddb.hashopen() behind the scenes?)
>     dbm.ndbm    dbm
>     dbm.dumb    dumbdbm
>     dbm.gnu     gdbm
>
>  This leaves bsddb as a separate package. As far as I can tell bsddb is
>  not so different from the others. I presume (although the documentation
>  for bsddbobject.keys() denies it) that btopen() gives lexicographical
>  ordering and rnopen() give insertion order ordering by keys, whereas
>  hashopen() is unordered like a dict and like the other dbms provided.
>
>  In any case the name dbm.db seems wrong to me (too generic when the
>  others are specific to their dbm type), so at the least shouldn't dbm.db
>  be renamed dbm.bsd?
>

Good point. Anyone object to that renaming?

>  If consistency were wanted, dbm.bsd.open() could be a wrapper for
>  dbm.bsd.hashopen() but only with filenname, flag and mode arguments so
>  as to match the other dbms, and with dbm.bsd.hashopen(),
>  dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific
>  functions available in the module as usual?
>

Adding new functions is beyond the reorganization of the stdlib. But
it could be considered as a separate idea.

-Brett

From qgallet at gmail.com  Wed Mar 26 23:33:36 2008
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Wed, 26 Mar 2008 23:33:36 +0100
Subject: [stdlib-sig] Py3K bsddb name query
In-Reply-To: <bbaeab100803261230g5d7ab130g1abb695b4deacaff@mail.gmail.com>
References: <200803260715.53293.mark@qtrac.eu>
	<bbaeab100803261230g5d7ab130g1abb695b4deacaff@mail.gmail.com>
Message-ID: <8b943f2b0803261533j173ad079ncf368c4bcbae1eb9@mail.gmail.com>

On Wed, Mar 26, 2008 at 8:30 PM, Brett Cannon <brett at python.org> wrote:

> On Wed, Mar 26, 2008 at 12:15 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> > Hi,
> >
> >  I notice that in PEP 3108 the dbm modules are going to be in package
> >  dbm:
> >
> >     New         Old
> >     ----------- --------------------------------------------
> >     dbm.tools   anydbm + whichdb
> >     dbm.db      db.hash (actually bsd db so presumably using
> >                 bsddb.hashopen() behind the scenes?)
> >     dbm.ndbm    dbm
> >     dbm.dumb    dumbdbm
> >     dbm.gnu     gdbm
> >
> >  This leaves bsddb as a separate package. As far as I can tell bsddb is
> >  not so different from the others. I presume (although the documentation
> >  for bsddbobject.keys() denies it) that btopen() gives lexicographical
> >  ordering and rnopen() give insertion order ordering by keys, whereas
> >  hashopen() is unordered like a dict and like the other dbms provided.
> >
> >  In any case the name dbm.db seems wrong to me (too generic when the
> >  others are specific to their dbm type), so at the least shouldn't
> dbm.db
> >  be renamed dbm.bsd?
> >
>
> Good point. Anyone object to that renaming?


+1 for dbm.bsd, it's more informative.


>
> >  If consistency were wanted, dbm.bsd.open() could be a wrapper for
> >  dbm.bsd.hashopen() but only with filenname, flag and mode arguments so
> >  as to match the other dbms, and with dbm.bsd.hashopen(),
> >  dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific
> >  functions available in the module as usual?
> >
>
> Adding new functions is beyond the reorganization of the stdlib. But
> it could be considered as a separate idea.
>
> -Brett
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080326/79b7e421/attachment.htm 

From santagada at gmail.com  Thu Mar 27 01:00:57 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Wed, 26 Mar 2008 21:00:57 -0300
Subject: [stdlib-sig] Py3K bsddb name query
In-Reply-To: <8b943f2b0803261533j173ad079ncf368c4bcbae1eb9@mail.gmail.com>
References: <200803260715.53293.mark@qtrac.eu>
	<bbaeab100803261230g5d7ab130g1abb695b4deacaff@mail.gmail.com>
	<8b943f2b0803261533j173ad079ncf368c4bcbae1eb9@mail.gmail.com>
Message-ID: <191223F0-9ECE-4B10-A3AE-8D02CFEA3FA6@gmail.com>


On 26/03/2008, at 19:33, Quentin Gallet-Gilles wrote:
>
>
> On Wed, Mar 26, 2008 at 8:30 PM, Brett Cannon <brett at python.org>  
> wrote:
> On Wed, Mar 26, 2008 at 12:15 AM, Mark Summerfield <mark at qtrac.eu>  
> wrote:
> > Hi,
> >
> >  I notice that in PEP 3108 the dbm modules are going to be in  
> package
> >  dbm:
> >
> >     New         Old
> >     ----------- --------------------------------------------
> >     dbm.tools   anydbm + whichdb
> >     dbm.db      db.hash (actually bsd db so presumably using
> >                 bsddb.hashopen() behind the scenes?)
> >     dbm.ndbm    dbm
> >     dbm.dumb    dumbdbm
> >     dbm.gnu     gdbm
> >
> >  This leaves bsddb as a separate package. As far as I can tell  
> bsddb is
> >  not so different from the others. I presume (although the  
> documentation
> >  for bsddbobject.keys() denies it) that btopen() gives  
> lexicographical
> >  ordering and rnopen() give insertion order ordering by keys,  
> whereas
> >  hashopen() is unordered like a dict and like the other dbms  
> provided.
> >
> >  In any case the name dbm.db seems wrong to me (too generic when the
> >  others are specific to their dbm type), so at the least shouldn't  
> dbm.db
> >  be renamed dbm.bsd?
> >
>
> Good point. Anyone object to that renaming?
>
> +1 for dbm.bsd, it's more informative.


+1

--
Leonardo Santagada





From g.rodola at gmail.com  Fri Mar 28 14:13:49 2008
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Fri, 28 Mar 2008 14:13:49 +0100
Subject: [stdlib-sig] What about a mirror to Google Groups?
Message-ID: <6927f550803280613l79e21223i394c6365ba8af54c@mail.gmail.com>

Hi,
Do you think it would be possible to create a mirrror of this list to
Google Groups?
I usually read python-dev, python-3000 and python-ideas via Google
Groups which I find very convenient (or, at least, surely more
convenient than using the stinky mailman web interface).

Toughs?

From brett at python.org  Sat Mar 29 08:00:59 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 29 Mar 2008 08:00:59 +0100
Subject: [stdlib-sig] What about a mirror to Google Groups?
In-Reply-To: <6927f550803280613l79e21223i394c6365ba8af54c@mail.gmail.com>
References: <6927f550803280613l79e21223i394c6365ba8af54c@mail.gmail.com>
Message-ID: <bbaeab100803290000j463f6aa8q183443a5a0a83878@mail.gmail.com>

On Fri, Mar 28, 2008 at 2:13 PM, Giampaolo Rodol? <g.rodola at gmail.com> wrote:
> Hi,
>  Do you think it would be possible to create a mirrror of this list to
>  Google Groups?
>  I usually read python-dev, python-3000 and python-ideas via Google
>  Groups which I find very convenient (or, at least, surely more
>  convenient than using the stinky mailman web interface).
>
>  Toughs?

Perhaps, but I am out of the country right now and so not in a
position to look into this.

-Brett

From Ronny.Pfannschmidt at gmx.de  Sat Mar 29 15:02:28 2008
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 29 Mar 2008 15:02:28 +0100
Subject: [stdlib-sig] reorganizing xmlrpc and adding json/jsonrpc
Message-ID: <20080329150228.22f1e9f0@ronnyger.mine.nu>

hi,

I propose adding a json lib in combination with a reorganisation of xmlrpc in order to support jsonrpc either by choice of the programmer or content-type neogation.

This mostly requires a json lib that's able to marshal jsonrpc requests/responses sharing the api of the xmlrpclib and some simple content-type choice in the rpcserver.

additional changes could be the reimplementation in terms of wsgi instead of having separate cgi/http server implementations and recreating the original api in terms of the wsgiref cgi/standalone handlers.

I'm looking forward to comments on this.

---
Ronny Pfannschmidt

From brett at python.org  Sat Mar 29 16:18:35 2008
From: brett at python.org (Brett Cannon)
Date: Sat, 29 Mar 2008 16:18:35 +0100
Subject: [stdlib-sig] reorganizing xmlrpc and adding json/jsonrpc
In-Reply-To: <20080329150228.22f1e9f0@ronnyger.mine.nu>
References: <20080329150228.22f1e9f0@ronnyger.mine.nu>
Message-ID: <bbaeab100803290818o120bab67ufa2f47ea51ec1eb4@mail.gmail.com>

On Sat, Mar 29, 2008 at 3:02 PM, Ronny Pfannschmidt
<Ronny.Pfannschmidt at gmx.de> wrote:
> hi,
>
>  I propose adding a json lib in combination with a reorganisation of xmlrpc in order to support jsonrpc either by choice of the programmer or content-type neogation.
>
>  This mostly requires a json lib that's able to marshal jsonrpc requests/responses sharing the api of the xmlrpclib and some simple content-type choice in the rpcserver.

Adding a JSON library is already under discussion on the web SIG. I
would go read their archives and join the discussion there.

As for any merging with xmlrpc, that's fine, but it must be done in a
backwards-compatible way.

-Brett