On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I see three solutions for dealing with this.
>
> 1. Have stubs for the entire urllib API in urllib.__init__ that raise
> a DeprecationWarning either specifying the new name or saying the
> function/class is deprecated.
>
>
On Sat, May 10, 2008 at 11:43 PM, <[EMAIL PROTECTED]> wrote:
>
>Brett> There is going to be an issue with the current proposal for
>Brett> keeping around urllib. Since the package is to be named the same
>Brett> thing as the module
>
> Is this the only module morphing into a packag
On May 10, 2008, at 11:49 PM, Guido van Rossum wrote:
Works for me. The other thing I always use from cgi is escape() --
will that be available somewhere else too?
xml.sax.saxutils.escape() would be an appropriate replacement, though
the location is a little funky.
-Fred
--
Fred Drake
Works for me. The other thing I always use from cgi is escape() --
will that be available somewhere else too?
On Sat, May 10, 2008 at 8:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I just realized that PEP 3108 was missing one proposal from the stdlib
> SIG (originally proposed by Facundo Bati
Brett> There is going to be an issue with the current proposal for
Brett> keeping around urllib. Since the package is to be named the same
Brett> thing as the module
Is this the only module morphing into a package of the same name?
Skip
___
There is going to be an issue with the current proposal for keeping
around urllib. Since the package is to be named the same thing as the
module, to handle the new name that means urllib.__init__ will need to
gain the Py3K warning for the new name. But that doesn't quite work as
the package's modul
I just realized that PEP 3108 was missing one proposal from the stdlib
SIG (originally proposed by Facundo Batista) of copying the
cgi.parse_qs() function over to the new urllib.parse module so that
people no longer need to import the cgi module just for that one
parsing function. Does anyone objec
Greg Ewing wrote:
I wouldn't like to see any guideline that said you
should only use double quotes or something like that.
Nah, it was more a philosophical discussion prompted by a comment from
me regarding my personal reasons for preferring different styles of
quotes in certain situations.
Greg> I wouldn't like to see any guideline that said you should only use
Greg> double quotes or something like that.
It might be useful to have a wiki page which identified some of the
conventions people use.
Skip
___
Python-Dev mailing list
P
[EMAIL PROTECTED] wrote:
While Python doesn't have a char type (yet), I still find the distinction
between 'c' and "abc" useful to show intent (especially given my C
background
The way I tend to use them is that "xxx" is for data
operated on by the program and seen by the user,
and 'xxx' is fo
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|
| Moving from python-checkins and giving this topic a proper subject. The
| original thread started here with a checkin by Benjamin:
|
|http://mail.python.org/pipermail/python-checkins/2008-May/069181.html
To me, those changes ar
[EMAIL PROTECTED] schrieb:
Moving from python-checkins and giving this topic a proper subject. The
original thread started here with a checkin by Benjamin:
http://mail.python.org/pipermail/python-checkins/2008-May/069181.html
While Python doesn't have a char type (yet), I still find the di
Moving from python-checkins and giving this topic a proper subject. The
original thread started here with a checkin by Benjamin:
http://mail.python.org/pipermail/python-checkins/2008-May/069181.html
While Python doesn't have a char type (yet), I still find the distinction
between 'c' and "a
On 2008-05-10 01:18, Martin v. Löwis wrote:
Is there a tool available that can convert 2.x code automagically
to the .format() method syntax ?
Just did a quick grep of our code base and it has some 2000 lines of code
that would need to be changed.
Why do you think this code needs to change?
I
2008/5/10 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> I've already wrapped all the Ttk functionality by now, and I will
>> complete the documentation till the first betas.
>> But as you know there isn't much people using (I know myself and a Tcl
>> guy) so I'm not sure if it would be acceptable to in
> I've already wrapped all the Ttk functionality by now, and I will
> complete the documentation till the first betas.
> But as you know there isn't much people using (I know myself and a Tcl
> guy) so I'm not sure if it would be acceptable to include this module
> right into these betas, or would
16 matches
Mail list logo
