>>> What if you've got a PNG as one of the multipart components? With a
>>> Content-Transfer-Encoding of "binary"? There's no way to represent that
>>> as a string.
>> Sure is. Any byte sequence can be interpreted as latin-1.
>
> Last time I looked, Latin-1 didn't cover the octets 0x80 - 0x9F.
On 8/17/07, Talin <[EMAIL PROTECTED]> wrote:
> I wonder how hard it would be - and how much it would distort the Python
> code base - if most if not all platform-specific differences could be
> externalized from the core Python source code. Ideally, a platform
> wishing to support Python shouldn't
Martin v. Löwis wrote:
>> Martin> It took some effort to integrate this for 2.3, so I feel sad
>> Martin> that this is now all ripped out again. I'm not certain the code
>> Martin> gets cleaner that way - just smaller.
>>
>> Well, fewer #ifdefs can't be a bad thing.
>
> By that princip
Wow, excellent feedback. I've added your email to the list of reminders
for the next round of edits.
Jim Jewett wrote:
> The PEP says:
>
> The general form of a standard format specifier is:
>
> [[fill]align][sign][width][.precision][type]
>
> but then says:
>
> A zero fill char
Alexandre Vassalotti writes:
> Perhaps, it would be a good idea to take Plan9's approach to
> portability -- i.e., you develop an extreme allergy to code filled
> with #if, #ifdef, #else, #elseif; localize system dependencies in
> separate files and hide them behind interfaces.
If I understan
Martin v. Löwis wrote:
> I now agree with Bill that we have a "computation of matching braces
> problem", surprisingly: people disagree with each other and with the
> PEP what the meaning of the braces in above example is.
I think it should be considered an error to use
a name which is not a valid
It is fantastic! Totally super work. I just have one small request;
pretty please do not set the font. I'm very happy with my browsers
default (Verdana), and Bitstream Vera Sans renders badly for me.
--
mvh Björn
___
Python-3000 mailing list
Python-3000
> > What if you've got a PNG as one of the multipart components? With a
> > Content-Transfer-Encoding of "binary"? There's no way to represent that
> > as a string.
>
> Sure is. Any byte sequence can be interpreted as latin-1.
Last time I looked, Latin-1 didn't cover the octets 0x80 - 0x9F.
May
> On 8/17/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > Ideally, the package would be well suited not only for wire-to-wire
> > > and all-internal uses, but also related domains like HTTP and other
> > > RFC 2822-like contexts.
> >
> > But that's exactly why the internal representation should b
Alexandre Vassalotti wrote:
> On 8/17/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
[...]
> Ah, I didn't notice that index included all the documents. That
> explains the huge size increase. However, would it be possible to keep
> the indexes separated? I noticed that I find I want more quickly when
On 8/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Perhaps, it would be a good idea to take Plan9's approach to
> > portability -- i.e., you develop an extreme allergy to code filled
> > with #if, #ifdef, #else, #elseif; localize system dependencies in
> > separate files and hide them beh
> What if you've got a PNG as one of the multipart components? With a
> Content-Transfer-Encoding of "binary"? There's no way to represent that
> as a string.
Sure is. Any byte sequence can be interpreted as latin-1.
Not that I think this would be a good thing to do.
> I wonder if we're misund
> Perhaps, it would be a good idea to take Plan9's approach to
> portability -- i.e., you develop an extreme allergy to code filled
> with #if, #ifdef, #else, #elseif; localize system dependencies in
> separate files and hide them behind interfaces.
>
> By the way, there is a great chapter about p
On 8/17/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Ideally, the package would be well suited not only for wire-to-wire
> > and all-internal uses, but also related domains like HTTP and other
> > RFC 2822-like contexts.
>
> But that's exactly why the internal representation should be bytes,
> n
On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett> On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> I just got rid of BeOS and RiscOS.
>
> Brett> Just so you know, Skip, BeOS still has a maintainer on the 2.x
> Brett> branch. Whether we want to continu
Eric Smith wrote:
> Ron Adam wrote:
>>
>> Martin v. Lo"wis wrote:
>>> Bill Janssen schrieb:
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message tran
On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> >> I'm refactoring the sandbox implementation, and I need to add the code
> >> that parses the standard format specifiers to py3k. Since strings,
> >> ints, and float
> Ideally, the package would be well suited not only for wire-to-wire
> and all-internal uses, but also related domains like HTTP and other
> RFC 2822-like contexts.
But that's exactly why the internal representation should be bytes,
not strings. HTTP's use of MIME, for instance, uses "binary" qu
[disclaimer: I am a clueless newbie in the portability area.]
On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Martin> It took some effort to integrate this for 2.3, so I feel sad
> Martin> that this is now all ripped out again. I'm not certain the code
> Martin> gets clean
Brett> On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I just got rid of BeOS and RiscOS.
Brett> Just so you know, Skip, BeOS still has a maintainer on the 2.x
Brett> branch. Whether we want to continue support past 2.x is another
Brett> question (as Guido says in
Guido van Rossum wrote:
> On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> I'm refactoring the sandbox implementation, and I need to add the code
>> that parses the standard format specifiers to py3k. Since strings,
>> ints, and floats share same format specifiers, I want to have only a
>> sin
On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> I'm refactoring the sandbox implementation, and I need to add the code
> that parses the standard format specifiers to py3k. Since strings,
> ints, and floats share same format specifiers, I want to have only a
> single parser.
Really? Strings s
On 8/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I just got rid of BeOS and RiscOS.
Just so you know, Skip, BeOS still has a maintainer on the 2.x branch.
Whether we want to continue support past 2.x is another question (as
Guido says in another email, it's a hassle and so we should try
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 17, 2007, at 1:22 PM, Martin v. Löwis wrote:
> A library implementing that in Python should certainly use bytes
> at the network (stream) side, and strings at the application side.
> Even though the format is human-readable, the protocol is byt
I'm refactoring the sandbox implementation, and I need to add the code
that parses the standard format specifiers to py3k. Since strings,
ints, and floats share same format specifiers, I want to have only a
single parser.
My first question is: where should this parser code live? Should I
cr
On 8/17/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> I didn't read the PEP nor all email discussions. So can you tell me if it
> would be possible to write simply:
>"{} {}".format('Hello', 'World')
If you really want to write this, I suggest adding the following
helper function to your code
> Martin> It took some effort to integrate this for 2.3, so I feel sad
> Martin> that this is now all ripped out again. I'm not certain the code
> Martin> gets cleaner that way - just smaller.
>
> Well, fewer #ifdefs can't be a bad thing.
By that principle, it would be best if Python
The PEP says:
The general form of a standard format specifier is:
[[fill]align][sign][width][.precision][type]
but then says:
A zero fill character without an alignment flag
implies an alignment type of '='.
In the above form, how can you get a fill character without an
align
> The odd thing here is that RFC 2047 (MIME) seems to be about encoding
> non-ASCII character sets in ASCII. So the spec is kind of odd here.
> The actual bytes on the wire seem to be ASCII, but they may an
> interpretation where those ASCII bytes represent a non-ASCII string.
HTTP is fairly conf
Martin> It took some effort to integrate this for 2.3, so I feel sad
Martin> that this is now all ripped out again. I'm not certain the code
Martin> gets cleaner that way - just smaller.
Well, fewer #ifdefs can't be a bad thing.
I noticed this on the Syllable Wikipedia page:
It
On 8/17/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> But for me it looks to be more complex: we have to maintain indexes (0, 1,
> 2, ...), marker is different ({0} != {1}), etc.
> ... tell me if it would be possible to write simply:
>"{} {}".format('Hello', 'World')
It would be possible to
Guido van Rossum wrote:
> On 8/16/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Martin v. Löwis wrote:
>>
A simple merge won't work, because in 3.0 the codec uses bytes and in
2.6 it uses str. Also the call to the decoding error handler has
changed, because in 3.0 the error handle
On 8/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > I'd get in touch with the last known maintainer of the AtheOS port, or
> > some of the Syllabe maintainers (if all else fails, spam their wiki's
> > front page :-). If it's just a renaming maybe they're relying
Guido van Rossum schrieb:
> I'd get in touch with the last known maintainer of the AtheOS port, or
> some of the Syllabe maintainers (if all else fails, spam their wiki's
> front page :-). If it's just a renaming maybe they're relying on the
> same #ifdefs still.
The port was originally contribute
On 8/17/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti schrieb:
> > On 8/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> >> On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> > Okay, I made the switch. I tagged the state of both Python branches
> >> > before the switch a
>> On second thought, that won't work. For example, this currently
>> doesn't work:
>> '{0[{foo}{bar}]}'.format({'FOOBAR': 'abc'}, foo='FOO', bar='BAR')
>> KeyError: 'FOO'
>>
>> I can't decide if that's a bug or not.
>
> I think it will be a bug. Some one is bound to run into it at some
> point
Victor Stinner wrote:
> Hi,
>
> I read many people saying that
>"{0} {1}".format('Hello', 'World')
> is easiert to read than
>"%s %s" % ('Hello', 'World')
>
Not me.
>
> But for me it looks to be more complex: we have to maintain indexes (0, 1,
> 2, ...), marker is different ({0} != {1})
I think you should just disallow {...} for the start of the variable
reference. I.e. {0.{1}} is okay, but {{1}} is not.
On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
> >
> > Martin v. Lo"wis wrote:
> >> Bill Janssen schrieb:
> I think most of these points are irrelevant.
Eric Smith wrote:
> Ron Adam wrote:
>>
>> Martin v. Lo"wis wrote:
>>> Bill Janssen schrieb:
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message tran
I'd get in touch with the last known maintainer of the AtheOS port, or
some of the Syllabe maintainers (if all else fails, spam their wiki's
front page :-). If it's just a renaming maybe they're relying on the
same #ifdefs still.
Thanks for doing this BTW! I love cleanups.
(If there are other peo
Georg Brandl wrote:
>> Firefox, on my fairly recent machine, takes ~5 seconds rendering the
>> index of the new docs from disk, compared to a fraction of a second
>> for the old one.
>
> But you're right that rendering is slow there. It may be caused by the
> more complicated CSS... perhaps the i
Guido van Rossum wrote:
> There's still one leak that Neal would like to see fixed, in
> test_zipimport. Instructions to reproduce: in a *debug* build, run
> this command:
>
> ./python Lib/test/regrtest.py -R1:1: test_zipimport
>
> This reports 29 leaked references.
>
I found the problem in M
Guido van Rossum wrote:
> There's still one leak that Neal would like to see fixed, in
> test_zipimport. Instructions to reproduce: in a *debug* build, run
> this command:
>
> ./python Lib/test/regrtest.py -R1:1: test_zipimport
>
> This reports 29 leaked references.
>
Err, this patch is using
I just got rid of BeOS and RiscOS. I'm about to launch into Irix and Tru64,
the other two listed on
http://wiki.python.org/moin/Py3kDeprecated
I wonder, should AtheOS support be removed as well? According to Wikipedia
it's no longer being developed, having been superceded by something calle
Ron Adam wrote:
>
> Martin v. Lo"wis wrote:
>> Bill Janssen schrieb:
I think most of these points are irrelevant. The curly braces are not
just syntactic sugar, at least the opening brace is not; the digit
is not syntactic sugar in the case of message translations.
>>> Are there "co
Hi,
I read many people saying that
"{0} {1}".format('Hello', 'World')
is easiert to read than
"%s %s" % ('Hello', 'World')
But for me it looks to be more complex: we have to maintain indexes (0, 1,
2, ...), marker is different ({0} != {1}), etc.
I didn't read the PEP nor all email discu
Guido van Rossum wrote:
> I see two new tests failing tonight:
>
> - test_xmlrpc fails on all platforms I have. This is due to several
> new tests that were merged in from the trunk; presumably those tests
> need changes due to str vs. bytes.
>
> - test_codecs fails on OSX PPC only. This is in t
47 matches
Mail list logo
