This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eli.bendersky
Recipients Arfrever, effbot, eli.bendersky, eric.araujo, ezio.melotti, flox, scoder
Date 2012-02-11.07:41:27
SpamBayes Score 6.4081185e-09
Marked as misclassified No
Message-id <CAF-Rda9tr1HFRZU86iJDMJ6cqh-Y4kQMSiGXJPwccKi2V=SaPw@mail.gmail.com>
In-reply-to <1328938344.35.0.897611983362.issue13988@psf.upfronthosting.co.za>
Content
> I strongly feel that existing code importing ElementTree or cElementTree should not be broken.  Let’s add transparent import from _elementtree to ElementTree without breaking existing uses of cET.
>

AFAICS there's currently no disagreement on this point. The import
from cElementTree will keep working in 3.3 as it always had. However,
the explicit mention of cElementTree should be removed from the
documentation of ElementTree. The only remaining question is whether a
silent deprecation warning should be added in cElementTree.

> I think that 3.2 and 2.7 should get a doc note about cET, do we have a bug for this?
>

What doc note? Something in the spirit of: "Note that in 3.3, the
accelerated C implementation will be provided by default when
importing ElementTree" - or do you mean something else?

I don't think there's an open bug for this.
History
Date User Action Args
2012-02-11 07:41:29eli.benderskysetrecipients: + eli.bendersky, effbot, scoder, ezio.melotti, eric.araujo, Arfrever, flox
2012-02-11 07:41:27eli.benderskylinkissue13988 messages
2012-02-11 07:41:27eli.benderskycreate