What about using venv and pip instead of svn?
On Sun, Jan 12, 2014 at 4:12 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 11.01.2014 21:11, schrieb Terry Reedy:
On 1/11/2014 2:04 PM, georg.brandl wrote:
http://hg.python.org/cpython/rev/87bdee4d633a
changeset: 88413:87bdee4d633a
branch:
Planned :)
Georg
Am 12.01.2014 09:12, schrieb INADA Naoki:
What about using venv and pip instead of svn?
On Sun, Jan 12, 2014 at 4:12 PM, Georg Brandl g.bra...@gmx.net
mailto:g.bra...@gmx.net wrote:
Am 11.01.2014 21:11, schrieb Terry Reedy:
On 1/11/2014 2:04 PM, georg.brandl
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 Sun, 12 Jan 2014 17:51:41 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On 12 January 2014 04:38, R. David Murray rdmur...@bitdance.com wrote:
But! Our goal should be to help people convert to Python3. So how can
we find out what the specific problems are that real-world programs are
On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano st...@pearwood.infowrote:
On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
AFAIK (and just for the record), there could be both Latin1 text and
UTF-16
in a PDF (and other encodings too), depending on the font used:
[...]
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 Sat, 11 Jan 2014 23:10:43 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/11/2014 05:37 PM, Brett Cannon wrote:
You're assuming the context manager is doing something magical to verify
that all calls in the block raise the expected
exception. What you want to do is execute it in a
On 12 Jan 2014 21:53, Juraj Sukop juraj.su...@gmail.com wrote:
On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano st...@pearwood.info
wrote:
On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
AFAIK (and just for the record), there could be both Latin1 text and
UTF-16
in a
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
And cross-platform automation tools in Python instead of make
https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script
--
anatoly t.
On Sun, Jan 12, 2014 at 11:12 AM, INADA Naoki songofaca...@gmail.com wrote:
What about using venv and pip instead of svn?
On Sun, Jan 12, 2014
Hi,
I am Nachshon and this is my first post to the python mailing list.
I have been porting some libraries from python 2 to python 3 recently with
the goal of a common codebase that will run on both versions. I was
thinking it would make my life, and a lot of other developers as well, a
lot
Hi Nachson,
Python 2.7 with the -3 warning flag covers most of this, while using tox to
run automated tests under both 2.x and 3.x should cover the rest (tox is
also useful for checking code runs under Python 2.6, even if you normally
use a newer version).
Is there anything in particular you
On 12 Jan 2014 23:39, Nachshon David Armon nachshon.ar...@gmail.com
wrote:
Hi,
I am Nachshon and this is my first post to the python mailing list.
I have been porting some libraries from python 2 to python 3 recently
with the goal of a common codebase that will run on both versions. I was
On Sat, Jan 11, 2014 at 11:53 PM, Nick Coghlan ncogh...@gmail.com wrote:
You may want to tweak the tracker so the comment ends up on the
appropriate issue (#19092 is something else entirely)
Yes. This was supposed to be #19097. My bad.
___
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 would be an explicit encoding operator with a known, fixed, and well
specified encoder.
This would cover most of the use cases seen in this
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
On 13 Jan 2014 01:22, Kristján Valur Jónsson 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 would be an explicit encoding operator with a known, fixed, and well
On Sun, Jan 12, 2014 at 2:16 PM, Nick Coghlan ncogh...@gmail.com wrote:
Why are you proposing to do the *join* in text space? Encode all the parts
separately, concatenate them with b'\n'.join() (or whatever separator is
appropriate). It's only the *text formatting operation* that needs to be
On 01/12/2014 04:24 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 23:10:43 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/11/2014 05:37 PM, Brett Cannon wrote:
You're assuming the context manager is doing something magical to verify that
all calls in the block raise the expected
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
Now you're just splitting hairs, Nick.
An explicit operator, %s, _defined_ to be encode a string object using strict
ascii,
how is that any less explicit than the .encode('ascii', 'strict') spelt out in
full? The language is full of constructs that are shorthands for others, more
lengthy but
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
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 '%a' which reads as encode as ASCII and
On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote:
On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano st...@pearwood.infowrote:
On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote:
AFAIK (and just for the record), there could be both Latin1 text and
UTF-16
in a
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 Sun, Jan 12, 2014 at 11:16:37PM +1000, Nick Coghlan wrote:
content = '\n'.join([
'header',
'part 2 %.3f' % number,
binary_image_data.decode('latin-1'),
utf16_string.encode('utf-16be').decode('latin-1'),
'trailer']).encode('latin-1')
On Sun, Jan 12, 2014 at 3:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 Jan 2014 23:39, Nachshon David Armon nachshon.ar...@gmail.com
wrote:
I propose that this new version of python use the python 3 unicode model.
As the version of python will be fully compatible with both python 2
Wait a second, this is how I understood it but what Nick said made me think
otherwise...
On Sun, Jan 12, 2014 at 6:22 PM, Steven D'Aprano st...@pearwood.infowrote:
On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote:
On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano st...@pearwood.info
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
Daniel Holth writes:
-1 on adding more surrogateesapes by default. It's a pain to track
down where the encoding errors came from.
What do you mean by default? It was quite explicit in the code I
posted, and it's the only reasonable thing to do with text data
without known (but ASCII
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
On 01/12/2014 12:39 PM, Stephen J. Turnbull wrote:
Daniel Holth writes:
-1 on adding more surrogateesapes by default. It's a pain to track
down where the encoding errors came from.
What do you mean by default? It was quite explicit in the code I
posted, and it's the only reasonable
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 conversion.
This makes it very explicit what we are
+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 and
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
Why not just use six.byte_format(fmt, *args)?
It works on both Python2 and Python3 and accepts the numerical format
specifiers, plus '%b' for inserting bytes and '%a' for converting text
to ascii.
Admittedly it doesn't exist yet,
but it could and it would save a lot of arguing :)
(Apologies
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 01/12/2014 01:59 PM, Mark Shannon wrote:
Why not just use six.byte_format(fmt, *args)?
It works on both Python2 and Python3 and accepts the numerical format
specifiers, plus '%b' for inserting bytes and '%a'
for converting text to ascii.
Sounds like the second best option!
Admittedly
On Mon, Jan 13, 2014 at 4:57 AM, Juraj Sukop juraj.su...@gmail.com wrote:
On Sun, Jan 12, 2014 at 6:22 PM, Steven D'Aprano st...@pearwood.info
wrote:
First, utf16_string confuses me. What is it? If it is a Unicode
string, i.e.:
It is a Unicode string which happens to contain code points
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
Steven D'Aprano writes:
then the name is horribly misleading, and it is best handled like this:
content = '\n'.join([
'header',
'part 2 %.3f' % number,
binary_image_data.decode('latin-1'),
utf16_string, # Misleading name, actually Unicode string
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
On 01/12/2014 02:31 PM, Stephen J. Turnbull wrote:
This corrupts binary_image_data. Each byte 127 will be replaced by
two bytes. In the second case, you can use latin1 to encode, it it
gives you what you want.
This kind of subtlety is precisely why MAL warned about use of latin1
to smuggle
I don't know about the rest of you but I feel like the discussion is
heading off the rails (if it hasn't already jumped the tracks). Let's try
to bring this back around to something actionable which people can focus
their energy on as the amount of developer time spent arguing could have
led to
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.
Hi Python-dev.
I'm playing a bit on the concept on live-coding during a debug session and
one of the most annoying things is that although I can reload the code for
a function (using something close to xreload), it seems it's not possible
to change the code for the current frame (i.e.: I need to
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 12Jan2014 17:46, Brett Cannon br...@python.org wrote:
THE EIBTI group are willing to support PEP 460 but beyond that don't want
to have in Python itself anything for bytes.format() which takes in a
string and spits out bytes. It's bytes in-bytes out and not bytes str
in-bytes out as the
On Mon, Jan 13, 2014 at 07:31:16AM +0900, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
then the name is horribly misleading, and it is best handled like this:
content = '\n'.join([
'header',
'part 2 %.3f' % number,
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
There's a lot of discussion about PEP 460 and I haven't read it all.
Maybe you all have already reached the same conclusion that I have. In
that case I apologize (but the PEP should be updated). Here's my
contribution:
PEP 460 itself currently rejects support for %d, AFAIK on the basis
that bytes
Ethan Furman writes:
This kind of subtlety is precisely why MAL warned about use of latin1
to smuggle bytes.
And why I've been fighting Steven D'Aprano on it.
No, I think you haven't been fighting Steven d'A on it. You're
talking about parsing and generating structured binary files,
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
On 01/12/2014 04:02 PM, Stephen J. Turnbull wrote:
So when you talk about we, I suspect you are not the we everybody
else is arguing with. In particular, AIUI your use case is not
included in the use cases most of us -- including Steven -- are
thinking about.
Ah, so even in the minority I'm
On Jan 12, 2014, at 6:55 PM, Guido van Rossum gu...@python.org wrote:
The key reason for introducing a separate bytes type in Python 3 is to
avoid *mixing* bytes and text. This aims to avoid the classic Python 2
Unicode failure, where str+unicode fails or succeeds based on whether
str
On Sun, Jan 12, 2014 at 4:28 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 03:55 PM, Guido van Rossum wrote:
There's a lot of discussion about PEP 460 and I haven't read it all.
Maybe you all have already reached the same conclusion that I have.
No, no agreement has been reached.
On 01/12/2014 03:55 PM, Guido van Rossum wrote:
There's a lot of discussion about PEP 460 and I haven't read it all.
Maybe you all have already reached the same conclusion that I have.
No, no agreement has been reached. Your contribution is timely.
PEP 460 itself currently rejects support
Sorry, I started my own PEP 460 reboot thread -- I wrote that
message before yours arrived, even if maybe I posted after you. I'm in
the PBP camp myself for this. I won't pronounce on PEP 460 as-is.
Please follow up in the other thread if you need clarifications.
On Sun, Jan 12, 2014 at 2:46 PM,
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work too), and
for other types it should probably work like %a, so that it works as
expected for numeric values, and with a
Changing the subject line to better describe what we're talking about. I
hope it is of interest to others apart from Ethan and I -- mixed bytes
and text is hard to get right. (And if I've got something wrong, I'd
like to know about it.)
On Sat, Jan 11, 2014 at 08:38:49PM -0800, Ethan Furman
On Sun, Jan 12, 2014 at 8:27 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work too), and
for other types it should probably
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work too), and
for other types it should probably
On Sun, Jan 12, 2014 at 6:07 PM, Daniel Holth dho...@gmail.com wrote:
Is there a formatting character that means anything except a unicode
string to prevent accidentally interpolating a Unicode string into a
bytes string without [a sane] encoding?
No, and we shouldn't introduce one. An
On Mon, Jan 13, 2014 at 01:03:15PM +1100, Steven D'Aprano wrote:
code speaks louder than words: http://www.pearwood.info/ethan_demo.py
[...]
Ethan refers to code like:
template % (срЃ.encode('cp1251').decode('latin-1'), 42,
blob.decode('latin-1'))
You did say to use a *text* template to
On Sun, Jan 12, 2014 at 9:18 PM, Guido van Rossum gu...@python.org wrote:
On Sun, Jan 12, 2014 at 6:07 PM, Daniel Holth dho...@gmail.com wrote:
Is there a formatting character that means anything except a unicode
string to prevent accidentally interpolating a Unicode string into a
bytes string
On 01/12/2014 06:07 PM, Daniel Holth wrote:
On Sun, Jan 12, 2014 at 8:27 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work
On 01/12/2014 06:16 PM, Ethan Furman wrote:
If you do :
-- b'%s' % 'some text'
Ignore what I previously said. With no encoding the result would be:
b'some text'
So an encoding should definitely be specified.
--
~Ethan~
___
Python-Dev mailing
On 01/12/2014 06:03 PM, Steven D'Aprano wrote:
The above all sounds reasonable. But the following does not -- I think
it shows some fundamental confusion on your part.
My apologies. The '\xd1.' was a bytestring, I forgot to type the b. (I know, I know, I should've copied and pasted
:(
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
On Sun, Jan 12, 2014 at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote:
In reference to a byte stream, if you do:
-- b'%s' % 'some text'.encode('cp1241')
it's really just bytes into bytes.
That's a confusing example -- it would be clearer to just show
b'%s' % b'some text'
If you do :
--
On Sun, Jan 12, 2014 at 6:24 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 06:16 PM, Ethan Furman wrote:
If you do :
-- b'%s' % 'some text'
Ignore what I previously said. With no encoding the result would be:
b'some text'
So an encoding should definitely be specified.
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:
On 01/12/2014 07:45 PM, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote:
In reference to a byte stream, if you do:
-- b'%s' % 'some text'.encode('cp1241')
it's really just bytes into bytes.
That's a confusing example -- it would be clearer to
Steven D'Aprano writes:
Of course you're right, but I have understood the above as being a
sketch and not real code. (E.g. does header really mean the literal
string header, or does it stand in for something which is a header?)
In real code, one would need to have some way of telling
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 06:11 PM, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work
1 - 100 of 110 matches
Mail list logo
