On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote:
> With the deprecation warning being silent, is there much to lose, though?
Yes, it creates problems for anyone that deliberately converts all
warnings to errors when running their test suites. This forces them to
spend time switching over to
> Currently in 3.3 the whole cElementTree module is:
> >
> > # Deprecated alias for xml.etree.ElementTree
> >
> > from xml.etree.ElementTree import *
> >
> > Would it be alright to issue a DeprecationWarning if this module is
> > imported? Then hopefully a couple of releases after 3.3 we can j
On Tue, Feb 14, 2012 at 1:42 PM, Eli Bendersky wrote:
> An open question remains on whether to deprecate cElementTree, now that this
> change is in place.
>
> Currently in 3.3 the whole cElementTree module is:
>
> # Deprecated alias for xml.etree.ElementTree
>
> from xml.etree.ElementTree impo
>
> The change was committed to the default branch. In 3.3, "import
> xml.etree.ElementTree" will automatically use the _elementtree accelerator,
> if available, and will fall back to a Python implementation otherwise. The
> documentation of ElementTree has also been updated to reflect this fact.
>
On Tue, Feb 14, 2012 at 8:08 AM, Barry Warsaw wrote:
> On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
>
>>I think Antoine makes a good point about ease of introspection when
>>you have multiple versions in the same series installed, so I'd be
>>fine with:
>>- updating the PEP recommendation to
On Tue, Feb 14, 2012 at 7:07 AM, "Martin v. Löwis" wrote:
>> I think Antoine makes a good point about ease of introspection when
>> you have multiple versions in the same series installed, so I'd be
>> fine with:
>> - updating the PEP recommendation to say that either form of link is
>> fine (with
On Tue, Feb 14, 2012 at 4:33 AM, Victor Stinner
wrote:
>> However, I am still -1 on the solution proposed by the PEP. I still think
>> that migrating to datetime use is a better way to go, rather than a
>> proliferation of the data types used to represent timestamps, along with an
>> API to speci
In article ,
Ned Deily wrote:
> In article ,
> "Russell E. Owen" wrote:
> > One problem I've run into is that the 64-bit Mac python 2.7 does not
> > work properly with ActiveState Tcl/Tk. One symptom is to build
> > matplotlib. The results fail -- both versions of Tcl/Tk somehow get
> > lin
On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
>I think Antoine makes a good point about ease of introspection when
>you have multiple versions in the same series installed, so I'd be
>fine with:
>- updating the PEP recommendation to say that either form of link is
>fine (with hard links margin
Antoine Pitrou conviced me to drop simply the int type: float and
Decimal are just enough. Use an explicit cast using int() to get int.
os.stat_float_times() is still deprecated by the PEP.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://
> I think Antoine makes a good point about ease of introspection when
> you have multiple versions in the same series installed, so I'd be
> fine with:
> - updating the PEP recommendation to say that either form of link is
> fine (with hard links marginally faster, but harder to introspect)
> - not
> However, I am still -1 on the solution proposed by the PEP. I still think
> that migrating to datetime use is a better way to go, rather than a
> proliferation of the data types used to represent timestamps, along with an
> API to specify the type of data returned.
>
> Let's look at each item in
On Feb 13, 2012, at 01:28 AM, Victor Stinner wrote:
>I'm still waiting for Nick Coghlan and Guido van Rossum for their
>decision on the PEP.
Thanks for continuing to work on this Victor. I agree with the general
motivation behind the PEP, and appreciate your enthusiasm for improving Python
here.
Eli Bendersky, 13.02.2012 12:35:
>> Since there appeared to be an overall positive response for making
>> this change in Python 3.3, and since there isn't longer any doubt
>> about the ownership of the package *in Python's stdlib* (see
>> http://mail.python.org/pipermail/python-dev/2012-February/11
Hi,
My work on the PEP 410 tries to unify the code to manipulate
timestamps. The problem is that I'm unable to decide how to round
these numbers.
Functions using a resolution of 1 second (e.g. time.mktime) expects
rounding towards zero (ROUND_HALF_DOWN), as does int(float). Example:
>>> time.mkt
Revised PEP for new dictionary implementation, PEP 412?
is attached.
Cheers,
Mark.
PEP: XXX
Title: Key-Sharing Dictionary
Version: $Revision$
Last-Modified: $Date$
Author: Mark Shannon
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 08-Feb-2012
Python-Version: 3.3 or 3.4
P
> Since there appeared to be an overall positive response for making
> this change in Python 3.3, and since there isn't longer any doubt
> about the ownership of the package *in Python's stdlib* (see
> http://mail.python.org/pipermail/python-dev/2012-February/116389.html),
> I've opened issue 13988
17 matches
Mail list logo
