On 12 January 2014 16:22, senthil.kumaran wrote:
> summary:
> Issue #19092 - Raise a correct exception when cgi.FieldStorage is given an
> invalid file-obj. Also use __bool__ to determine the bool of the FieldStorage
> object.
> Library
> ---
>
> +- Issue #19097: Raise the correct Excepti
On 12 January 2014 04:38, R. David Murray 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
> facing, look at the *actual code*, and help that project figure out the
> best way to make that cod
On 12 January 2014 02:33, M.-A. Lemburg wrote:
> On 11.01.2014 16:34, Nick Coghlan wrote:
>> While that was an *expedient* (and, in fact, necessary) solution at
>> the time, the fact it is still thoroughly confusing people 13 years
>> later shows it is not a *comprehensible* solution.
>
> FWIW: I
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 loop::
for test in (...):
with support.check_warnings(("automatic int co
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: 3.3
>> parent: 88410:05e84d3ecd1e
>> user:Georg Brandl
>> date:Sat Jan 11 20:04:19 2014 +01
On 12 January 2014 12:13, Brett Cannon wrote:
> With that flexibility this matches what I have been mulling in the back of
> my head all day. Basically everything that goes in is assumed to be bytes
> unless {:s} says to expect something which can be passed to str() and then
> use some specified e
On 01/11/2014 06:29 PM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 11:05:36AM -0800, Ethan Furman wrote:
On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
unicode to bytes
bytes to unicode using latin1
unicode to bytes
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide
concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with
actual code, and I suspect even Guido could be influenced if h
On 12 Jan 2014 03:44, "Victor Stinner" wrote:
>
> 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 a
On 12 Jan 2014 03:29, "Ethan Furman" wrote:
>
> On 01/11/2014 12:43 AM, Nick Coghlan wrote:
>>
>>
>> In particular, the bytes type is, and always will be, designed for
>> pure binary manipulation [...]
>
>
> I apologize for being blunt, but this is a lie.
>
> Lets take a look at the methods define
On 01/11/2014 05:20 PM, Terry Reedy wrote:
The following function . . .
Thanks, Terry, for doing that.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
On Sat, Jan 11, 2014 at 11:05:36AM -0800, Ethan Furman wrote:
> On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
> >On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
> >>
> >> unicode to bytes
> >> bytes to unicode using latin1
> >> unicode to bytes
> >
> >Where do you get this from
On Sat, Jan 11, 2014 at 8:20 PM, Terry Reedy wrote:
> The following function interpolates bytes, bytearrays, and formatted
> strings, the latter two auto-converted to bytes, into a bytes (or
> auto-converted bytearray) format. This function automates much of what some
> people have recommended fo
No, I don't think it is.
The purpose is to make it easier to work with bytes objects. There can be no
python 2 compatibility when it comes to bytes/unicode conversion.
From: Python-Dev [python-dev-bounces+kristjan=ccpgames@python.org] on
behalf of Se
On 11Jan2014 13:15, Juraj Sukop wrote:
> On Sat, Jan 11, 2014 at 5:14 AM, Cameron Simpson wrote:
> > data = b' '.join( bytify( [ 10, 0, obj, binary_image_data, ... ] ) )
>
> Thanks for the suggestion! The problem with "bytify" is that some items
> might require different formatting than other
On Sat, Jan 11, 2014 at 3:45 PM, Ethan Furman wrote:
> The docs say this [1]:
> ==
> test.support.check_warnings(*filters, quiet=True)
>
> A convenience wrapper for warnings.catch_warnings() that makes it
> easier to test that a warning
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:
[...]
> In Python2, txt is just a str, but in Python3 handling everything as latin1
> st
On Sat, Jan 11, 2014 at 04:28:34PM -0500, Terry Reedy wrote:
> The problem with some criticisms of using 'unicode in Python 3' is that
> there really is no such thing. Unicode in 3.0 to 3.2 used the old
> internal model inherited from 2.x. Unicode in 3.3+ uses a different
> internal model that
The following function interpolates bytes, bytearrays, and formatted
strings, the latter two auto-converted to bytes, into a bytes (or
auto-converted bytearray) format. This function automates much of what
some people have recommended for combining ascii text and binary blogs.
The test passes o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-11, 18:09 GMT, you wrote:
>> We are NOT going back to the confusing incoherent mess that
>> is the Python 2 model of bolting Unicode onto the side of
>> POSIX . . .
>
> We are not asking for that.
Yes, you do. Maybe not you personally, bu
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 o
On Sat, Jan 11, 2014 at 07:22:30PM +, MRAB wrote:
> >with open("outfile.pdf", "w", encoding="latin-1") as f:
> > f.write(pdf)
> >
> [snip]
> The second example won't work because you're forgetting about the
> handling of line endings in text mode.
So I did! Thank you for the correction.
Hi,
2014/1/11 Antoine Pitrou :
>> 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:
>
> - does it call x.__bytes__? int.__bytes__ doesn't exist
> - does it call bytes(x)? bytes(10) gives
> b
2014/1/11 Ethan Furman :
>>> 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, the "s"
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner 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 key question, isn't it?
On Fri, Jan 10, 2014 at 9:13 PM, Juraj Sukop wrote:
>
>
>
> On Sat, Jan 11, 2014 at 12:49 AM, Antoine Pitrou wrote:
>
>> Also, when you say you've never encountered UTF-16 text in PDFs, it
>> sounds like those people who've never encountered any non-ASCII data in
>> their programs.
>
>
> Let me
The docs say this [1]:
==
test.support.check_warnings(*filters, quiet=True)
A convenience wrapper for warnings.catch_warnings() that makes it easier to test that a warning was correctly
raised. It is approximately equivalent to calling
On 01/11/2014 12:45 PM, Donald Stufft wrote:
FWIW as one of the people who it took Python3 to finally figure out how to
actually use unicode, it was the absence of encode on bytes and decode on
str that actually did it. Giving bytes a format method would not have affected
that either way I don’t
On Sat, Jan 11, 2014 at 4:28 PM, Terry Reedy wrote:
> On 1/11/2014 1:44 PM, Stephen J. Turnbull wrote:
>
>> We already *have* a type in Python 3.3 that provides text
>> manipulations on arrays of 8-bit objects: str (per PEP 393).
>>
>> > BTW: I don't know why so many people keep asking for use c
On 1/11/2014 1:44 PM, Stephen J. Turnbull wrote:
We already *have* a type in Python 3.3 that provides text
manipulations on arrays of 8-bit objects: str (per PEP 393).
> BTW: I don't know why so many people keep asking for use cases.
> Isn't it obvious that text data without known (but ASCI
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
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 20:22, schrieb Antoine Pitrou:
> On Sat, 11 Jan 2014 10:38:01 -0800
> Ethan Furman wrote:
>> On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
>> > On Sat, 11 Jan 2014 18:41:49 +0100
>> > Victor Stinner wrote:
>> >>
>> >> If you agree, I will modify the PEP. If Antoine disagree, I will
On 01/11/2014 11:22 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman wrote:
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner wrote:
If you agree, I will modify the PEP. If Antoine disagree, I will fork
the PEP 460 ;-)
On Jan 11, 2014, at 10:34 AM, Nick Coghlan wrote:
> Yes, it bloody well does. The number of people who have told me that
> using Python 3 is what allowed them to finally understand how Unicode
> works vastly exceeds the number of wire protocol and file format devs
> that have complained about wo
On Sat, 11 Jan 2014 11:54:26 -0800, Ethan Furman wrote:
> On 01/11/2014 11:49 AM, Stephen J. Turnbull wrote:
> > MRAB writes:
> >
> > > > with open("outfile.pdf", "w", encoding="latin-1") as f:
> > > > f.write(pdf)
> > > >
> > > [snip]
> > > The second example won't work because you
On 01/11/2014 11:49 AM, Stephen J. Turnbull wrote:
MRAB writes:
> > with open("outfile.pdf", "w", encoding="latin-1") as f:
> > f.write(pdf)
> >
> [snip]
> The second example won't work because you're forgetting about the
> handling of line endings in text mode.
Not so fast! F
MRAB writes:
> > with open("outfile.pdf", "w", encoding="latin-1") as f:
> > f.write(pdf)
> >
> [snip]
> The second example won't work because you're forgetting about the
> handling of line endings in text mode.
Not so fast! Forgot, yes (me too!), but not work? Not quite:
with o
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
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 a bytes object. If it doesn't have the buffer interface,
error.
%s : interpolate a str ob
On 01/11/2014 10:36 AM, Steven D'Aprano wrote:
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
unicode to bytes
bytes to unicode using latin1
unicode to bytes
Where do you get this from? I don't follow your logic. Start with a text
template:
template = """\xDE\xAD\xBE\
On Sat, 11 Jan 2014 10:38:01 -0800
Ethan Furman wrote:
> On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
> > On Sat, 11 Jan 2014 18:41:49 +0100
> > Victor Stinner wrote:
> >>
> >> If you agree, I will modify the PEP. If Antoine disagree, I will fork
> >> the PEP 460 ;-)
> >
> > Please fork it.
>
>
On 2014-01-11 05:36, Steven D'Aprano wrote:
[snip]
Latin-1 has the nice property that every byte decodes into the character
with the same code point, and visa versa. So:
for i in range(256):
assert bytes([i]).decode('latin-1') == chr(i)
assert chr(i).encode('latin-1') == bytes([i])
pa
On Sat, Jan 11, 2014 at 05:33:17PM +0100, M.-A. Lemburg wrote:
> FWIW: I quite liked the Python 2 model, but perhaps that's because
> I already knww how Unicode works, so could use it to make my
> life easier ;-)
/incredulous
I would really love to see you justify that claim. How do you use the
On Sat, Jan 11, 2014 at 04:15:35PM +0100, M.-A. Lemburg wrote:
> I think we need to step back a little from the purist view
> of things and give more emphasis on the "practicality beats
> purity" Zen.
>
> I complete agree with Stephen, that bytes are in fact often
> an encoding of text. If that t
M.-A. Lemburg writes:
> I complete agree with Stephen, that bytes are in fact often
> an encoding of text. If that text is ASCII compatible, I don't
> see any reason why we should not continue to expose the C lib
> standard string APIs available for text manipulations on bytes.
We already *ha
tl;dr: At the end I'm volunteering to look at real code that is having
porting problems.
On Sat, 11 Jan 2014 17:33:17 +0100, "M.-A. Lemburg" wrote:
> asciistr is interesting in that it coerces to bytes instead
> of to Unicode (as is the case in Python 2).
>
> At the moment it doesn't cover the m
On 01/11/2014 10:32 AM, Antoine Pitrou wrote:
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner 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 willing to let the PEP as-is b
On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote:
> On 01/11/2014 07:38 AM, Steven D'Aprano wrote:
> >
> >The point that I am making is that many people want to add formatting
> >operations to bytes so they can put ASCII strings inside bytes. But (as
> >far as I can tell) they don't nee
On Sat, 11 Jan 2014 18:41:49 +0100
Victor Stinner 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 case of
b'%s' % x
Am 11.01.2014 18:41, schrieb Victor Stinner:
> 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
On 01/11/2014 07:34 AM, Nick Coghlan wrote:
On 12 January 2014 01:15, M.-A. Lemburg wrote:
We don't have to be pedantic about the bytes/text separation.
It doesn't help in real life.
Yes, it bloody well does. The number of people who have told me that
using Python 3 is what allowed them to fi
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 sub
On 01/11/2014 12:43 AM, Nick Coghlan wrote:
In particular, the bytes type is, and always will be, designed for
pure binary manipulation [...]
I apologize for being blunt, but this is a lie.
Lets take a look at the methods defined by bytes:
dir(b'')
['__add__', '__class__', '__contains__', '
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-11, 10:56 GMT, you wrote:
> I don't know what the fuss is about.
I just cannot resist:
When you are calm while everybody else is in the state of
panic, you haven’t understood the problem.
-- one of many collections of Murphy’
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-10, 17:34 GMT, you wrote:
> From my experience, the concept of a default locale is deeply
> flawed. What if I log into a (Linux) machine using an old
> latin-1 putty from the Windows XP era, have most file names
> and contents in UTF-8 e
On 11.01.2014 16:34, Nick Coghlan wrote:
> On 12 January 2014 01:15, M.-A. Lemburg wrote:
>> On 11.01.2014 14:54, Georg Brandl wrote:
>>> Am 11.01.2014 14:49, schrieb Georg Brandl:
Am 11.01.2014 10:44, schrieb Stephen Hansen:
> I mean, its not like the "bytes" type lacks knowledge of
On 01/11/2014 07:38 AM, Steven D'Aprano wrote:
The point that I am making is that many people want to add formatting
operations to bytes so they can put ASCII strings inside bytes. But (as
far as I can tell) they don't need to do this, because they can treat
Unicode strings containing code point
On Sun, 12 Jan 2014 01:34:26 +1000
Nick Coghlan wrote:
>
> Yes, it bloody well does. The number of people who have told me that
> using Python 3 is what allowed them to finally understand how Unicode
> works vastly exceeds the number of wire protocol and file format devs
> that have complained ab
On Sat, Jan 11, 2014 at 01:56:56PM +0100, Juraj Sukop wrote:
> On Sat, Jan 11, 2014 at 6:36 AM, Steven D'Aprano wrote:
> > If you consider PDF as binary with occasional pieces of ASCII text, then
> > working with bytes makes sense. But I wonder whether it might be better
> > to consider PDF as mos
On 12 January 2014 01:15, M.-A. Lemburg wrote:
> On 11.01.2014 14:54, Georg Brandl wrote:
>> Am 11.01.2014 14:49, schrieb Georg Brandl:
>>> Am 11.01.2014 10:44, schrieb Stephen Hansen:
>>>
I mean, its not like the "bytes" type lacks knowledge of the subset of
bytes
that happen to b
On Sat, 11 Jan 2014 08:26:57 +0100
Georg Brandl wrote:
> Am 11.01.2014 03:04, schrieb Antoine Pitrou:
> > On Fri, 10 Jan 2014 20:53:09 -0500
> > "Eric V. Smith" wrote:
> >>
> >> So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
> >> 3892. See for example http://bugs.python.or
On 11.01.2014 14:54, Georg Brandl wrote:
> Am 11.01.2014 14:49, schrieb Georg Brandl:
>> Am 11.01.2014 10:44, schrieb Stephen Hansen:
>>
>>> I mean, its not like the "bytes" type lacks knowledge of the subset of bytes
>>> that happen to be 7-bit ascii-compatible and can't perform text-ish
>>> oper
Am 11.01.2014 14:49, schrieb Georg Brandl:
> Am 11.01.2014 10:44, schrieb Stephen Hansen:
>
>> I mean, its not like the "bytes" type lacks knowledge of the subset of bytes
>> that happen to be 7-bit ascii-compatible and can't perform text-ish
>> operations
>> on them--
>>
>> Python 3.3.3 (v3.3
Am 11.01.2014 10:44, schrieb Stephen Hansen:
> I mean, its not like the "bytes" type lacks knowledge of the subset of bytes
> that happen to be 7-bit ascii-compatible and can't perform text-ish operations
> on them--
>
> Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 b
Am 11.01.2014 09:43, schrieb Nick Coghlan:
> On 11 January 2014 12:28, Ethan Furman wrote:
>> On 01/10/2014 06:04 PM, Antoine Pitrou wrote:
>>>
>>> On Fri, 10 Jan 2014 20:53:09 -0500
>>> "Eric V. Smith" wrote:
So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
>>
The PEP 460 discussion threads made it clear that some of the
participants that weren't around for the earlier parts of the Python 3
transition were struggling with the fundamental conceptual differences
between the Python 2 and Python 3 text models.
Since other folks (including Armin Ronacher) ha
On Sat, Jan 11, 2014 at 6:36 AM, Steven D'Aprano wrote:
>
> I'm sorry, I don't understand what you mean here. I'm honestly not
> trying to be difficult, but you sound confident that you understand what
> you are doing, but your description doesn't make sense to me. To me, it
> looks like you are c
On Sat, Jan 11, 2014 at 5:14 AM, Cameron Simpson wrote:
>
> Hi Juraj,
>
Hello Cameron.
> data = b' '.join( bytify( [ 10, 0, obj, binary_image_data, ... ] ) )
>
Thanks for the suggestion! The problem with "bytify" is that some items
might require different formatting than other items. For ex
I don't know what the fuss is about. This isn't about breaking the text model.
It's about a convenient way to turn text into bytes using a default, lenient,
way. Not the other way round.
Here's my proposal
b'foo%sbar' % (a)
would implicitly apply the following function equivalent to every obje
On 1/11/2014 1:44 AM, Stephen Hansen wrote:
There's been a number of examples given: PDF, HTTP, network streams
that switch inline from text-ish to binary and back-again.. But, we
can focus that down to a very narrow and not at all uncommon situation
in the latter.
PDF has been mentioned a fe
For not caring much, your own stubbornness is quite notable throughout this
discussion. Stones and glass houses. :)
That said:
Twisted and Mercurial aren't the only ones who are hurt by this, at all.
I'm aware of at least two other projects who are actively hindered in their
support or migration
On 11 January 2014 12:28, Ethan Furman wrote:
> On 01/10/2014 06:04 PM, Antoine Pitrou wrote:
>>
>> On Fri, 10 Jan 2014 20:53:09 -0500
>> "Eric V. Smith" wrote:
>>>
>>>
>>> So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
>>> 3892. See for example http://bugs.python.org/issue
On 11 January 2014 08:58, Ethan Furman wrote:
> On 01/10/2014 02:42 PM, Antoine Pitrou wrote:
>>
>> On Fri, 10 Jan 2014 17:33:57 -0500
>> "Eric V. Smith" wrote:
>>>
>>> On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
On Fri, 10 Jan 2014 12:56:19 -0500
"Eric V. Smith" wrote:
>
74 matches
Mail list logo
