Ron Adam wrote:
> If the string __format__ method got 'k10' as a format specifier, it has
> no idea what the 'k10' is suppose to mean, it needs to make a choice to
> either fall back to str(), or raise an exception that could be caught
> and handled.
I think Guido's scheme handles this okay. Ea
skip> Yes, but an int is both much smaller than a function and can't be
skip> involved in cyclic garbage.
I also forgot to mention that inexperienced users will probably find it
easier to hang onto an int than create a closure
Skip
___
Python-3
Greg Ewing wrote:
> Talin wrote:
>> in
>> the case of an integer that is printed with leading zeros, the sign must
>> come *before* the padding: '+00010'. It's not sufficient to simply
>> apply padding blindly to the output of __format__, which would give you
>> '00+10'.
>
> How about
Greg Ewing wrote:
> Ron Adam wrote:
>> Truncating behavior is
>> explicitly specified by giving a max_width size without a replacement
>> character.
>
> I think that would be an extremely bad default for numbers.
It's *not* a default. The default is to have no max_width.
> > I believe the
Greg Ewing wrote:
> Ron Adam wrote:
>> return value.__format__(format_spec, abstract)
>
> Why would the __format__ method need to be passed an
> 'abstract' flag? It can tell from the format_spec if
> it needs to know.
I may have been thinking too far ahead on this one. I first wrote that
>> Then you need to hang onto the closure. That might be some distance
>> away from the point at which the function was registered.
Greg> Well, if you get a unique ID, you need to hang onto that somehow,
Greg> too.
Yes, but an int is both much smaller than a function and can't b
Talin wrote:
> in
> the case of an integer that is printed with leading zeros, the sign must
> come *before* the padding: '+00010'. It's not sufficient to simply
> apply padding blindly to the output of __format__, which would give you
> '00+10'.
How about this, then: The apply_format
Ron Adam wrote:
> return value.__format__(format_spec, abstract)
Why would the __format__ method need to be passed an
'abstract' flag? It can tell from the format_spec if
it needs to know.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
Ron Adam wrote:
>
> Truncating behavior is
> explicitly specified by giving a max_width size without a replacement
> character.
I think that would be an extremely bad default for numbers.
> I believe they will learn fairly quickly what not to do.
Even if that's true, why make the behaviour t
Talin wrote:
> So 's:10,5' to indicate a max width of 10, min width of 5.
If you just say
':s10'
does this mean there's *no* minimum width, or that the
minimum width is also 10?
The former would be somewhat unintuitive, but if the latter,
then the separation between format and width specifie
[EMAIL PROTECTED] wrote:
> Then you need to hang onto the closure. That might be some distance away
> from the point at which the function was registered.
Well, if you get a unique ID, you need to hang onto that
somehow, too.
--
Greg
___
Python-3000 ma
Guido wrote:
> I remember a language that did the *** thing; it was called Fortran.
> It was an absolutely terrible feature.
I agree that expanding the field width is much to be
preferred if possible. But if you *must* have a maximum
field width, it's better to show no number at all than
a number
On Aug 5, 2007, at 4:49 PM, Martin v. Löwis wrote:
> I don't think it needs to be a separate type,
> instead, bytes objects could have a idem-potent
> .freeze() method which switches the "immutable"
> bit on. There would be no way to switch it off
> again.
+1
-Fred
--
Fred Drake
_
I changed bsddb so that it consistently produces and
consumes bytes only, and added convenience wrappers
StringKeys and StringValues for people whose database
are known to store only strings as either keys or
values; those get UTF-8 encoded.
While I could fix test_bsddb with these changes,
anydbm
> You mean if it were fixed it could fail, right? Code calling it should
> be checking for errors anyway because it allocates memory.
>
> Have you tried making this particular change and seeing what fails?
I now tried, and it turned out that bytes.__reduce__ would break
(again); I fixed it and ch
Talin wrote:
> Ron Adam wrote:
>> Talin wrote:
> Let me define some terms again for the discussion. As noted before, the
> ',' part is called the alignment specifier. It's no longer appropriate
> to use the term 'conversion specifier', since we're not doing
> conversions, so I guess I will st
On 8/5/07, Talin <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
> > To me there is an underlying consistency with grouping abstract/indirect
> > types with more concrete types rather than makeing an exception in the
> > field alignment specifier.
> >
> > Moving repr to the format side sort of breaks
Ron Adam wrote:
> Talin wrote:
>> Another thing I want to point out is that Guido and I (in a private
>> discussion) have resolved our argument about the role of __format__.
>> Well, not so much *agreed* I guess, more like I capitulated.
>
> Refer to the message in this thread where I discuss th
On Sat, Aug 04, 2007 at 04:06:30PM -0500, [EMAIL PROTECTED] wrote:
> I'm looking at the recently submitted patch for the csv module and am
> scratching my head a bit trying to understand the code transformations.
> I've not looked at any py3k code yet, so this is all new to me. Is there
> any docu
>> I agree. We should specify that somewhere, so we have a recorded
>> guideline to use in case of doubt.
>
> But where? Time to start a PEP for the C API perhaps?
I would put it into the API documentation. We can put a daily-generated
version of the documentation online, just as the trunk docume
On 8/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > IMO at the C level all conversions between bytes and Unicode that
> > don't specify a conversion should use UTF-8. That's what most of the
> > changes made so far do.
>
> I agree. We should specify that somewhere, so we have a recorded
> g
> IMO at the C level all conversions between bytes and Unicode that
> don't specify a conversion should use UTF-8. That's what most of the
> changes made so far do.
I agree. We should specify that somewhere, so we have a recorded
guideline to use in case of doubt.
One function that misbehaves und
On 8/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Aside from the name, are there other issues you can think of with any
> > of the API changes? There are some small changes, things like macros
> > only having a function form. Are these a problem?
> >
> > Str/unicode is going to be a big
On 8/4/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> Well, regardless of the brokenness of the patch, I do get two
> different failures from this test on OSX. The first is caused by
> trying to socket.bind() a port that's already been bound recently:
> That looks pretty easy to fix.
It was fix
I can't remember specifics, but i had always expected map and filter
to be replaced by their itertools counter parts.
On 8/4/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> Although there has been quite a bit of discussion on dropping reduce()
> and retaining map(), filter(), and zip(), there has
> Aside from the name, are there other issues you can think of with any
> of the API changes? There are some small changes, things like macros
> only having a function form. Are these a problem?
>
> Str/unicode is going to be a big change. Any thoughts there?
We need some rules on what the cha
Talin wrote:
> Ron Adam wrote:
>
>> Ron Adam wrote:
>>
>>> An alternative I thought of this morning is to reuse the alignment
>>> symbols '^', '+', and '-' and require a minimum width if a maximum
>>> width is specified.
>>
>> One more (or two) additions to this...
>
> (snipped)
>
> I've kin
On 04/08/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> Well, regardless of the brokenness of the patch, I do get two
> different failures from this test on OSX. The first is caused by
> trying to socket.bind() a port that's already been bound recently:
>
> Exception in thread Thread-2:
> Traceba
28 matches
Mail list logo
