Tres Seaver writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 12:57 AM, Stephen J. Turnbull wrote:
asciistr *canonizes* something as an ASCII string, and therefore
compatible with both bytes and str. It can't *create* such a thing
ex nihilo.
How many
Guido van Rossum wrote:
I've now looked at asciistr. (Thanks Glenn and Ethan for the link.)
Now that I (hopefully) understand it, I'm worried that a text
processing algorithm that uses asciistr might under hard-to-predict
circumstances (such as when the arguments contain nothing of interest
to
Nick Coghlan writes:
Give up makes it sound like I got tired of arguing without being
convinced rather than admitting I was just plain wrong.
I thought it was something in between (you explicitly said lenient
PEP 460 doesn't hurt you, but my understanding was you still believe
that there's a
On 14 Jan 2014 19:11, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
Give up makes it sound like I got tired of arguing without being
convinced rather than admitting I was just plain wrong.
I thought it was something in between (you explicitly said lenient
PEP 460
On Tue, Jan 14, 2014 at 12:20 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I've now looked at asciistr. (Thanks Glenn and Ethan for the link.)
Now that I (hopefully) understand it, I'm worried that a text
processing algorithm that uses asciistr might under
On Tue, Jan 14, 2014 at 7:59 AM, Guido van Rossum gu...@python.org wrote:
Here's an example of what I mean:
I sent that off without proofreading, and I also got one detail about
asciistr() wrong. Here are some corrections.
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r +=
[Other readers: asciistr is at https://github.com/jeamland/asciicompat]
On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
Right, asciistr is designed for a specific kind of hybrid API where
you want to accept binary input (and produce binary output) *and* you
want to
On 15 Jan 2014 04:16, Guido van Rossum gu...@python.org wrote:
[Other readers: asciistr is at https://github.com/jeamland/asciicompat]
On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
Right, asciistr is designed for a specific kind of hybrid API where
you want to
Guido van Rossum wrote:
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r += asciistr(')')
return r
The general fix would be to add
else: r += a[:0]
The awkwardness might be reducable if asciistr let
you write something like
r = asciistr('(', a)
meaning give me
On 15 Jan 2014 08:00, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
def spam(a):
r = asciistr('(')
if a: r += a.strip()
r += asciistr(')')
return r
The general fix would be to add
else: r += a[:0]
The awkwardness might be reducable if
Guido van Rossum wrote:
Actually, Nick explained that asciistr() + asciistr() returns str,
That part seems wrong to me, because it means that
you can't write polymorphic byte/string functions
that are composable.
I would be -1 on that, and prefer that
asciistr + asciistr -- asciistr.
--
Greg
On 15 Jan 2014 08:14, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
Actually, Nick explained that asciistr() + asciistr() returns str,
That part seems wrong to me, because it means that
you can't write polymorphic byte/string functions
that are composable.
I
On Tue, Jan 14, 2014 at 1:37 PM, Nick Coghlan ncogh...@gmail.com wrote:
Yep - that's why I consider asciistr to be firmly in the power tool
category. If you know what you're doing, it should let you write hybrid API
code that is just as concise as Python 2, but it's also far more error prone
Nick Coghlan wrote:
On 15 Jan 2014 08:00, Greg Ewing greg.ew...@canterbury.ac.nz
mailto:greg.ew...@canterbury.ac.nz wrote:
If so, would it help if asciistr were a built-in
type, so that other things could be made aware of
it?
That way lies the Python 2 text model, and we're not going
On Tue, Jan 14, 2014 at 10:16:17AM -0800, Guido van Rossum wrote:
Hm. It is beginning to sound more and more flawed. I also worry that
it will bring back the nightmare of data-dependent UnicodeError back.
E.g. this (from tests/basic.py):
def
On Wed, Jan 15, 2014 at 01:03:13PM +1300, Greg Ewing wrote:
Nick Coghlan wrote:
That way lies the Python 2 text model, and we're not going there. It's
probably best to think of asciistr as a way of demonstrating a
rhetorical point about the superiority of the Python 3 text model
Hmmm...
Steven D'Aprano wrote:
I don't think mixing bytes and strings makes good semantic sense.
It's not about mixing bytes and text -- it's about
writing polymorphic code that will work on either
bytes *or* text. Not both at the same time.
If we had quantum computers, this would be easy
to solve:
Steven D'Aprano writes:
I thought I understand the purpose of asciistr was exactly that, to
produce something that was compatible with both bytes and strings.
asciistr *canonizes* something as an ASCII string, and therefore
compatible with both bytes and str. It can't *create* such a thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 12:57 AM, Stephen J. Turnbull wrote:
asciistr *canonizes* something as an ASCII string, and therefore
compatible with both bytes and str. It can't *create* such a thing
ex nihilo.
How many miracles must be attested?
Tres.
- --
Ethan Furman writes:
The part that you don't seem to acknowledge (sorry if I missed it)
is that there are str-like methods already on bytes.
I haven't expressed myself well, but I don't much care about that.
It's what Knuth would classify as a seminumerical method. What I do
care about is
Glenn Linderman writes:
On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
the proposals to embed binary in Unicode by abusing Latin-1
encoding.
Those aren't proposals, they are currently feasible
techniques in Python 3 for *some* use cases. The question is why
On 01/13/2014 02:48 AM, Stephen J. Turnbull wrote:
Ethan Furman writes:
The part that you don't seem to acknowledge (sorry if I missed it)
is that there are str-like methods already on bytes.
I haven't expressed myself well, but I don't much care about that.
You don't care that there are
On 1/13/2014 6:43 AM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
the proposals to embed binary in Unicode by abusing Latin-1
encoding.
Those aren't proposals, they are currently feasible
Stephen J. Turnbull wrote:
PBP doesn't think it's a great idea to pass around bytes that are
implicitly some other type, but didn't mind it (or got used to it) in
Python 2, and so they're not looking at that as a problem that Python
3 can solve. They're looking at Python 3 as the problem that
On 1/13/2014 4:06 PM, Greg Ewing wrote:
snip
of text methods -- together with a text-like literal
syntax and default repr(), even though at least half
the time they're completely inappropriate!
Better said as 'half the time they're coincidentally helpful!'
My $.01 :)
Emile
Glenn Linderman writes:
On 1/13/2014 6:43 AM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
smuggled binary (great term borrowed from a different
subthread) muddies the waters of what you are dealing with.
Not really. The mud is one or more of the serious deficiencies.
It can be
Sorry to butt in, but can you post a link to the asciistr code? Google
has too many hits for other things to be useful to find it, it seems.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing writes:
I don't think of my viewpoint as being PBP. That term
assumes there is purity there to be beaten. To my mind,
any notion of purity with respect to bytes objects
went out the window as soon as it was given a pile
of text methods -- together with a text-like literal
On 1/13/2014 9:06 PM, Guido van Rossum wrote:
Sorry to butt in, but can you post a link to the asciistr code? Google
has too many hits for other things to be useful to find it, it seems.
https://github.com/jeamland/asciicompat
___
Python-Dev mailing
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
Sorry to butt in, but can you post a link to the asciistr code? Google
has too many hits for other things to be useful to find it, it seems.
https://github.com/jeamland/asciicompat
--
~Ethan~
___
On 14 January 2014 15:15, Stephen J. Turnbull step...@xemacs.org wrote:
The purity position is probably going to lose in the end, since Guido
is clearly in the PBP camp at this point, and that's a strong
indicator (especially since Nick has given up on convincing
python-dev). But that does
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
In contrast, here's the tests I drew up for what I thought bytes should do for
us (no code, just tests):
https://bitbucket.org/stoneleaf/bytestring
--
~Ethan~
___
Python-Dev mailing list
On 01/13/2014 09:12 PM, Ethan Furman wrote:
On 01/13/2014 09:06 PM, Guido van Rossum wrote:
In contrast, here's the tests I drew up for what I thought bytes should do for
us (no code, just tests):
https://bitbucket.org/stoneleaf/bytestring
Ugh. Ignore for now, I need to update them to
On 14 January 2014 16:04, Guido van Rossum gu...@python.org wrote:
On Mon, Jan 13, 2014 at 9:34 PM, Nick Coghlan ncogh...@gmail.com wrote:
I've now looked at asciistr. (Thanks Glenn and Ethan for the link.)
Now that I (hopefully) understand it, I'm worried that a text
processing algorithm
On 12 January 2014 01:01, Victor Stinner victor.stin...@gmail.com wrote:
Supporting formating integers would allow to write bContent-Length:
%s\r\n % 123, which would work on Python 2 and Python 3.
I'm surprised that no-one is mentioning bContent-Length: %s\r\n %
str(123) which works on Python
Am 12.01.2014 09:57, schrieb Paul Moore:
On 12 January 2014 01:01, Victor Stinner victor.stin...@gmail.com wrote:
Supporting formating integers would allow to write bContent-Length:
%s\r\n % 123, which would work on Python 2 and Python 3.
I'm surprised that no-one is mentioning
On 12 January 2014 09:23, Georg Brandl g.bra...@gmx.net wrote:
On 12 January 2014 01:01, Victor Stinner victor.stin...@gmail.com wrote:
Supporting formating integers would allow to write bContent-Length:
%s\r\n % 123, which would work on Python 2 and Python 3.
I'm surprised that no-one is
On 12 Jan 2014 22:10, Paul Moore p.f.mo...@gmail.com wrote:
On 12 January 2014 09:23, Georg Brandl g.bra...@gmx.net wrote:
On 12 January 2014 01:01, Victor Stinner victor.stin...@gmail.com
wrote:
Supporting formating integers would allow to write bContent-Length:
%s\r\n % 123, which would
From: Python-Dev [python-dev-bounces+kristjan=ccpgames@python.org] on
behalf of Georg Brandl [g.bra...@gmx.net]
Sent: Sunday, January 12, 2014 09:23
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
Am 12.01.2014 09:57, schrieb Paul Moore
On Sat, Jan 11, 2014 at 8:40 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
Hi there.
How about a compromise?
Personally, I think adding the full complement of integer/float formatting to
bytes is a bit over the top.
How about just supporting two format specifiers?
%b : interpolate
of Georg Brandl [g.bra...@gmx.net]
Sent: Sunday, January 12, 2014 09:23
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
Am 12.01.2014 09:57, schrieb Paul Moore:
On 12 January 2014 01:01, Victor Stinner victor.stin...@gmail.com
wrote:
Supporting
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, Kristján Valur Jónsson wrote:
Imho, this is not equivalent to re-introducing automatic type conversion
between binary/unicode, it is adding a specific convenience function for
explicitly asking for ASCII encoding.
It is not
16:09
To: Kristján Valur Jónsson
Cc: python-dev@python.org; Georg Brandl
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
It is not explicit, it is implicit - whether or not the resulting string
assumes ASCII compatibility or not depends on whether you pass a binary value
On 01/12/2014 08:21 AM, Ethan Furman wrote:
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, Kristján Valur Jónsson wrote:
Imho, this is not equivalent to re-introducing automatic type conversion
between binary/unicode, it is adding a
specific convenience function for
On 12 January 2014 16:52, Kristján Valur Jónsson krist...@ccpgames.com wrote:
I mean, basically what I am suggesting is that in addition to %b with
def helper(o):
return str(o).encode('ascii', 'strict')
b'foo%bbar'%(helper(myobj), )
you have
b'foo%sbar'%(myobj, )
But that's not what
; Georg Brandl
*Subject:* Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
It is not explicit, it is implicit - whether or not the resulting string
assumes ASCII compatibility or not depends on whether you pass a binary
value (no assumption) or a string value (assumes ASCII compatibility
On 12/01/2014 17:06, Mark Shannon wrote:
On 12/01/14 16:52, Kristján Valur Jónsson wrote:
Now you're just splitting hairs, Nick.
An explicit operator, %s, _defined_ to be encode a string object using
strict ascii,
I don't like this because '%s' reads to me as insert *string* here.
I think
On 12 January 2014 17:03, Ethan Furman et...@stoneleaf.us wrote:
We know full well the difference between unicode and bytes, and we know full
well that numbers and much of the text we need has an ASCII (bytes!)
representation. When we do a b'Content Length: %d' % len(binary_data) we
are
On 01/12/2014 09:26 AM, Paul Moore wrote:
On 12 January 2014 17:03, Ethan Furman et...@stoneleaf.us wrote:
We know full well the difference between unicode and bytes, and we know full
well that numbers and much of the text we need has an ASCII (bytes!)
representation. When we do a b'Content
On 12 January 2014 18:26, Ethan Furman et...@stoneleaf.us wrote:
True enough! ;) It's unacceptable in the sense that the bytes type is
/almost/ there, it's /almost/ what is needed to handle the boundary
conditions. We have a __bytes__ method (how is it supposed to be used?)
that could be
I want to add one more PoV: small performance regression, especially on
Python 2.
Because programs that needs byte formatting may be low level and used
heavily from application.
Many programs uses one source approach to support Python 3.
And supporting Python 3 should not means large performance
On 01/11/2014 07:09 PM, Nick Coghlan wrote:
Folks that want implicit serialisation (and I agree it has its uses) should go
help Benno get asciistr up to speed.
asciistr is not what I'm looking for in the way of a boundary type.
I have created a 'bytestring'[1] repository which has the tests
On 01/12/2014 09:26 AM, Paul Moore wrote:
Can you give an example of code that is *nearly* acceptable to you,
which works in Python 2 and 3 today, and explain what improvements you
would like to see to it in order to use it instead of waiting for a
core change?
I'm not a developer, but I'm
On 01/12/2014 11:00 AM, Paul Moore wrote:
And yet I still don't follow what you *want*. Unless it's that b'%d' %
(12,) must work and give b'12', and nothing else is acceptable.
Nothing else is ideal. I'll go that route if I have to. I understand that in the real world you go with what
On 12 January 2014 19:30, Emile van Sebille em...@fenx.com wrote:
len(open('chars','wb').write(.join(map (chr,range(256.read())
Python 2:
len(open('chars','wb').write(.join(map (chr,range(256.read())
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError:
On 01/12/2014 11:30 AM, Emile van Sebille wrote:
On 01/12/2014 09:26 AM, Paul Moore wrote:
Can you give an example of code that is *nearly* acceptable to you,
which works in Python 2 and 3 today, and explain what improvements you
would like to see to it in order to use it instead of waiting for
Georg Brandl writes:
if it weren't for your stupid maximalist opposition).
Can you please stop throwing personal insults around? You don't have to
resort to that level.
Ethan's posts (as an example of one general trend in this thread) are
pretty frustrating, you have to admit.
MAL
Am 12.01.2014 20:30, schrieb Emile van Sebille:
On 01/12/2014 09:26 AM, Paul Moore wrote:
Can you give an example of code that is *nearly* acceptable to you,
which works in Python 2 and 3 today, and explain what improvements you
would like to see to it in order to use it instead of waiting for
Paul Moore wrote:
I could easily argue at this point that this is the type of bug that
having %-formatting operations on bytes would encourage - %s means
format a string (from years of C and Python (text) experience) so I
automatically supply a string argument when using %s in a bytes
formatting
On 12/01/2014 21:06, Greg Ewing wrote:
Paul Moore wrote:
I could easily argue at this point that this is the type of bug that
having %-formatting operations on bytes would encourage - %s means
format a string (from years of C and Python (text) experience) so I
automatically supply a string
Nick Coghlan wrote:
On 13 Jan 2014 01:22, Kristján Valur Jónsson krist...@ccpgames.com
mailto:krist...@ccpgames.com wrote:
Well, my suggestion would that we _should_ make it work, by having
the %s format specifyer on bytes objects mean: str(arg).encode('ascii',
'strict')
It is not
On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote:
Georg Brandl writes:
Antoine writes:
. . . if it weren't for your stupid maximalist opposition. . .
Can you please stop throwing personal insults around? You don't have to
resort to that level.
Ethan's posts (as an example of one general
, January 12, 2014 17:04
To: Kristján Valur Jónsson
Cc: Nick Coghlan; Georg Brandl; python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
On 12 January 2014 16:52, Kristján Valur Jónsson krist...@ccpgames.com wrote:
But that's not what the current PEP says. It uses %s
+1, even better.
From: Python-Dev [python-dev-bounces+kristjan=ccpgames@python.org] on
behalf of Mark Shannon [m...@hotpy.org]
Sent: Sunday, January 12, 2014 17:06
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f
On 01/12/2014 01:06 PM, Greg Ewing wrote:
Paul Moore wrote:
I could easily argue at this point that this is the type of bug that
having %-formatting operations on bytes would encourage - %s means
format a string (from years of C and Python (text) experience) so I
automatically supply a string
On 01/12/2014 01:37 PM, Kristján Valur Jónsson wrote:
Right.
I'm saying, let's support two interpolators only:
%b interpolates a bytes object (or one supporting the charbuffer interface)
into a bytes object.
%s interpolates a str object by first converting to a bytes object using strict
ascii
On 1/12/2014 11:14 AM, Ethan Furman wrote:
And a core principle of the bytes/text separation in Python 3 is that
encoding should never happen implicitly.
That could be. And yet the bytes type already has several concessions
to ASCII encoding.
%d % 26 = an explicit request to convert binary
Paul Moore wrote:
On 12 January 2014 18:26, Ethan Furman et...@stoneleaf.us wrote:
I'm arguing from three PoVs:
1) 2 3 compatible code base
2) having the bytes type /be/ the boundary type
3) readable code
The only one of these that I can see being in any way an argument against
def
Ethan Furman wrote:
Your asciistr, which sometimes returns bytes and sometimes returns text,
is absolutely *not* what we want.
The kind of third-party thing that *might* fill the bill
would be a *function*:
bytesformat(bContent-Length: %d, length)
that implements all the %-specifiers
Mark Lawrence wrote:
I entirely agree. This would also parallel the conversion flags given
here http://docs.python.org/3/library/string.html#format-string-syntax,
I quote Three conversion flags are currently supported: '!s' which
calls str() on the value, '!r' which calls repr() and '!a'
On 12 January 2014 22:10, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I think the readability argument becomes a bit sharper when
you consider more complex examples, e.g. if I have a tuple
of 3 floats that I want to put into a PDF file, then
b%f %f %f % my_floats
is considerably
On 12/01/2014 17:03, Ethan Furman wrote:
On 01/12/2014 08:21 AM, Ethan Furman wrote:
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, Kristján Valur Jónsson wrote:
Imho, this is not equivalent to re-introducing automatic type
conversion between binary/unicode, it is adding a
Hi Ethan,
On Sun, 12 Jan 2014 13:28:15 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote:
Georg Brandl writes:
Antoine writes:
. . . if it weren't for your stupid maximalist opposition. . .
Can you please stop throwing personal insults
Ethan Furman writes:
Nothing else is ideal. I'll go that route if I have to. I
understand that in the real world you go with what works, but in
the development stage you fight for the ideal. :)
You're going to lose, because Python 3 chose a different ideal that
conflicts with yours.
On 1/12/2014 2:57 PM, Stephen J. Turnbull wrote:
But bytes already acknowledges an ASCII bias.
True, but that bias is implemented without use of encoding or
decoding. b'%d' % (123,) - b'123' does require encoding, at the
very least in the sense of type change and serialization.
b'%d' all
On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Nothing else is ideal. I'll go that route if I have to. I
understand that in the real world you go with what works, but in
the development stage you fight for the ideal. :)
You're going to lose, because Python 3 chose
On 01/12/2014 02:52 PM, Antoine Pitrou wrote:
You are right, it is not ok. The wording wasn't constructive or
controlled at all. I'd like to apologize for that.
Thank you. Apology accepted.
At the same point, I was expressing a fair amount of frustration. I
think the last discussion
Glenn Linderman writes:
the proposals to embed binary in Unicode by abusing Latin-1
encoding.
Those aren't proposals, they are currently feasible techniques in
Python 3 for *some* use cases.
The question is why infecting Python 3 with the byte/character
confoundance virus is preferable to
Ethan Furman writes:
1) Are you saying it's okay to be insulting when frustrated? I
also find this mega-thread frustrating, but I'm trying
very hard not to be insulting.
OK, no. Understandable, yes.
2) If you are going to use my name, please be certain of the facts
[1].
On 2014-01-11 22:09, Nick Coghlan wrote:
For Python 2 folks trying to grok where the bright line is in terms of
the Python 3 text model: if your proposal includes *any* kind of
implicit serialisation of non binary data to binary, it is going to be
rejected as an addition to the core bytes
Those still arguing on this thread might want to look at the thread
PEP 460 reboot.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Ethan Furman writes:
On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote:
No, Nick's point is that there's no encoding needed there are all,
just a bunch of methods that handle numbers in the range 0-255. You
can rationalize the particular choice of numbers by referring to the
ASCII
On 01/12/2014 07:02 PM, Stephen J. Turnbull wrote:
[snip most of very eloquent reply]
Thank you, Stephen, for remaining calm despite my somewhat heated response.
A few comments in-line.
I now better understand your viewpoint about text always being unicode strings;
I just happen to disagree.
On 01/12/2014 08:27 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote:
I didn't trim enough to make my point clear. My apologies.
But
knowledge of ASCII isn't necessary to specify these methods; they can
be defined in an
On 01/12/2014 02:32 PM, Mark Lawrence wrote:
I've just tried asciistr using your test code (having corrected the typo, it's
assertIsInstance, not assertIsinstance :)
and it looks like a very good starting point. Have you, or anyone else for
that matter, actually tried asciistr out?
Ah,
On 1/12/2014 8:00 PM, Ethan Furman wrote:
Okay, I've thought somewhat. Under the definition above would it be
fair to say that Db3Table (a class in my dbf module) is a boundary
type? It sits between the actual file and the program, and transforms
bytes into actual Python types.
Yes.
On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
the proposals to embed binary in Unicode by abusing Latin-1
encoding.
Those aren't proposals, they are currently feasible techniques in
Python 3 for *some* use cases.
The question is why infecting Python 3 with the
Hi,
I'm in favor of adding support of formatting integer and floatting
point numbers in the PEP 460: %d, %u, %o, %x, %f with padding and
precision (%10d, %010d, %1.5f) and sign (%-i, %+i) but without
alternate format ({:#x}). %s would also accept int and float for
convenience.
int and float
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460 ;-)
Please fork it.
b'x=%s' % 10 is well defined, it's pure bytes.
It is well-defined? Then please explain me what the general
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460 ;-)
Please fork it.
You've already stated you don't care that much and are
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460 ;-)
Message-
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of Victor Stinner
Sent: 11. janúar 2014 17:42
To: Python Dev
Subject: [Python-Dev] PEP 460: allowing %d and %f and mojibake
Hi,
I'm in favor of adding support of formatting integer and floatting
On Jan 11, 2014, at 10:38 AM, Ethan Furman wrote:
You've already stated you don't care that much and are willing to let the PEP
as-is be rejected. Why not remove your name and let Victor have it back? Is
he not the original author? (If this is protocol just say so -- remember I'm
still new to
On 01/11/2014 11:22 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
If you agree, I will modify the PEP. If
Am 11.01.2014 20:22, schrieb Antoine Pitrou:
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
If you agree, I will modify the PEP. If
11.01.14 21:40, Kristján Valur Jónsson написав(ла):
How about a compromise?
Personally, I think adding the full complement of integer/float formatting to
bytes is a bit over the top.
How about just supporting two format specifiers?
%b : interpolate a bytes object. If it doesn't have the buffer
Am 11.01.2014 22:01, schrieb Serhiy Storchaka:
11.01.14 21:40, Kristján Valur Jónsson написав(ла):
How about a compromise?
Personally, I think adding the full complement of integer/float formatting
to bytes is a bit over the top.
How about just supporting two format specifiers?
%b :
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner victor.stin...@gmail.com wrote:
b'x=%s' % 10 is well defined, it's pure bytes.
It is well-defined? Then please explain me what the general case of
b'%s' % x
is supposed to call:
This is the
2014/1/11 Ethan Furman et...@stoneleaf.us:
b'x=%s' % 10 is well defined, it's pure bytes.
It is well-defined? Then please explain me what the general case of
b'%s' % x
is supposed to call:
This is the key question, isn't it?
Python 2 and Python 3 are very different here.
In Python 2,
On 1/11/2014 1:50 PM, Ethan Furman wrote:
Perhaps that's the problem. According to the docs:
object.__bytes__(self)
Called by bytes() to compute a byte-string representation of an
object. This should return a bytes
1 - 100 of 102 matches
Mail list logo
