Guido van Rossum wrote:
> My personal suggestion is to stay close to the .NET formatting language:
>
> name_specifier [',' width_specifier] [':' conversion_specifier]
>
> where width_specifier is a positive or negative number giving the
> minimum width (negative for left-alignment) and conversi
On 8/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > Since there is a merged int/long type now, we need to decide how the C
> > API should look. For example, should the APIs be prefixed with
> > PyInt_* or PyLong_?
>
> I've always assumed it would be Py_Int*. If any
> integer
Neal Norwitz wrote:
> Since there is a merged int/long type now, we need to decide how the C
> API should look. For example, should the APIs be prefixed with
> PyInt_* or PyLong_?
I've always assumed it would be Py_Int*. If any
integer can be any length, it doesn't make sense
to have any length-r
Since there is a merged int/long type now, we need to decide how the C
API should look. For example, should the APIs be prefixed with
PyInt_* or PyLong_? What are the other issues? What do people want
for the C API in 3k?
n
___
Python-3000 mailing lis
__members__ and __methods__ are both deprecated as of 2.2 and there is
the new __dir__. Is there any reason to keep them? I don't notice
anything in PEP 3100, but it seems like they should be removed.
Also PyMember_[GS]et are documented as obsolete and I plan to remove
them unless I hear otherwi
On 8/2/07, Brandon Craig Rhodes <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> writes:
>
> > My personal suggestion is to stay close to the .NET formatting language:
> >
> > name_specifier [',' width_specifier] [':' conversion_specifier]
>
> A problem is that this format requ
On 8/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > In order to support the use cases for %s and %r, I propose to allow
> > appending a single letter 's', 'r' or 'f' to the width_specifier
> > (*not* the conversion_specifier):
> >
> > 'r' always calls repr() on the objec
On 8/2/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> |def __bool__(self):
> |"""True if self != 0."""
> |return self != 0
>
> Could this be a Number rather than Complex method?
Yes, a
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> My personal suggestion is to stay close to the .NET formatting language:
>
> name_specifier [',' width_specifier] [':' conversion_specifier]
A problem is that this format requires brute memorization to remember
where to put things. If letters we
Guido van Rossum wrote:
> In order to support the use cases for %s and %r, I propose to allow
> appending a single letter 's', 'r' or 'f' to the width_specifier
> (*not* the conversion_specifier):
>
> 'r' always calls repr() on the object;
> 's' always calls str() on the object;
> 'f' calls the
Nicko van Someren wrote:
> 1000
> 200
> (3000)
>40
>(5)
> I.e. with the bulk of the padding applied before the number but
> conditional padding after the number if there is no closing bracket.
I think it should be the responsibility of the forma
Terry,
I liked these ideas so much I removed both "integer" and "float" from
the HTTP-NG type system. See
http://www.parc.com/janssen/pubs/http-next-generation-architecture.html,
section 4.5.1. Though if I was doing it again, I'd go further, and
make all fixed-point, floating-point, and string t
On 8/2/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Floats constitute a bit-size bounded (like ints) set of rationals with
> denominators restricted to powers of two. Decimal literals and Decimals
> constitute a memory bounded (like longs) set of rationals with denominators
> instead restricted to
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| In short, having read up to the beginning of Exact vs. Inexact Classes,
my
| suggestion is to delete the unrealizable 'real' class
Less than a minute after hitting Send, I realized that one could base a
(restricted) c
"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|def __bool__(self):
|"""True if self != 0."""
|return self != 0
Could this be a Number rather than Complex method?
---
| There is no built-in rational type
Floats constitu
On 8/2/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > The patch is based on the latest trunk/ checkout, Python 2.6. I don't
> > think this is a problem if nobody else made any effort towards making
> > xrange more sequence-like in the Python 3000 branch. The C source might
> > require some ta
Guido van Rossum wrote:
> Personally I think support for the various accounting-style output is
> not worth it. I betcha any accounting system worth the name would not
> use this and instead have its own custom code for formatting anyway.
>
> My personal suggestion is to stay close to the .NET fo
On 8/2/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> > My personal suggestion is to stay close to the .NET formatting language
>
> If Microsoft formatting ideas are going to be used, why not use the
> Excel language? In my mind it's not any worse than any other string of
> characters with special m
> The patch is based on the latest trunk/ checkout, Python 2.6. I don't
> think this is a problem if nobody else made any effort towards making
> xrange more sequence-like in the Python 3000 branch. The C source might
> require some tab/space cleanup.
Unfortunately, this is exactly what happene
Talin wrote:
> The first change is to divide the conversion specifiers into two parts,
> which we will call "alignment specifiers" and "format specifiers". So
> the new syntax for a format field will be:
>
> valueSpec [,alignmentSpec] [:formatSpec]
>
> In other words, alignmentSpec is intr
Personally I think support for the various accounting-style output is
not worth it. I betcha any accounting system worth the name would not
use this and instead have its own custom code for formatting anyway.
My personal suggestion is to stay close to the .NET formatting language:
name_specifie
On 2 Aug 2007, at 03:01, Talin wrote:
> In general, you can think of the difference between format
> specifier and
> alignment specifier as:
>
> Format Specifier: Controls how the value is converted to a
> string.
> Alignment Specifier: Controls how the string is placed on the
> lin
On 8/2/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:46 AM 8/2/2007 -0700, Guido van Rossum wrote:
> >On 8/1/07, Talin <[EMAIL PROTECTED]> wrote:
> > > I think that in order to 'mix' metaclasses, each metaclass needs to get
> > > a crack at the members as they are defined. The 'dict' object
At 07:46 AM 8/2/2007 -0700, Guido van Rossum wrote:
>On 8/1/07, Talin <[EMAIL PROTECTED]> wrote:
> > I think that in order to 'mix' metaclasses, each metaclass needs to get
> > a crack at the members as they are defined. The 'dict' object really
> > isn't important - what's important is to be able
On Thu, 02 Aug 2007 15:03:42 +, Stargaming wrote:
> On Sat, 28 Jul 2007 17:06:50 +0200, tomer filiba wrote:
>
>> currently, testing for "x in xrange(y)" is an O(n) operation.
>>
>> since xrange objects (which would become range in py3k) are not real
>> lists, there's no reason that __contain
On Sat, 28 Jul 2007 17:06:50 +0200, tomer filiba wrote:
> currently, testing for "x in xrange(y)" is an O(n) operation.
>
> since xrange objects (which would become range in py3k) are not real
> lists, there's no reason that __contains__ be an O(n). it can easily be
> made into an O(1) operation.
On 8/1/07, Talin <[EMAIL PROTECTED]> wrote:
> I think that in order to 'mix' metaclasses, each metaclass needs to get
> a crack at the members as they are defined. The 'dict' object really
> isn't important - what's important is to be able to overload the
> creation of a class member.
>
> I can thi
Talin wrote:
> Ron Adam wrote:
>
>> Splits the item and it's formatter. The alignment is more of a
>> container property or feild property as you pointed out further down.
>>
>> So maybe if you group the related values together...
>>
>> {valuespec:format, alignment:width}
>>
>> This has a
28 matches
Mail list logo
