pep 3115 (new metaclasses) seems overly complicated imho.
it fails my understanding of "keeping it simple", among other heuristics.
(1)
the trivial fix-up would be to extend the type constructor to take
4 arguments: (name, bases, attrs, order), where 'attrs' is a plain
old dict, and 'order' is a
On 6/9/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Rauli Ruohonen writes:
> > The ones it absolutely prohibits in interchange are surrogates.
>
> Excuse me? Surrogates are code points with a specific interpretation
> if it is "purported that the stream is in UTF-16". Otherwise, Unicode
On 6/9/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > PEP 3127 (Integer Literal Support and Syntax) introduces new notations
> > for octal and binary integers. This isn't implemented yet. Are there
> > any takers? It shouldn't be particularly complicated.
>
> I have a p
Georg Brandl wrote:
> Also, I'm not sure what int() should do with "010".
The only change would be for int(x, 0), and that should raise a
ValueError, just like any other invalid string.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
> On another note, I have no idea how Martin's name (in the Cc line) ended
> up as:
>
> """
> L$(D+S(Bwis"
> """
>
> If I knew, it *might* have a bearing on what sorts of
> canonicalizations should be performed, and what sorts of warnings the
> parser ought to emit for likely corrupted text.
T
Guido van Rossum schrieb:
> PEP 3127 (Integer Literal Support and Syntax) introduces new notations
> for octal and binary integers. This isn't implemented yet. Are there
> any takers? It shouldn't be particularly complicated.
I have a patch lying around here which might be quite complete...
One t
Jim Jewett writes:
> but I think dealing with K characters is now a "least of evils"
> decision, instead of "we need them for something."
Agreed.
> On another note, I have no idea how Martin's name (in the Cc line)
> ended up as: [scrambled stuff]
That's almost surely me. The composer part
