Apologies if this is a little off-topic for python-dev, but it seemed
like the best place to ask and get the attention of those needed.
I am championing a patch to improve Django's support for numeric types
by using Decimals with numeric columns and floats with double
precision columns, rather tha
On 9/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The goal is to determine whether the setobject.c implementation would be
> improved by recoding the set_lookkey() function to optimize key
> insertion order using Brent's variation of Algorithm D (See Knuth vol.
> III, section 6.4, page 525)
On 9/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> My hypothesis is that there are actually only two use cases that
> matter enough to be supported directly:
>
> (a) quickly print a bunch of items with spaces in between them and a
> trailing newline
>
> (b) print one or more items with p
On 9/6/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> One could use "class decorators". For example if you want to define the
> method foo() in a file-like class, you could use code like:
I like the sound of this. Suppose there were a function textstream()
that decorated a file-like object (su
On 8/31/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Hm. The example is poorly chosen because it's an end case. The
> invariant for both is (I'd hope!)
>
> "".join(s.partition()) == s == "".join(s.rpartition())
> (Just think of it as rpartition() stopping at the last occurrence,
> ra
On 8/31/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Andrew Durdin wrote:
>
> > Just to put my spoke in the wheel, I find the difference in the
> > ordering of return values for partition() and rpartition() confusing:
> >
> > head, sep, remainder = p
On 8/31/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Hye-Shik Chang]
> > What would be a result for rpartition(s, '?') ?
> > ('', '', 'http://www.python.org')
> > or
> > ('http://www.python.org', '', '')
>
> The former. The invariants for rpartition() are a mirror image of those
> for part
On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> You are wrong. Current string literals are explicit. They are what you
> type.
No they are not:
>>> "I typed \x41, but got this!"
'I typed A, but got this!'
What we have are not explicit string literals but *explicit rules*,
for
On 7/7/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> I believe there were some current alternatives and concerns already
> expressed that have not been included yet that maybe should be.
Yes; Nick pointed me to one, and I'll be looking at that and the
related discussions before redrafting; I'll
On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*] -- although the rules are
different to the current beha
On 7/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> However, while I prefer what you describe to Python's current
> behaviour, I am not yet convinced the backward compatibility pain is
> worth it. Adding yet-another-kind-of-string-literal (when we already
> have bytestrings on the horizon) is a
Here's the draft PEP I wrote up:
Abstract
Triple-quoted string (TQS henceforth) literals in Python preserve
the formatting of the literal string including newlines and
whitespace. When a programmer desires no leading whitespace for
the lines in a TQS, he must align all lines bu
On 7/6/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> Doc strings, first meant for the code reader, need to be where they are.
> They also come before the code itself, so don't interfere.
Doc strings are really not an issue, due to the conventions for
processing whitespace in them (and also the f
In general, I find triple-quoted strings to be very handy,
particularly for standalone scripts. However, the fact that they have
to be written in the left-hand column to avoid leading whitespace
really grates, particularly when they're nested within a block or two
-- it's a wart:
try:
On 6/28/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> AFAICT, the only unresolved issue outstanding is a compromise or
> Pronouncement regarding the atime/ctime/mtime members' datatype. This is
> assuming, of course, that making the "empty path" be os.curdir doesn't
> receive any objections,
15 matches
Mail list logo
