On 1/7/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
I've been thinking a little about how and where we'd add warnings to
2.6 and later for things that will break in 3.0. My first idea is
to add a command line option '-3' (or maybe '-warn3') implemented
as "from __future__ import py3k". We can t
On Monday 08 January 2007 22:53, Thomas Wouters wrote:
> I would prefer -Wpy3k, or the corresponding
> warnings.filterwarnings call, and just not warn in too many
> (used) places.
-W seems like an option. We can add other -W options later
(for instance, -W tabs). Hm. -W already has a meaning, thou
On 1/8/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
On Monday 08 January 2007 22:53, Thomas Wouters wrote:
> I would prefer -Wpy3k, or the corresponding
> warnings.filterwarnings call, and just not warn in too many
> (used) places.
-W seems like an option. We can add other -W options later
(fo
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >The transformation is as Phillip outlined above, with extra logic to
> >handle the case where e is a tuple or list.
>
> In the tuple or list case, there's no need to reset the variables, becau
At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
>On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>> >The transformation is as Phillip outlined above, with extra logic to
>> >handle the case where e is a tuple or list.
>>
>>In the tuple or lis
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
> >On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >> >The transformation is as Phillip outlined above, with extra logic to
> >> >handl
At 11:34 AM 1/8/2007 -0600, Collin Winter wrote:
>On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
>> >On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>> >> >The transformation is as Ph
I seem to recall
> that Guido wanted to move to an 'as' clause for Py3K anyway, to avoid the
> "except FooExc, BarExc:" anti-pattern. So now seems as good a time "as"
> any. :)
http://mail.python.org/pipermail/python-dev/2006-March/062449.html
http://mail.python.org/pipermail/python-dev/2006-
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 12/30/06, Talin <[EMAIL PROTECTED]> wrote:
> > Maybe this would be a good time to review, or at least restate, the
> > specific plans for strings in Py3K? I know that there's been a great
> > deal of discussion on this, but a lot of that discussio
Anthony Baxter wrote:
> I'm not sure whether we should try and warn about 'print' becoming a
> function. We should also consider things like intern() and
> compile() (if they are to move to sys).
I think it's fine if we prepare an upgrade path: for instance, we could add
sys.intern() and sys.c
On Monday 08 January 2007 22:53, Thomas Wouters wrote:
> (Also on my warn-TODO for 2.6 are coerce(), __get/set/delslice__
Should we warn on use of the __slice__ methods and the __cmp__
method, or hook into the object code to warn when they're defined?
I guess the latter would be more proactive. O
On Tue, Jan 09, 2007, Anthony Baxter wrote:
> On Monday 08 January 2007 22:53, Thomas Wouters wrote:
>>
>> (Also on my warn-TODO for 2.6 are coerce(), __get/set/delslice__
>
> Should we warn on use of the __slice__ methods and the __cmp__
> method, or hook into the object code to warn when they'r
On 1/8/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>
> Do we also want to warn about use of sq_slice and sq_ass_slice with
> C-code objects? (And yes, my inner 12 year old still giggles about
> sq_ass_slice)
Sometimes it's nice to know you aren't alone. :-)
> My concern is that having to dive i
13 matches
Mail list logo
