Charles Merriam wrote:
> I hate bringing up something that has been hashed over so many times,
> but I'm a bear
> of little brain and am not understanding the migration path. The
> whole use of the "2to3"
> tools seems like an abrupt hack. It is workable, but causes a serious
> plan for near term
> 2.x to 3.x migration. I'd like to present a different view. Instead
> of just yelling how it
> must be wrong, consider it. It's not far from the current migration
> path and is less rocky.
I'm not understanding what you are asking for that isn't being done
already. There are a variety of from __future__ or from future_builtins
options to enable various bits and pieces, and if you don't want the
warnings, don't switch on the py3k warnings flag.
If you're asking for multiple command line switches to enable different
subsets of the py3k warnings, that isn't going to happen. The only
reason even the py3k warnings flag exists is to prevent the warnings
having too much of a speed impact during normal execution of Python 2.6
code - aside from that specific optimisation, the intention is for
developers to enable or disable warnings of interest via the normal
mechanisms in the warnings module.
So you *have* fine grained control - right down to choosing which
individual warnings you want to ignore (for the moment, anyway).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
