Darn right it should return False. Given the principle of least surprise
(and my prejudices built up over 40 years as a computer programmer) I would
expect that decimal.Decimal data would be stored internally as some form of
decimal data, and would store into a database as such. It would be
expected to be in a fixed point format. Real, on the other hand, I would
expect to be stored as an IEEE double precision floating point number, or
something like that.
I don't care whether a fixed point decimal number might be defined by a
mathematician as "real" -- I care whether it can be processed by an FPU,
and whether it will loose precision in large financial calculations.
I came across the following today:
Python 3.3.0 (default, Sep 29 2012, 17:14:58)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numbers
>>> import decimal
>>> d = decimal.Decimal()
>>> isinstance(d, numbers.Number)
>>> isinstance(d, numbers.Complex)
>>> isinstance(d, numbers.Real)
>>> isinstance(d, numbers.Rational)
>>> isinstance(d, numbers.Integral)
That seems plainly absurd to me. Decimals are quite clearly real
numbers. I then found the following in PEP-3141 :
The Decimal Type
After consultation with its authors it has been decided that the
Decimal type should not at this time be made part of the numeric
What was the rationale for this decision and does it still apply?
What do you think about an optional `keepsep` argument in str.split(),
in order to keep the separator?
Something like the `keepends` of str.splitlines():
>>> 'I am\ngoing\nto...'.splitlines(keepends=True)
['I am\n', 'going\n', 'to...']
>>> 'python3'.split('n', keepsep=True)
INAF Osservatorio Astronomico di Cagliari
Loc. Poggio dei Pini, Strada 54 - 09012 Capoterra (CA) - Italy
Phone: +39 070 71180255
Recently I've repeatedly needed to check whether a particular sequence
occurred as a "subsequence" of another. I think this could be a general
requirement, so I'd like to ask if anyone else agrees. In python code, I
have the following, although I can rewrite it in C if people on this list
like it enough to add it to core:
def index_subseq(self, subseq):
'''slice over which subseq is a sub-sequence of sequence self'''
i = -1
i = self.index(subseq, i + 1)
if all((a == b) for a, b in zip(subseq, itertools.chain(self[i:],
return slice(i, i + len(subseq))
(0, 1, 2, 3, 4, 5, 6, 7, 8).index_subseq((3,4,5))) # slice(3, 6, None)
[0, 1, 2, 3, 4, 5, 6, 7, 8].index_subseq((3,4,5)))
(0, 1, 2, 3, 4).index_subseq((3,4,5))) # ValueError
[0, 1, 2, 3, 4].index_subseq((3,4,5)))
[This listing omits the monkeypatching into the list and tuple builtins.]
The index() method of more specialized sequences like str and bytearray
already has behavior much like what I propose for this method, since it
doesn't have to worry about elements of those sequences having elements in
turn. This method returns a slice object: I considered but decided against
returning just the initial index of the slice. As I've written it here, the
method doesn't care whether it is passed a list or a tuple as the "subseq"
argument. This could be generalized to take any iterable. If anyone has a
suggestion for a better name than "index_subseq", that would be good too.
If people think this is a good idea, I'll post a patch in the tracker.
Hello, it would be nice if reference pure Python implementation existed for
more parts of interpreter core and the core actually used them. This was
done for import machinery in Python 3.3 making importlib library.
One potential target for this would be moving the logic of what python.exe
does – parsing its arguments, finding the script to run, compiling its code
and running as __main__ module, running REPL if it's in interactive mode
afterwards. There could be a stdlib module exposing this logic, using
argparse to parse the arguments, overhauled version of runpy to run the
__main__ module and overhauled version of code to run the REPL. Python.exe
would be just thin wrapper which bootstraps the interpreter and runs this
What brought me to this idea. I just wanted to use unicode in REPL on
Windows. It doesn't work because sys.stdin.buffer.raw.read just doesn't
read unicode characters on Windows, similar for
sys.stdout.buffer.raw.write. See http://bugs.python.org/issue1602 . There
is a workaround, one can write custom sys.stdin and sys.stdout objects
which use winapi functions ReadConsoleW and WriteConsoleW called via
ctypes. Setting these objects seems to solve the problem – input() and
print() work during execution of a script. There is however problem in
interactive mode since Python REPL actually doesn't use sys.stdin for
input. It takes input from real STDIN, but it uses encoding of sys.stdin,
which doesn't seem to make sense, see http://bugs.python.org/issue17620 .
So I have written my own REPL based on stdlib module 'code', but I needed
some hook which runs it just after the execution of a script and before
standard REPL starts. There is just PYTHONSTARTUP environment variable
which works only for bare Python console, not running any script. So I
needed a script run.py such that "py <options> run.py [<somescript>
[<args>]]" did almost the same thing as "py <options> [<somescript>
[<args>]]". It would run my REPL at the right time.
Writing things like run.py is difficult since there are many details one
should handle so the inner script being run behaves the same way as if it
was run directly. It is also difficult to test it (e.g.
http://bugs.python.org/issue18838). It would be easy if there where
reference implementation how Python itself does it. The script like run.py
has more use cases, for example Ned Batchelder's coverage.py implements its
Generally if more parts of interpreter core were exposed via stdlib, issues
like the ones mentioned could be handled more easily. Another example:
there are some issues when one hits Ctrl-C on input on Windows, it seems
that one should detect the condition and wait for signal to arrive (see
http://bugs.python.org/issue18597 , http://bugs.python.org/issue17619 ). I
thought that input() is just a thin wrapper around sys.stdin.readline() so
it could be easily implemented in pure Python (there was even idea that
input() won't be in Python 3000). So it surprises me that input() is
implemented in very different way and provides alternative codepath to
low-level reading function that the codepath sys.stdin -> sys.stdin.buffer
-> sys.stdin.buffer.raw. If there was only one path, it would be easier to
fix issues like that.
Thank you for response, Drekin.
Why do I have to do this:
for thing in things:
When I could do this:
Aside from being much more concise, it could be more efficient too,
I believe that the all() and any() library functions should be modified to
accept multiple arguments as well as single iterators.
Currently, code such as this (taken from a sublime text plugin), breaks:
self.mode is 'client'
Meaning either that one must write either this, and use parenthesis to
avoid some obscure order of operations error:
(not self.broadcasting) and
(self.mode is 'client')
Or this, and have others wonder at the odd double parenthesis or list:
self.mode is 'client'
I can't foresee any compatibility issues for this modification, as it would
only make currently broken code work, not the other way around.
I searched the mailing list archives with Google to see if there were any
past discussions on this topic, however the ambiguousness my search terms
('all', 'any' 'multiple, 'arguments') meant that the results were too
numerous for me to sort through ( I gave up after the first 3 pages).
"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it. " - Terry Pratchett
Ok, I wasn't very clear in my first one, so I'm going to try this again.
My idea is to put Clang as a compiler for building Python extensions on Windows. i.e. I would be able to do this:
C:\my-python-extension> python setup.py build -c clang
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On 25/08/13 19:46, Musical Notation wrote:
> This is not a proposal to remove significant indentation, this is to complement it. You can declare "from __future__ import braces" to use it.
Try that at the interactive interpreter, you may be surprised.
What about this?
lambda x, y: a = sum(x)/len(x); b = sum(y)/len(y); (a+b)/2;;
The double-semicolon notation can also replace indentation for grouping of statements:
for x in list: