I've completed most of the implementation for PEP 3101. The only thing
I have left to do is the Formatter class, which is supposed to live in
the string module.
My plan is to write this part in Python, and put it in Lib/string.py.
Given the complexities and book-keeping involved, writing it in C
Talin wrote:
> Eric V. Smith wrote:
>> I have hooked up the existing PEP 3101 sandbox implementation into the
>> py3k branch as unicode.format(). It implements the earlier PEP syntax
>> for specifiers.
>
> Woo hoo! Thanks Eric. This is great news.
>
> At
Talin wrote:
> One final thing I wanted to mention, which Guido reminded me, is that
> we're getting short on time. This PEP has not yet been officially
> accepted, and the reason is because of the lack of an implementation. I
> don't want to miss the boat. (The boat in this case being Alpha 1.)
Greg Ewing wrote:
> Ron Adam wrote:
>> The only question is weather the 'r'
>> specifier also allows for other options like width and alignment.
>
> I'd say it should have exactly the same options as 's'.
Agreed.
___
Python-3000 mailing list
Python-300
Greg Ewing wrote:
> Eric Smith wrote:
>> 1: "".format() ... understands which
>> types can be converted to other types, and does the conversions.
>>
>> 2: each type's __format__ function understands how to convert to some
>> subset of all types (int can convert to float and decimal, for example).
I'm just getting back from vacation and trying to catch up. I think
I've caught the sense of the discussion, but forgive me if I haven't.
Talin wrote:
> The reason is that for some types, the __format__ method can define its
> own interpretation of the format string which may include the letter
Guido van Rossum wrote:
> I've written up a comprehensive status report on Python 3000. Please read:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
I think this sentence:
"Python 2.6 will contain backported versions of many Py3k features,
either enabled through __future__ statemen
Talin wrote:
> Other kinds of customization require replacing a much larger chunk of
> code. Changing the "underscores" and "check-unused" behavior requires
> overriding 'vformat', which means replacing the entire template string
> parser. I figured that there would be a lot of people who might
> Formatter Creation and Initialization
>
> The Formatter class takes a single initialization argument, 'flags':
>
> Formatter(flags=0)
>
> The 'flags' argument is used to control certain subtle behavioral
> differences in formatting that would be cumbersome to change vi
Talin wrote:
> Some more thoughts on this, and some questions.
>
> PEP 3101 defines two layers of APIs for string formatting: a low-level
> formatting engine, and a high-level set of convenience methods
> (primarily str.format).
>
> Both layers have grown complex due to the desire to satisfy fe
Martin v. Löwis wrote:
...
> Specification of Language Changes
> =
>
> The syntax of identifiers in Python will be based on the Unicode
> standard annex UAX-31 [1]_, with elaboration and changes as defined
> below.
>
> Within the ASCII range (U+0001..U+007F), the v
Jim Jewett wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
>>> There are some things you can safely do with even arbitrary objects --
>>> such as appending them to a list.
>
>>> By mentioning security as a reason to restrict th
Jim Jewett wrote:
> Rationale for Removing Implicit String Concatenation
>
> Implicit String concatentation can lead to confusing, or even
> silent, errors. [1]
>
> def f(arg1, arg2=None): pass
>
> f("abc" "def") # forgot the comma, no warning ...
>
Eric V. Smith wrote:
> Nick Coghlan wrote:
>>> Feature: Exception raised if attribute with leading underscore accessed.
>>>
>>> The syntax supported by the PEP is deliberately limited in an attempt
>>> to increase security. This is an additional security m
Nick Coghlan wrote:
>> Feature: Exception raised if attribute with leading underscore accessed.
>>
>> The syntax supported by the PEP is deliberately limited in an attempt
>> to increase security. This is an additional security measure, which
>> is on by default, but can be optionally disabled if
> If I were designing a formatting system from scratch,
> I think I'd separate the issue of formatting numbers into
> strings from the issue of inserting strings into other
> strings. So instead of
>
>"Answer no. %5d is %8.3f" % (n, x)
>
> you would say something like
>
>subst("Answer no
16 matches
Mail list logo
