On Sat, Mar 1, 2008 at 4:34 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-03-01 05:06, Brett Cannon wrote:
Seriously, I just don't want to support two different approaches to
the same problem.
Then what makes you believe that the urllib2 approach is the
better one ?
Why
On Fri, Feb 29, 2008 at 3:47 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On Fri, Feb 29, 2008 at 11:52 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2008-02-29 20:20, Brett Cannon wrote:
So, I'd be +1 on the second approach, provided that those
two classes
[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
On Thu, Feb 28, 2008 at 4:56 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
I'm inclined towards the fancy naming option. Ditching the most commonly
used module in the standard library doesn't seem like progress to me. The
thing that seems to bug people is choosing between urllib and
When I brought this up last it was when I first began bombarding this
list with stdlib reorganization questions, so there was some noise
about the whole process and no clear resolution was reached.
The problem is that both modules have a Cookie class, so they can be
merged. Much like the url*
On Thu, Feb 21, 2008 at 7:34 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 8:16 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 2:48 PM, Ian Bicking [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
which I am liking. But I figured I would ask
On Feb 20, 2008 7:43 AM, Fred Drake [EMAIL PROTECTED] wrote:
On Feb 20, 2008 9:35 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
ISTR that HTMLParser was the preferred one. It is certainly newer, and
doesn't carry the baggage of sgmllib which I would discard together
with htmllib). Maybe
Since Bill Janssen prodded me on to this list I might as well take
advantage now and bug you all about how to deal with Cookie and
cookielib in the stdlib reorg.
My current idea is the new names cookie.client and cookie.server for
Cookie and cookielib, respectively. While this goes against the
On Feb 5, 2008 3:40 PM, Robert Brewer [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
So my question is whether you all would be up for handling a merging
of Cookie and cookielib for 2.6?
I appreciate the thought and effort for a smooth transition, but -1 on
this idea if I understand
On Feb 4, 2008 11:39 AM, Ian Bicking [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On Feb 3, 2008 3:41 PM, Ian Bicking [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
As part of the standard library cleanup for Python 3.0, it has been
suggested to me that the Cookie module be removed
On Feb 4, 2008 12:50 PM, Bill Janssen [EMAIL PROTECTED] wrote:
I think most web frameworks use setuptools at this point. I'd rather
get this as a distribution, rather than from the standard library. In
fact, I'd prefer to see all web-development libraries distributed
separate from the
As part of the standard library cleanup for Python 3.0, it has been
suggested to me that the Cookie module be removed. The rationale for
this is that most of the module is already deprecated and cookielib
does a better job for cookie support anyway.
I just wanted to see if anyone here had strong
12 matches
Mail list logo
