we read: "[...] This can create the illusion of non-transitivity between
supported cross-type comparisons and unsupported comparisons. For
example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)."
(The same is in the 3.3 docs).
Python 3.2.3 (default, Sep 10 2012, 18:14:40)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more
>>> import decimal
>>> decimal.Decimal(2) == float(2)
Is it a bug in the docs or in Python itself? (I checked that in 3.2,
but it may be true for 3.3 as well)
On Sat, Sep 29, 2012 at 11:39 AM, Chris Angelico <rosuav(a)gmail.com> wrote:
> On Sun, Sep 30, 2012 at 4:26 AM, Brett Cannon <brett(a)python.org> wrote:
> > Does this mean we want to re-open the discussion about decimal constants?
> > Last time this came up I think we decided that we wanted to wait for
> > cdecimal (which is obviously here) and work out how to handle contexts,
> > syntax, etc.
> Just to throw a crazy idea out: How bad a change would it be to make
> decimal actually the default?
> (Caveat: I've not worked with decimal/cdecimal to any real extent and
> don't know its limitations etc.)
Painful for existing code, unittests and extension modules. Definitely
python-ideas territory (thread moved there with an appropriate subject).
I'm not surprised at all that a decimal type can be "fast" in an
interpreted language due to the already dominant interpreter overhead.
I wish all spreadsheets had used decimals from day one rather than binary
floating point (blame Lotus?). Think of the trouble that would have saved
There's a patch for this bug: http://bugs.python.org/issue12014 that
needs reviewed. Petri Lehtinen made some (very minor) comments back in
May; otherwise it's been neglected. I've brought this up occasionally
here in the past; it would be great if someone could just give it a
thumbs up or down (or say what needs to be changed, or whatever).
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]
Since Python 2.3 many open-like functions supports "Universal line mode"
(PEP 278 ). Since 3.0 (and 2.6) PEP 3116  suggests better
alternative -- io.TextWrapper.
In issue15204  proposed to deprecate "U" mode in open-like functions.
In fact I found only three places where "U" mode is mentioned in the
* builtin open (io.open) (almost ignored);
* fileinput (transparently passed to open);
* zipfile (inefficient and inconsistent implementation).
Is someone uses "U" mode and has objections?
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
>> Last but not least, distlib is the plan forward endorsed by python-dev,
> Is it? I haven't seen a PEP or an official decision about that. Just because
> someone proposed it on a mailing-list doesn't mean it is "endorsed by
We discussed about this with Vinay, Nick and al on python-dev, based on
that describes what 'distlib' is.
The document has changed since then,
But the idea was to create a subset of 4 or 5 modules that implement the
Vinay started to work on this and made progress.
When I said "endorsed", I mean that most of the people in python-dev
that care about packaging agreed or did not disagree.
Now, if you disagree please say it. Or if you need an official decision,
we need to first declare who is the current packaging BDFL maybe ?
And since you seem interested in the topic maybe you could take that role ?
On 26.09.12 16:43, ezio.melotti wrote:
> changeset: 79194:36f61661f71e
> user: Ezio Melotti <ezio.melotti(a)gmail.com>
> date: Wed Sep 26 17:43:23 2012 +0300
> Add a few entries to whatsnew/3.3.rst.
> +A new :data:`~html.entities.html5` dictionary that maps HTML5 named character
> +references to the equivalent Unicode character(s) (e.g. ``html5['gt;'] == '>'``)
> +has been added to the :mod:`html.entities` module. The dictionary is now also
> +used by :class:`~html.parser.HTMLParser`.
Is there a reason why the trailing ';' is included in the entity names?
On Wed, Sep 26, 2012 at 1:23 AM, benjamin.peterson
> If debug_override is not None, then it must be a boolean and is taken as
> - the value of __debug__ instead.
> + the value of bool(sys.flags.optimize) instead.
It may be better to just rephrase this sentence entirely to better
account for the fact that we're now checking the runtime
sys.flags.optimize value rather than the compile time __debug__ value.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I was wondering if it would be worth providing better HTTP 1.1 support
in http.server. The way I envision it, there would be a separate
HTTP11RequestHandler which would provide:
- a smart wfile with automatic chunk encoding (which relieves the API
user from manually handling chunk encoding or content length
- keep-alive enabled by default
- HTTP 1.1 by default (BaseHTTPRequestHandler defaults to 1.0)
What do you think?
Software development and contracting: http://pro.pitrou.net
What's the status of 3.3? Is it going to be released tomorrow?
(I see that we still have a few release-blockers in the tracker,
and the whatsnew section is probably due to be updated by Raymond...)