Adam Olsen wrote:
> My proposal was to flip this logic: __format__ should check for its
> own specifiers first, and only if it doesn't match will it return
> NotImplemented (triggering a call to __int__, or maybe __index__).
>
> class MyInt:
> def __format__(self, spec):
> if is_custom
On 8/12/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Eric V. Smith wrote:
> > Right. Your "if" test is my is_float_specifier function. The problem
> > is that this needs to be shared between int and float and string, and
> > anything else (maybe decimal?) that can be converted to a float. Maybe
>
Eric V. Smith wrote:
> Right. Your "if" test is my is_float_specifier function. The problem
> is that this needs to be shared between int and float and string, and
> anything else (maybe decimal?) that can be converted to a float. Maybe
> we should make is_float_specifier a classmethod of flo
On 8/12/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> On Thursday 09 August 2007 19:39:50 you wrote:
> > So why not just skip caching for anything that doesn't hash()? If
> > you're really worried about efficiency, simply re.compile() the
> > expression once and don't rely on the re module's int
James Y Knight wrote:
> I've been skimming a lot of the discussion about how to special case
> various bits and pieces of formatting, but it really seems to me as
> if this is really just asking for the use of a generic function. I'm
> not sure how exactly one spells the requirement that the
On Thursday 09 August 2007 19:39:50 you wrote:
> So why not just skip caching for anything that doesn't hash()? If
> you're really worried about efficiency, simply re.compile() the
> expression once and don't rely on the re module's internal cache.
I tried to keep backward compatibility.
Why cha
On Sunday 12 August 2007 16:50:05 Barry Warsaw wrote:
> In r56957 I committed changes to sndhdr.py and imghdr.py so that they
> compare what they read out of the files against proper byte
> literals.
So nobody read my patches? :-( See my emails "[Python-3000] Fix imghdr module
for bytes" and "[Py
Talin wrote:
> Taking some ideas from the various threads, here's what I'd like to propose:
>
> (Assume that brackets [] means 'optional field')
>
>[:[type][align][sign][[0]minwidth][.precision]][/fill][!r]
>
> Examples:
>
> :f# Floating point number of natural width
> :f10
On Sunday 12 August 2007 19:11:18 Bill Janssen wrote:
> Why not just write
>
>b'xyz'[0:1] == b'x'
It's just strange to write:
'abc'[0] == 'a'
for character string and:
b'abc'[0:1] == b'a'
for byte string.
The problem in my brain is that str is a special case since a str item is also
a
Martin v. Löwis wrote:
> However, if string.letters is removed, I trust that people
> start listing all characters explicitly in the regex, and curse
> python-dev for removing such a useful facility.
On the other hand, if it's kept, but turns into something
tens of kilobytes long, what effect will
Paul Moore wrote:
> Ugh. Alternatively, h[0] == ord('P') should work.
I'm wondering whether we want a "byte character literal"
to go along with "byte string literals":
h[0] == c"P"
After all, if it makes sense to write an array of bytes
as though they were ASCII characters, it must make sense
Paul Moore wrote:
> and you set the newline argument to specify a *specific*,
> non-universal, newline value
It still seems wrong to not translate the newlines, though,
since it's still a *text* mode, and the standard Python
representation of text has \n line endings.
--
Greg
James Y Knight wrote:
> I've been skimming a lot of the discussion about how to special case
> various bits and pieces of formatting, but it really seems to me as
> if this is really just asking for the use of a generic function.
I was afraid someone would suggest that. I think it
would be a b
Georg Brandl wrote:
> Hm... I have a feeling that this will be one of the first entries in a
> hypothetical "Python 3.0 Gotchas" list.
And probably it's exacerbated by calling them byte
"strings", when they're really a kind of array rather
than a kind of string, and the use of b"..." as a
construc
Talin wrote:
> :s10 # String right-aligned within field of minimum width
> # of 10 chars.
I'm wondering whether the default alignment for
strings should be left instead of right. The C
way is all very consistent and all, but it's not
a very practical default. How often do yo
> Is the code which sets IOBinding.encoding still correct? That value is
> used in several places in IDLE, including setting the encoding for
> std{in,err,out}.
I think so, yes. The conditions in which it needs to be used will have
to change, though: Python 3 defaults to UTF-8 as the source encod
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> Hopefully MvL has a few minutes to revisit the IOBinding.py code which is
>> setting IDLE's encoding. I'm not sure how it should be configured.
>
> This code was now bogus. In 2.x, the line read
>
> s = unicode(s, IOBinding.encoding)
>
> Then
>> Exactly my feelings. Still, people seem to like string.letters a lot,
>> and I'm unsure as to why that is.
>
> I think because it feels like the most direct, least obscured
> approach. Calling ord() feels like a hack, re is overkill and
> maligned for many reasons, and c.isalpha() would behave
On 8/12/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 11/08/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Try h[0:1] == b'P'. Slicing will ensure it stays as a bytes object,
> > rather than just giving the integer it contains.
>
> Ugh. Alternatively, h[0] == ord('P') should work.
>
> Unless you'r
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 some point I'd like to build that branc
On 8/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Wasn't unicodedata.ascii_letters suggested at one point (to eliminate
> > the string module), or was that my imagination?
>
> Not sure - I don't recall such a proposal.
>
> > IMO, if there is a need for unicode or locale letters, we shoul
On 11/08/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Try h[0:1] == b'P'. Slicing will ensure it stays as a bytes object,
> rather than just giving the integer it contains.
Ugh. Alternatively, h[0] == ord('P') should work.
Unless you're writing source in EBCDIC (is that allowed?).
All of the alt
On 12/08/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Note that Python does nothing special in the above case. For non-Windows
> platforms, you'd get two different results -- the conversion from \r\n to
> \n is done by the Windows C runtime since the default open() mode is text
> mode.
>
> Only w
I've been skimming a lot of the discussion about how to special case
various bits and pieces of formatting, but it really seems to me as
if this is really just asking for the use of a generic function. I'm
not sure how exactly one spells the requirement that the first
argument be equal to a
Bill Janssen schrieb:
>> I don't like the behaviour of Python 3000 when we compare a bytes strings
>> with length=1:
>>>>> b'xyz'[0] == b'x'
>>False
>>
>> The code can be see as:
>>>>> ord(b'x') == b'x'
>>False
>>
>> or also:
>>>>> 120 == b'x'
>>False
>>
>> Two solutions:
> Wasn't unicodedata.ascii_letters suggested at one point (to eliminate
> the string module), or was that my imagination?
Not sure - I don't recall such a proposal.
> IMO, if there is a need for unicode or locale letters, we should
> provide a function to generate them as needed. It can be passe
> I don't like the behaviour of Python 3000 when we compare a bytes strings
> with length=1:
>>>> b'xyz'[0] == b'x'
>False
>
> The code can be see as:
>>>> ord(b'x') == b'x'
>False
>
> or also:
>>>> 120 == b'x'
>False
>
> Two solutions:
> 1. b'xyz'[0] returns a new bytes
> base64MIME.decode() and base64MIME.encode() should accept bytes and str
> base64MIME.decode() result type is bytes
> base64MIME.encode() result type should be... bytes or str, no idea
>
> Other decode() and encode() functions should use same rules about types.
Victor,
Here's my take on this
Eric V. Smith wrote:
> 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 i
On 11/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > Is this ok: when newline='\r\n' or newline='\r' is passed, only that
> > string is used to determine
> > the end of lines. No translation to '\n' is done.
>
> I *think* it would be more
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.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 10, 2007, at 6:49 PM, Victor Stinner wrote:
> It's really hard to convert email module to Python 3000 because it
> does mix
> byte strings and (unicode) character strings...
Indeed, but I'm making progress.
Just a very quick follow up now,
Hi everyone,
I apologize for my quietness on this list (I'm actually in the middle of
a move), but I recently implemented most of PEP 3118 in the py3k-buffer
branch (it's implemented but not tested...)
However, I'm running into trouble getting it to link. The compilation
step proceeds fine
> s = str(s, IOBinding.encoding)
> TypeError: decoding Unicode is not supported
>
> Hopefully MvL has a few minutes to revisit the IOBinding.py code which is
> setting IDLE's encoding. I'm not sure how it should be configured.
This code was now bogus. In 2.x, the line read
s = unicode
34 matches
Mail list logo
