On 14Jan2014 20:23, Antoine Pitrou wrote:
> On Tue, 14 Jan 2014 10:52:05 -0800
> Guido van Rossum wrote:
> > Quite a few people have spoken out in favor of loud
> > failures rather than silent "wrong" output. But I think that in the
> > specific context of formatting output, there is a long and I
On 01/14/2014 10:58 PM, Stephen J. Turnbull wrote:
At the very least, the "iterated interpolation is a bad idea"
misfeature needs to be documented.
I'm not sure it needs any extra attention. Even with str, iterated interpolation is tricky -- I've been bitten by it
more than once, and that ev
Nick Coghlan writes:
> Yes, I'm currently thinking the appropriate approach to the docs
> will be to remove the current "these have most of the str methods
> too" paragraph for binary sequences and instead create three
> completely explicit lists of methods:
> - provided, works with arbitr
On 15 Jan 2014 20:58, "Stephen J. Turnbull" wrote:
>
> Aside: OK, Guido, ya got me.
>
> I have a separate screed recounting the reasons for my apostasy, but
> that's probably not interesting any more. I'll send it to individuals
> on request.
>
> > But in terms of explaining the text model, that
Aside: OK, Guido, ya got me.
I have a separate screed recounting the reasons for my apostasy, but
that's probably not interesting any more. I'll send it to individuals
on request.
> But in terms of explaining the text model, that
> separation is important enough that
>
> (1) We should
> Right, that's the danger I was worried about, but the problem is that
> there's at least *some* minimum level of ASCII compatibility that
> needs to be assumed in order to define an interpolation format at all
> (this is the point I originally missed).
Only if you insist that bytes formats
I am exhausted from all these discussions. I just recommend not
touching those docs.
On Tue, Jan 14, 2014 at 8:08 PM, Jim Jewett wrote:
> On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum wrote:
>> Personally I wouldn't add any words suggesting or referring to the
>> option of creation another c
On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum wrote:
> Personally I wouldn't add any words suggesting or referring to the
> option of creation another class for this purpose. You wouldn't
> recommend subclassing dict for constraining the types of keys or
> values, would you?
Yes, and it is so
On 14Jan2014 11:43, Jim Jewett wrote:
> Greg Ewing replied:
> >> ... ASCII compatible binary data is a
> >> *subset* of arbitrary binary data.
>
> I wrote: [...]
> >(2) It *may* be worth creating a virtual
> > split in the documentation. [...]
>
> Ethan likes the idea, but points ou
On 1/14/2014 10:11 AM, Jim J. Jewett wrote:
Virtual subclass ASCIIStructuredBytes
You would first have to define what you meant by a virtual subclass, and
that somewhere would have to be linked every place you use the term,
because it is a new term.
Why not just call the sections of the doc
Guido van Rossum wrote:
Quite a few people have spoken out in favor of loud
failures rather than silent "wrong" output. But I think that in the
specific context of formatting output, there is a long and IMO good
tradition of producing (slightly) wrong output in favor of more strict
behavior. Cons
Ethan Furman wrote:
On 01/14/2014 10:11 AM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(2) It *may* be worth creating a virtual
split in the documentation.
I think (2) is a great idea.
I don't think it's suc
On 1/14/2014 4:46 AM, Nick Coghlan wrote:
The one remaining way I could potentially see a formatb method working
is along the lines of what Glenn (I think) suggested: just like struct
definitions, the formatb specifier would have to consist*solely* of
substitution fields. However, that's getting
Let me answer you both since the issues are related.
On 1/14/2014 7:46 AM, Nick Coghlan wrote:
Guido van Rossum writes:
> And that is precisely my point. When you're using a format string,
Bytes interpolation uses a bytes format, or a byte string if you will,
but it should not be thought o
On 01/14/2014 01:17 PM, Mark Lawrence wrote:
On 14/01/2014 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there would be some combi
On 2014-01-14 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
On 01/14/2014 10:52 AM, Guido van Rossum wrote:
Which reminds me. Quite a few people have spoken out in favor of loud
failures rather than silent "wrong" output. But I think that in the
specific
On 01/14/2014 01:15 PM, Eric V. Smith wrote:
On 1/14/2014 3:54 PM, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there would be some combi
On Jan 14, 2014, at 10:52 AM, Guido van Rossum wrote:
>Which reminds me. Quite a few people have spoken out in favor of loud
>failures rather than silent "wrong" output. But I think that in the
>specific context of formatting output, there is a long and IMO good
>tradition of producing (slightly)
Nick Coghlan wrote:
The
mini-language parser has to assume in encoding in order to interpret
the format string, and that's *all* done assuming an ASCII compatible
format string (which must make life interesting if you try to use an
ASCII incompatible coding cookie for your source code
I don't t
On 14/01/2014 20:54, Guido van Rossum wrote:
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
% data_value[:15] everywhere.
Wow. I thought there would be some combination using %.15s but I can't
get that to wor
On 1/14/2014 3:54 PM, Guido van Rossum wrote:
> On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
>> In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
>> % data_value[:15] everywhere.
>
> Wow. I thought there would be some combination using %.15s but I can't
> get t
On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote:
> On 01/14/2014 10:52 AM, Guido van Rossum wrote:
>>
>> Which reminds me. Quite a few people have spoken out in favor of loud
>> failures rather than silent "wrong" output. But I think that in the
>> specific context of formatting output, there
On 01/14/2014 10:52 AM, Guido van Rossum wrote:
Which reminds me. Quite a few people have spoken out in favor of loud
failures rather than silent "wrong" output. But I think that in the
specific context of formatting output, there is a long and IMO good
tradition of producing (slightly) wrong ou
On Tue, Jan 14, 2014 at 12:04 PM, Eric V. Smith wrote:
> On 01/14/2014 01:52 PM, Guido van Rossum wrote:
>
>> But the way to arrive at this behavior without duplicating a whole lot
>> of code seems to be to call the existing text-based __format__ API and
>> convert the result to bytes -- for numbe
Personally I wouldn't add any words suggesting or referring to the
option of creation another class for this purpose. You wouldn't
recommend subclassing dict for constraining the types of keys or
values, would you?
On Tue, Jan 14, 2014 at 11:43 AM, Jim J. Jewett wrote:
>
>
>
> Greg Ewing replied:
On 01/14/2014 01:52 PM, Guido van Rossum wrote:
> But the way to arrive at this behavior without duplicating a whole lot
> of code seems to be to call the existing text-based __format__ API and
> convert the result to bytes -- for numbers this should be safe (their
> formatting produces just ASCII
Greg Ewing replied:
>> ... ASCII compatible binary data is a
>> *subset* of arbitrary binary data.
I wrote:
> But in terms of explaining the text model, that
> separation is important enough that
>(2) It *may* be worth creating a virtual
> split in the documentation.
(rough ske
On Tue, Jan 14, 2014 at 1:52 PM, Guido van Rossum wrote:
> On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker wrote:
>> On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov
>> wrote:
>>>
>>> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.
>>
>>
>> please no -- that's the source of a lot o
On Tue, 14 Jan 2014 10:52:05 -0800
Guido van Rossum wrote:
> Would you rather raise an exception, truncate the
> value, or mess up the formatting? All languages newer than Fortran
> that I've used have chosen the latter, and I still agree it's a good
> idea.
Well that's useful when printing out h
On 1/14/2014 1:11 PM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(1) We should be reluctant to strengthen the
"its really just ASCII" messages.
(2) It *may* be worth creating a virtual
split in the doc
On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker wrote:
> On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov
> wrote:
>>
>> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.
>
>
> please no -- that's the source of a lot of pain in py2 now.
>
> having a failure as a result of the value, r
On 01/14/2014 10:11 AM, Jim J. Jewett wrote:
But in terms of explaining the text model, that
separation is important enough that
(2) It *may* be worth creating a virtual
split in the documentation.
I think (2) is a great idea.
I'm willing ot work on (2) if there is general
On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov wrote:
> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.
>
please no -- that's the source of a lot of pain in py2 now.
having a failure as a result of the value, rather than the type, of an
object just makes hard-to-test for bugs.
Nick Coghlan wrote:
>> Arbitrary binary data and ASCII compatible binary data are *different
>> things* and the only argument in favour of modelling them with a single
>> type is because Python 2 did it that way.
Greg Ewing replied:
> I would say that ASCII compatible binary data is a
> *sub
On January 14, 2014 at 12:47:35 PM, Brett Cannon (br...@python.org) wrote:
>
> On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote:
>
> > Brett,
> >
> >
> > I like your proposal. There is one idea I have that could,
> > perhaps, improve it:
> >
> >
> > 1. “%s" and “{}” will continue to wor
On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote:
> Brett,
>
>
> I like your proposal. There is one idea I have that could,
> perhaps, improve it:
>
>
> 1. “%s" and “{}” will continue to work for bytes and bytearray in
> the following fashion:
>
> - check if __bytes__/Py_buffer supported.
Brett,
I like your proposal. There is one idea I have that could,
perhaps, improve it:
1. “%s" and “{}” will continue to work for bytes and bytearray in
the following fashion:
- check if __bytes__/Py_buffer supported.
- if it is, check that the bytes are strictly in the printable
ASCII-
On Mon, Jan 13, 2014 at 5:14 PM, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon wrote:
> > I have been going on the assumption that bytes.format() would change what
> > '{}' meant for itself and would only interpolate bytes. That convenient
> > between Python 2 and 3 sin
On 14 January 2014 19:54, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
> > And that is precisely my point. When you're using a format string,
> > all of the format string (not just the part between { and }) had
> > better use ASCII or an ASCII superset. And this (rightly)
> > constrai
Guido van Rossum writes:
> Of course, nobody in their right mind would use a format string
> containing UTF-16 or EBCDIC.
How about Shift JIS and Big 5 (traditionally "mandated by Microsoft"
in their respective regions, with Shift JIS still overwhelmingly
popular) and GB* ("GB18030 is not just
On 1/14/2014 12:03 AM, Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 6:25 PM, Terry Reedy wrote:
byteformat(b'\x00{}\x02{}def', (b'\x01', b'abc',))
b'\x00\x01\x02abcdef'
re.split produces [b'\x00', b'', b'\x02', b'', b'def']. The only ascii bias
is the one already present is the represent
Glenn Linderman wrote:
A mechanism could be defined where
"format string" would only contain format specifications, and any other
text would be considered an error.
Someone already did -- it's called struct.pack(). :-)
--
Greg
___
Python-Dev mailing
On 1/13/2014 9:25 PM, Nick Coghlan wrote:
since this observation makes it clear that there's*no* coherent way
to offer a pure binary interpolation API - the only general purpose
combination mechanism for segments of binary data that can avoid
making assumptions about the encodings of metacharact
On 14 January 2014 15:03, Guido van Rossum wrote:
> I don't think it's that easy. Just searching for '{' is enough to
> break in surprising ways unless the format string is encoded in an
> ASCII superset. I can think of two easy examples to illustrate this
> (they're similar to the example I poste
On 1/13/2014 9:03 PM, Guido van Rossum wrote:
Of course, nobody in their right mind would use a format string
containing UTF-16 or EBCDIC. And that is precisely my point. When
you're using a format string, all of the format string (not just the
part between { and }) had better use ASCII or an ASC
On Mon, Jan 13, 2014 at 6:25 PM, Terry Reedy wrote:
> On 1/13/2014 4:32 PM, Guido van Rossum wrote:
>
>> I will doggedly keep posting to this thread rather than creating more
>> threads.
>
> Please permit to to doggedly keep pointing you toward the possible solution
> I posted on the tracker last
On 2014-01-14 02:25, Terry Reedy wrote:
On 1/13/2014 4:32 PM, Guido van Rossum wrote:
> I will doggedly keep posting to this thread rather than creating more
threads.
Please permit to to doggedly keep pointing you toward the possible
solution I posted on the tracker last October.
But format
On 1/13/2014 5:14 PM, Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon wrote:
I have been going on the assumption that bytes.format() would change what
'{}' meant for itself and would only interpolate bytes. That convenient
between Python 2 and 3 since it represents what we
On 1/13/2014 4:32 PM, Guido van Rossum wrote:
> I will doggedly keep posting to this thread rather than creating more
threads.
Please permit to to doggedly keep pointing you toward the possible
solution I posted on the tracker last October.
But formatb() feels absurd to me. PEP 460 has nei
On 2014-01-13 21:51, Guido van Rossum wrote:
Terminology. Let's use the official terminology rather than making stuff up.
The docs at http://docs.python.org/3/library/string.html#formatspec
use the following terminology:
Replacement field: {...}; contains field name, conversion, format spec
in
On 1/13/2014 3:13 PM, Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 12:02 PM, Brett Cannon wrote:
On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy wrote:
I personally would not add 'bytes % whatever'.
Personally, neither would I; just focus on bytes.format() and let % operator
on strings slow
Nick Coghlan wrote:
Arbitrary binary data and ASCII compatible binary data are *different
things* and the only argument in favour of modelling them with a single
type is because Python 2 did it that way.
I would say that ASCII compatible binary data is a
*subset* of arbitrary binary data. As
Nick Coghlan wrote:
so the latter would be less of
an attractive nuisance when writing code that needs to handle arbitrary
binary formats and can't assume ASCII compatibility.
Hang on a moment. What do you mean by code that
"handles arbitrary binary formats"?
As far as I can see, the propos
On 1/13/2014 1:59 PM, Guido van Rossum wrote:
On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman wrote:
On 1/13/2014 12:09 PM, Guido van Rossum wrote:
Yeah, the %s behavior with a string argument was a messy attempt at
compromise. I was hoping to mimick a common use of %s in Python 2,
where it c
On 14 Jan 2014 04:58, "Guido van Rossum" wrote:
>
> Let me try rebooting the reboot.
>
> My interpretation of Nick's argument is that he are asking for a bytes
> formatting language that doesn't have an implicit ASCII assumption.
>
> To me this feels absurd. The formatting codes (%s, %c) themselve
On Jan 13, 2014, at 5:31 PM, Donald Stufft wrote:
> %s not accepting str is the major thing I’d personally be against.
To be more clear
b”%s” % “abc” == No
b”%s” % 123 == Fine
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signa
On Jan 13, 2014, at 5:25 PM, Eric V. Smith wrote:
> On 1/13/2014 4:59 PM, Guido van Rossum wrote:
>> On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman
>> wrote:
>>> If somehow (unlikely though it seems) we end up keeping %s (e.g.
>>> strictly to ease porting), we could also keep %r as an alias
On 1/13/2014 4:59 PM, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman
> wrote:
>> If somehow (unlikely though it seems) we end up keeping %s (e.g.
>> strictly to ease porting), we could also keep %r as an alias for %a.
>>
>>
>> %s for strictly interpolating bytes eases
On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon wrote:
> I have been going on the assumption that bytes.format() would change what
> '{}' meant for itself and would only interpolate bytes. That convenient
> between Python 2 and 3 since it represents what we want it to (str and bytes
> under the hood
On Mon, 13 Jan 2014 13:56:44 -0800
Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 1:40 PM, Antoine Pitrou wrote:
> > On Mon, 13 Jan 2014 13:32:28 -0800
> > Guido van Rossum wrote:
> >>
> >> But formatb() feels absurd to me. PEP 460 has neither a precise
> >> specification or any actual exampl
On Mon, Jan 13, 2014 at 4:36 PM, Ethan Furman wrote:
> On 01/13/2014 01:20 PM, Mark Lawrence wrote:
>
>> On 13/01/2014 21:01, Paul Moore wrote:
>>
>>>
>>> I think this should be for 3.5, and should not involve an accelerated
>>> release of 3.5 - we should get it into the 3.5 code early and let
>>
On Mon, Jan 13, 2014 at 4:59 PM, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman
> wrote:
>> On 1/13/2014 12:09 PM, Guido van Rossum wrote:
>>
>> Yeah, the %s behavior with a string argument was a messy attempt at
>> compromise. I was hoping to mimick a common use of %
On Mon, Jan 13, 2014 at 4:51 PM, Guido van Rossum wrote:
> Terminology. Let's use the official terminology rather than making stuff
> up.
>
> The docs at http://docs.python.org/3/library/string.html#formatspec
> use the following terminology:
>
> Replacement field: {...}; contains field name, con
On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman wrote:
> On 1/13/2014 12:09 PM, Guido van Rossum wrote:
>
> Yeah, the %s behavior with a string argument was a messy attempt at
> compromise. I was hoping to mimick a common use of %s in Python 2,
> where it can be used with either an 8-bit string o
On Mon, Jan 13, 2014 at 1:40 PM, Antoine Pitrou wrote:
> On Mon, 13 Jan 2014 13:32:28 -0800
> Guido van Rossum wrote:
>>
>> But formatb() feels absurd to me. PEP 460 has neither a precise
>> specification or any actual examples, so I can't tell whether the
>> intention is that the format string c
On 01/13/2014 01:20 PM, Mark Lawrence wrote:
On 13/01/2014 21:01, Paul Moore wrote:
I think this should be for 3.5, and should not involve an accelerated
release of 3.5 - we should get it into the 3.5 code early and let
people thrash out the details during the 3.5 release cycle.
I disagree, i
Nick Coghlan wrote:
By allowing format characters that *do* assume ASCII, the entire
construct is rendered unsafe - you have to look inside the format
string to determine if it is assuming ASCII compatibility or not, thus
the entire construct must be deemed as assuming ASCII compatibility at
the
Terminology. Let's use the official terminology rather than making stuff up.
The docs at http://docs.python.org/3/library/string.html#formatspec
use the following terminology:
Replacement field: {...}; contains field name, conversion, format spec
in that order, all optional.
Field name: either a
On 01/13/2014 01:08 PM, Glenn Linderman wrote:
+1 - what Ethan said. A real death, instead death by inappropriately transformed data, is
fine by me, if b"%s" %
str(...) doesn't have the appropriate .encode(...) call. But I could live with
either.
You mean instead of death by a thousand quote
On Mon, 13 Jan 2014 13:32:28 -0800
Guido van Rossum wrote:
>
> But formatb() feels absurd to me. PEP 460 has neither a precise
> specification or any actual examples, so I can't tell whether the
> intention is that the format string can *only* contain {...} sequences
> or whether it can also cont
On 1/13/2014 12:09 PM, Guido van Rossum wrote:
Yeah, the %s behavior with a string argument was a messy attempt at
compromise. I was hoping to mimick a common use of %s in Python 2,
where it can be used with either an 8-bit string or a number as
argument, acting like %b in the former case and lik
I will doggedly keep posting to this thread rather than creating more threads.
In another thread, Nick has said he's okay with my proposal (not sure
if that includes %s or not, but it now seems of lesser importance) as
long as we simultaneously introduce formatb() and formatb_map() (the
latter is
Glenn Linderman wrote:
Quotes in the stream are a great debug hint, without blowing up.
But do you really want those quotes turning up in
a *binary* stream, where they're somewhere between
awkward and near-impossible to spot by eyeballing,
and may only be discovered when something else --
likel
On 13/01/2014 21:01, Paul Moore wrote:
I think this should be for 3.5, and should not involve an accelerated
release of 3.5 - we should get it into the 3.5 code early and let
people thrash out the details during the 3.5 release cycle.
I disagree, it should be on pypi now so people can start tr
On 1/13/2014 9:38 AM, Ethan Furman wrote:
On 01/13/2014 09:31 AM, Antoine Pitrou wrote:
On Mon, 13 Jan 2014 08:36:05 -0800
Ethan Furman wrote:
You mean crash all the time? I'd be fine with that for both the str
case
and the bytes case. But's probably too late
to change the str case, and th
On 1/13/2014 10:40 AM, Brett Cannon wrote:
This even gives people in-place ASCII encoding for strings by always
using '{:s}' with text which they can do when they port their code to
run under both Python 2 and 3. So you should be able to do
``b'Content-Type: {:s}'.format('image/jpeg')`` and hav
On 1/13/2014 5:06 AM, Nick Coghlan wrote:
I figured out tonight that it's only positioning ASCII interpolation
as an*alternative* to adding binary interpolation that I have a
problem with. It isn't, because you lose the structural assurance that
you haven't inadvertently introduced an assumption
On 13 January 2014 18:58, Guido van Rossum wrote:
> I hear the objections against b'%s' % 'x' returning b"'x'" loud and
> clear, and if the noise about that sub-issue is preventing folks from
> seeing the absurdity in PEP 460, we can talk about a compromise, e.g.
> use %b which would require its a
Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
b'%s' % 'x' == b"'x'" (i.e. the three-byte string containing an 'x'
enclosed in single quotes)
I'm not sure about the quotes. Would anyone ever actually want those
On 1/13/2014 1:49 AM, Mark Shannon wrote:
So why not replace '%s' with '%a' for the ascii case and
with '%b' for directly inserting bytes.
Because %a and %b don't exist in Python 2.7?
I thought this was about 3.5, not 2.7 ;)
'%s' can't work in 3.5, as we must differentiate between
strings whi
On 01/13/2014 12:02 PM, Brett Cannon wrote:
Personally, neither would I; just focus on bytes.format() and let % operator on
strings slowly go away.
Hey, now, some of us like %! ;)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https:
On 01/13/2014 03:09 PM, Guido van Rossum wrote:
> If we have %b for strictly interpolating bytes, I'm fine with adding
> %a for calling ascii() on the argument and then interpolating the
> result after ASCII-encoding it.
>
> If somehow (unlikely though it seems) we end up keeping %s (e.g.
> strict
On Mon, Jan 13, 2014 at 3:11 PM, Yury Selivanov wrote:
> On January 13, 2014 at 3:08:43 PM, Daniel Holth (dho...@gmail.com) wrote:
>>
>> I see it now. b"foo%sbar" % b'baz' should also expand to b"foob'foo'bar"
>>
>> Instead of "%b" could "%j" mean "I should have used + or join()
>> here
>> but was
On Mon, Jan 13, 2014 at 12:02 PM, Brett Cannon wrote:
> On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy wrote:
>> I personally would not add 'bytes % whatever'.
>
> Personally, neither would I; just focus on bytes.format() and let % operator
> on strings slowly go away.
Well, % has some very strong
On January 13, 2014 at 3:08:43 PM, Daniel Holth (dho...@gmail.com) wrote:
>
> I see it now. b"foo%sbar" % b'baz' should also expand to b"foob'foo'bar"
>
> Instead of "%b" could "%j" mean "I should have used + or join()
> here
> but was too lazy" and work on str too?
Isn’t this just error p
On Mon, Jan 13, 2014 at 11:57 AM, Barry Warsaw wrote:
> On Jan 13, 2014, at 02:13 PM, Donald Stufft wrote:
>>On Jan 13, 2014, at 1:58 PM, Guido van Rossum wrote:
>>> I hear the objections against b'%s' % 'x' returning b"'x'" loud and
>>> clear, and if the noise about that sub-issue is preventi
I see it now. b"foo%sbar" % b'baz' should also expand to b"foob'foo'bar"
Instead of "%b" could "%j" mean "I should have used + or join() here
but was too lazy" and work on str too?
On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy wrote:
> On 1/13/2014 1:40 PM, Brett Cannon wrote:
>
>> > So bytes for
On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy wrote:
> On 1/13/2014 1:40 PM, Brett Cannon wrote:
>
> > So bytes formatting really needn't (and shouldn't, IMO) mirror str
>> > formatting.
>>
>
> This was my presumption in writing byteformat().
>
>
> I think one of the things about Guido's proposa
On Jan 13, 2014, at 02:13 PM, Donald Stufft wrote:
>
>On Jan 13, 2014, at 1:58 PM, Guido van Rossum wrote:
>
>> I hear the objections against b'%s' % 'x' returning b"'x'" loud and
>> clear, and if the noise about that sub-issue is preventing folks from
>> seeing the absurdity in PEP 460, we can t
On 1/13/2014 1:40 PM, Brett Cannon wrote:
> So bytes formatting really needn't (and shouldn't, IMO) mirror str
> formatting.
This was my presumption in writing byteformat().
I think one of the things about Guido's proposal that bugs me is that it
breaks the mental model of the .format() meth
On Jan 13, 2014, at 1:58 PM, Guido van Rossum wrote:
> I hear the objections against b'%s' % 'x' returning b"'x'" loud and
> clear, and if the noise about that sub-issue is preventing folks from
> seeing the absurdity in PEP 460, we can talk about a compromise, e.g.
> use %b which would require
Let me try rebooting the reboot.
My interpretation of Nick's argument is that he are asking for a bytes
formatting language that doesn't have an implicit ASCII assumption.
To me this feels absurd. The formatting codes (%s, %c) themselves are
expressed as ASCII characters. If you include anything
On 01/13/2014 09:12 AM, Nick Coghlan wrote:
On 14 January 2014 01:54, Ethan Furman wrote:
Forgive me for being dense, but I don't understand your objection. With
Guido's proposal, '%s' % bytes_data, bytes_data is passed through unchanged.
Did you mean something else by "binary data"?
I mean
On Jan 13, 2014, at 1:45 PM, Daniel Holth wrote:
> On Mon, Jan 13, 2014 at 12:42 PM, R. David Murray
> wrote:
>> On Mon, 13 Jan 2014 12:41:18 +0100, Antoine Pitrou
>> wrote:
>>> On Sun, 12 Jan 2014 18:11:47 -0800
>>> Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman
On Mon, Jan 13, 2014 at 12:42 PM, R. David Murray wrote:
> On Mon, 13 Jan 2014 12:41:18 +0100, Antoine Pitrou
> wrote:
>> On Sun, 12 Jan 2014 18:11:47 -0800
>> Guido van Rossum wrote:
>> > On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
>> > > On 01/12/2014 04:47 PM, Guido van Rossum wrot
On Mon, Jan 13, 2014 at 12:31 PM, Antoine Pitrou wrote:
> On Mon, 13 Jan 2014 08:36:05 -0800
> Ethan Furman wrote:
>
> > On 01/13/2014 08:09 AM, Antoine Pitrou wrote:
> > > On Mon, 13 Jan 2014 07:59:10 -0800
> > > Guido van Rossum wrote:
> > >> On Mon, Jan 13, 2014 at 3:41 AM, Antoine Pitrou
>
Am 13.01.2014 18:38, schrieb Ethan Furman:
> On 01/13/2014 09:31 AM, Antoine Pitrou wrote:
>> On Mon, 13 Jan 2014 08:36:05 -0800 Ethan Furman wrote:
>>>
>>> You mean crash all the time? I'd be fine with that for both the str
>>> case and the bytes case. But's probably too late to change the str
On 01/13/2014 09:31 AM, Antoine Pitrou wrote:
On Mon, 13 Jan 2014 08:36:05 -0800
Ethan Furman wrote:
You mean crash all the time? I'd be fine with that for both the str case
and the bytes case. But's probably too late
to change the str case, and the bytes case should mirror what str does.
L
On January 13, 2014 at 12:45:40 PM, R. David Murray (rdmur...@bitdance.com)
wrote:
[snip]
> There is no use case in the sense you are asking, just like there
> is no
> real use case for '%s' % b'x' producing "b'x'". But the real use
> case
> is exactly the same: to let you know your code is sc
On Mon, 13 Jan 2014 12:41:18 +0100, Antoine Pitrou wrote:
> On Sun, 12 Jan 2014 18:11:47 -0800
> Guido van Rossum wrote:
> > On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
> > > On 01/12/2014 04:47 PM, Guido van Rossum wrote:
> > >> %s seems the trickiest: I think with a bytes argument it
1 - 100 of 146 matches
Mail list logo
