On Sun, May 11, 2008 at 8:31 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Brett Cannon schrieb:
>>
>> 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.__i
-Brett [from his iPod touch]
On 11-May-08, at 0:04, Fred Drake <[EMAIL PROTECTED]> wrote:
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 Deprecat
-Brett [from his iPod touch]
On 10-May-08, at 23:58, "Alexandre Vassalotti" <[EMAIL PROTECTED]>
wrote:
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
-Brett [from his iPod touch]
On 10-May-08, at 23:46, "Alexandre Vassalotti" <[EMAIL PROTECTED]>
wrote:
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
On 10-May-08, at 20:43, [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 package of the same n
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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
Brett Cannon schrieb:
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 wor
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 May 11
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
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
12 matches
Mail list logo
