Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
Twisted projects. The issue #3982 was stuck because nobody proposed a
complete definition of the "new" features. Here is a try as a PEP.
The PEP is a draft with open questions. First, I'm not sure that both
bytes%args and byte
(Sorry if this messes-up the thread order, it is meant as a reply to the
original RFC.)
Dear list,
newbie here. After much hesitation I decided to put forward a use case
which bothers me about the current proposal. Disclaimer: I happen to write
a library which is directly influenced by this.
As
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
>
> The PEP is a draft with open questions. First, I'm not sure that both
> bytes%args and bytes.format(args) are needed. The implementation of
> .format() is more complex, so why not only adding bytes%args?
I think we must either imp
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote:
> BTW, there's a subtlety here: ``%s`` currently means "insert the result
> of calling __str__", but bytes formatting should *not* call __str__.
Since it derives from the C printf notation, it means "insert string
here". The fact that __str__
On Tue, 7 Jan 2014 00:54:17 +1100
Chris Angelico wrote:
> On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote:
> > BTW, there's a subtlety here: ``%s`` currently means "insert the result
> > of calling __str__", but bytes formatting should *not* call __str__.
>
> Since it derives from the C pr
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou wrote:
> On Tue, 7 Jan 2014 00:54:17 +1100
> Chris Angelico wrote:
> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou
> wrote:
> > > BTW, there's a subtlety here: ``%s`` currently means "insert the result
> > > of calling __str__", but bytes forma
On Mon, Jan 6, 2014 at 8:44 AM, Antoine Pitrou wrote:
>
> Hi,
>
> On Mon, 6 Jan 2014 14:24:50 +0100
> Victor Stinner wrote:
> >
> > The PEP is a draft with open questions. First, I'm not sure that both
> > bytes%args and bytes.format(args) are needed. The implementation of
> > .format() is more
On 6 Jan 2014 22:15, "Brett Cannon" wrote:
>
>
>
>
> On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou
wrote:
>>
>> On Tue, 7 Jan 2014 00:54:17 +1100
>> Chris Angelico wrote:
>> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou
wrote:
>> > > BTW, there's a subtlety here: ``%s`` currently means "in
On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>> Then,
>> the following points must be decided to define the complete list of
>> supported features (formatters):
>>
>> * Format integer to hexadecimal? ``%x`` and ``%X``
>> * Format integer to octal? ``%o``
>> * Format integer to binary? ``{!b}``
On 01/06/2014 09:50 AM, Xavier Morel wrote:
> On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>>> Then,
>>> the following points must be decided to define the complete list of
>>> supported features (formatters):
>>>
>>> * Format integer to hexadecimal? ``%x`` and ``%X``
>>> * Format integer to oc
On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote:
>
> On 6 Jan 2014 22:15, "Brett Cannon" wrote:
> >
> >
> >
> >
> > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou
> wrote:
> >>
> >> On Tue, 7 Jan 2014 00:54:17 +1100
> >> Chris Angelico wrote:
> >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine
On Tue, 7 Jan 2014 00:45:58 +1000
Nick Coghlan wrote:
>
> Right, but it seems to me that a new helper module that could be made
> backwards compatible at least as far as 2.6 (if not further) would be more
> useful for that than a builtin change that won't be available until 2015.
More useful in
On 6 Jan 2014 22:56, "Brett Cannon" wrote:
>
>
>
>
> On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote:
>>
>>
>> On 6 Jan 2014 22:15, "Brett Cannon" wrote:
>> >
>> >
>> >
>> >
>> > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou
wrote:
>> >>
>> >> On Tue, 7 Jan 2014 00:54:17 +1100
>> >> Chris A
I've just posted about PEP 460 and this discussion on the mercurial-devel
mailing list.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/option
Am 06.01.2014 14:24, schrieb Victor Stinner:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982 was stuck because nobody proposed a
> complete definition of the "new" features. Here is a try as a PEP.
Very nice, thanks. If I was to ma
On 7 January 2014 09:40, Georg Brandl wrote:
> Very nice, thanks. If I was to make a blasphemous suggestion I would
> even target it for Python 3.4. (No, seriously, this is a big issue
> - see the recent discussion by Armin - and the big names involved show
> that it is a major holdup of 3.x upt
2014/1/7 Paul Moore :
> Will the relevant projects actually support only 2.X and 3.4/5+? If
> they expect to or have to support 3.2 or 3.3, then this change isn't
> actually going to help them much. If they will only support versions
> of Python 3 containing this change, then it may well be worth
>
Given the low adoption rates for Python 3 it would not surprise me if people
who are hampered by the lack of this change are willing to wait until a Python
version is released that has it.
On Jan 7, 2014, at 5:13 AM, Victor Stinner wrote:
> 2014/1/7 Paul Moore :
>> Will the relevant projects act
On 7 Jan 2014 18:18, "Donald Stufft" wrote:
>
> Given the low adoption rates for Python 3 it would not surprise me if
people
> who are hampered by the lack of this change are willing to wait until a
Python
> version is released that has it.
Once the code exists (regardless of the exact spelling),
Am 07.01.2014 10:59, schrieb Paul Moore:
> On 7 January 2014 09:40, Georg Brandl wrote:
>> Very nice, thanks. If I was to make a blasphemous suggestion I would
>> even target it for Python 3.4. (No, seriously, this is a big issue
>> - see the recent discussion by Armin - and the big names involv
On Tue, 07 Jan 2014 10:40:15 +0100
Georg Brandl wrote:
> Am 06.01.2014 14:24, schrieb Victor Stinner:
> > Hi,
> >
> > bytes % args and bytes.format(args) are requested by Mercurial and
> > Twisted projects. The issue #3982 was stuck because nobody proposed a
> > complete definition of the "new" f
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl wrote:
>
> The proposal would be to focus entirely on addressing these roadblocks
> in the 3.5 version, and no other new features -- the release cycle
> needn't be 18 months for this one. This is similar to the moratorium
> for 3.2, but that one ca
Antoine Pitrou wrote:
> > Very nice, thanks. If I was to make a blasphemous suggestion I would
> > even target it for Python 3.4. (No, seriously, this is a big issue
> > - see the recent discussion by Armin - and the big names involved show
> > that it is a major holdup of 3.x uptake.) It would
Am 07.01.2014 12:16, schrieb Antoine Pitrou:
> On Tue, 07 Jan 2014 11:33:55 +0100
> Georg Brandl wrote:
>>
>> The proposal would be to focus entirely on addressing these roadblocks
>> in the 3.5 version, and no other new features -- the release cycle
>> needn't be 18 months for this one. This is
Is this really a good idea? PEP 460 proposes rather different
semantics for bytes.format and the bytes % operator from the str
versions. I think this is going to be both confusing and a continuous
target for "further improvement" until the two implementations
converge.
Nick Coghlan writes:
>I
Most popular formatting codes in Mercurial sources:
2519 %s
493 %d
102 %r
48 %Y
47 %M
41 %H
39 %S
38 %m
33 %i
29 %b
23 %ld
19 %ln
12 %.3f
10 %a
10 %.1f
9 %(val)r
9 %p
9 %.2f
8 %I
6 %n
5 %(va
+1
I have always been delighted that it is possible to manipulate binary
data in Python using string operations. It's not just immoral
non-Unicode text processing. A poor man's ASN.1 generator is an
example of a very non-text thing that might be convenient to write
with a few %s fill-in-the-blanks
On 01/07/2014 06:24 AM, Stefan Krah wrote:
> Antoine Pitrou wrote:
>>> Very nice, thanks. If I was to make a blasphemous suggestion I would
>>> even target it for Python 3.4. (No, seriously, this is a big issue
>>> - see the recent discussion by Armin - and the big names involved show
>>> that i
On 01/07/2014 02:22 PM, Serhiy Storchaka wrote:
Most popular formatting codes in Mercurial sources:
2519 %s
493 %d
102 %r
48 %Y
47 %M
41 %H
39 %S
38 %m
33 %i
29 %b
[...]
Are you sure you're not including str[fp]time formats in t
Daniel Holth writes:
> Isn't it true that if you have bytes > 127 or surrogate escapes then
> encoding to latin1 is no longer as fast as memcpy?
Be careful. As phrased, the question makes no sense. You don't "have
bytes" when you are encoding, you have characters.
If you mean "what happens w
Am 07.01.14 15:08, schrieb Daniel Holth:
> Isn't it true that if you have bytes > 127 or surrogate escapes then
> encoding to latin1 is no longer as fast as memcpy?
You mean "decoding from latin1" (i.e. bytes to string)?
No, the opposite is true. It couldn't use memcpy before, but does now
(see _
Victor Stinner, 06.01.2014 14:24:
> ``struct.pack()`` is incomplete. For example, a number cannot be
> formatted as decimal and it does not support padding bytes string.
Then what about extending the struct module in a way that makes it cover
more use cases like these?
Stefan
__
2014/1/7 Stefan Behnel :
> Victor Stinner, 06.01.2014 14:24:
>> ``struct.pack()`` is incomplete. For example, a number cannot be
>> formatted as decimal and it does not support padding bytes string.
>
> Then what about extending the struct module in a way that makes it cover
> more use cases like t
On Tue, Jan 07, 2014 at 09:26:20PM +0900, Stephen J. Turnbull wrote:
> Is this really a good idea? PEP 460 proposes rather different
> semantics for bytes.format and the bytes % operator from the str
> versions. I think this is going to be both confusing and a continuous
> target for "further imp
On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote:
>Very nice, thanks. If I was to make a blasphemous suggestion I would
>even target it for Python 3.4. (No, seriously, this is a big issue
>- see the recent discussion by Armin - and the big names involved show
>that it is a major holdup of 3.x up
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote:
> I think we should be willing to entertain breaking feature freeze for getting
> this in Python 3.4.
Maybe you could revert 3.4 to alpha status and give it a cycle or two
there to get this done before returning to beta status.
Skip
___
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw wrote:
>
> If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think
> I'd still like to see the following excluded and unknown features added:
>
> * Attribute access: {obj.attr}
> * Indexing: {dict[key]}
> * format keywords?
On Jan 07, 2014, at 11:13 AM, Victor Stinner wrote:
>Twisted and Mercurial don't support Python 3.
>
>(I heard that Twisted Core supports Python 3, but I don't know if it's
>true nor the Python 3 version.)
Parts of Twisted do run on Python 3 (and are even available in Ubuntu), but if
PEP 460 help
On Jan 07, 2014, at 05:16 AM, Donald Stufft wrote:
>Given the low adoption rates for Python 3 it would not surprise me if people
>who are hampered by the lack of this change are willing to wait until a Python
>version is released that has it.
If that means waiting until 3.5, then I disagree. The
On Tue, 7 Jan 2014 05:16:18 -0500
Donald Stufft wrote:
> Given the low adoption rates for Python 3
It would be nice not repeating that mantra since there are no reliable
usage figures available.
Regards
Antoine.
___
Python-Dev mailing list
Python-De
On Tue, Jan 7, 2014, at 12:46 PM, Barry Warsaw wrote:
> On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote:
>
> >Very nice, thanks. If I was to make a blasphemous suggestion I would
> >even target it for Python 3.4. (No, seriously, this is a big issue
> >- see the recent discussion by Armin - and
On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote:
>On Tue, 7 Jan 2014 15:46:50 -0500
>Barry Warsaw wrote:
>>
>> If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think
>> I'd still like to see the following excluded and unknown features added:
>>
>> * Attribute access:
Benjamin Peterson writes:
> I agree. This is a very important, much-requested feature for low-level
> networking code.
I hear it's much-requested, but is there any description of typical
use cases? The ones I've seen on this list and on -ideas are
typically stream-oriented, and seem like they
On 07/01/2014 22:11, Skip Montanaro wrote:
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote:
I think we should be willing to entertain breaking feature freeze for getting
this in Python 3.4.
Maybe you could revert 3.4 to alpha status and give it a cycle or two
there to get this done before
On 06/01/14 13:24, Victor Stinner wrote:
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
[snip]
I'm opposed to adding methods to bytes for this, as I think it goes
against the reason for the separation of str and bytes in the first place.
str objects are pieces of tex
On 06.01.2014 14:24, Victor Stinner wrote:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982 was stuck because nobody proposed a
> complete definition of the "new" features. Here is a try as a PEP.
>
> The PEP is a draft with open que
Hi,
2014/1/8 Mark Shannon :
> I'm opposed to adding methods to bytes for this, as I think it goes against
> the reason for the separation of str and bytes in the first place.
Well, sometimes practicability beats purity. Many developers
complained that Python 3 is too string. The motivation of the
Hi,
2014/1/8 M.-A. Lemburg :
> I'd simply copy over the Python 2 PyString code and start working
> from there.
It's not possible to reuse directly all Python 2 code because some
helpers have been modified to work on Unicode. The PEP 460 adds also
more work to other implementations of Python.
IMO
On Wed, Jan 8, 2014 at 9:12 PM, Victor Stinner wrote:
> IMO some formatting commands must not be implemented. For example,
> alignment is used to display something on screen, not in network
> protocols or binary file formats.
Must not, or need not? I can understand that those sorts of features
wo
On Wed, 08 Jan 2014 13:51:36 +0900
"Stephen J. Turnbull" wrote:
> Benjamin Peterson writes:
>
> > I agree. This is a very important, much-requested feature for low-level
> > networking code.
>
> I hear it's much-requested, but is there any description of typical
> use cases? The ones I've see
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner wrote:
>
> > What does b'%s' % 7 do?
>
> See Examples of the PEP:
>
> b'a%sc%s' % (b'b', 4) gives b'abc4'
[...]
> > And then what? Use the "default" encoding? ASCII?
>
> Bytes have no encoding. There are just bytes :-)
Therefore you shouldn't a
On 08.01.2014 11:12, Victor Stinner wrote:
> Hi,
>
> 2014/1/8 M.-A. Lemburg :
>> I'd simply copy over the Python 2 PyString code and start working
>> from there.
>
> It's not possible to reuse directly all Python 2 code because some
> helpers have been modified to work on Unicode. The PEP 460 add
Hi Victor,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982 was stuck because nobody proposed a
> complete definition of the "new" features. Here is a try as a PEP.
There is
On Tue, Jan 7, 2014 at 10:36 AM, Stephen J. Turnbull wrote:
> Daniel Holth writes:
>
> > Isn't it true that if you have bytes > 127 or surrogate escapes then
> > encoding to latin1 is no longer as fast as memcpy?
>
> Be careful. As phrased, the question makes no sense. You don't "have
> bytes"
On 01/08/2014 02:28 AM, Antoine Pitrou wrote:
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner wrote:
What does b'%s' % 7 do?
See Examples of the PEP:
b'a%sc%s' % (b'b', 4) gives b'abc4'
[...]
And then what? Use the "default" encoding? ASCII?
Bytes have no encoding. There are just byte
2014/1/8 Ethan Furman :
>> Therefore you shouldn't accept integers. It does not make sense to
>> format 4 as b'4'.
>
> Agreed. I would have that it would result in b'\x04'.
The PEP proposes b'%c' % 4 => b'\x04.
Antoine gave me a good argument against supporting b'%s' % int: how
would int subclas
Victor Stinner, 07.01.2014 19:14:
> 2014/1/7 Stefan Behnel:
>> Victor Stinner, 06.01.2014 14:24:
>>> ``struct.pack()`` is incomplete. For example, a number cannot be
>>> formatted as decimal and it does not support padding bytes string.
>>
>> Then what about extending the struct module in a way tha
On Wed, Jan 8, 2014 at 3:40 AM, M.-A. Lemburg wrote:
> PS: The PEP mentions having to code for Python 3.0-3.4 as well,
> which would don't support the new methods. I think it's perfectly
> fine to have newly ported code to require Python 2.7/3.5+. After
> all, the porting effort will take some tim
On Wed, 8 Jan 2014 11:16:49 -0700
Eric Snow wrote:
>
> It boils down to 3.5 being *the* target for porting from 2.7.
No. Please let's stop being self-deprecating. 3.3 is fine as a porting
target, as the many high-profile libraries which have already been
ported can attest.
> Otherwise we'd be b
On Mon, Jan 6, 2014 at 6:24 AM, Victor Stinner wrote:
> Abstract
>
>
> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
> Python 3.5.
>
>
> Rationale
> =
>
> ``bytes % args`` and ``bytes.format(args)`` have been removed in Python
> 2. This operator and this metho
On Wed, 8 Jan 2014 11:59:51 -0700
Eric Snow wrote:
> As others have opined,
> formatting a bytes object is out of place.
However, interpolating a bytes object isn't out of place, and it is
what a minimal "formatting" primitive could do.
Regards
Antoine.
___
Victor Stinner, 06.01.2014 14:24:
> Abstract
>
> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
> Python 3.5.
Here is a counterproposal. Let someone who needs this feature write a
library that does byte string formatting. That properly handles it, a full
featured tool
On Wed, Jan 08, 2014 at 07:12:06PM +0100, Stefan Behnel wrote:
> Why can't someone write a third-party library that does what these projects
> need, and that works in both Py2 and Py3, so that these projects can be
> modified to use that library and thus get on with their porting to Py3?
Apologies
Hi,
Another remark about the PEP: it should define bytearray % args and
bytearray.format(args) as well.
Regards
Antoine.
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
> Hi,
>
> bytes % args and bytes.format(args) are requested by Mercurial and
> Twisted projects. The issue #3982
On Wed, Jan 8, 2014 at 2:17 PM, Stefan Behnel wrote:
> Victor Stinner, 06.01.2014 14:24:
>> Abstract
>>
>> Add ``bytes % args`` operator and ``bytes.format(args)`` method to
>> Python 3.5.
>
> Here is a counterproposal. Let someone who needs this feature write a
> library that does byte s
Hi,
With Victor's consent, I overhauled PEP 460 and made the feature set
more restricted and consistent with the bytes/str separation. However, I
also added bytearray into the mix, as bytearray objects should
generally support the same operations as bytes (and they can be useful
*especially* for
> And I think everyone was well intentioned - and python3 covers most of the
> bases, but working with binary data is not only a "wire-protocol
> programmer's"
> problem. Needing a library to wrap bytesthing.format('ascii',
> 'surrogateescape')
> or some such thing makes python3 less approachable
On 2014-01-06 13:24, Victor Stinner wrote:
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
Twisted projects. The issue #3982 was stuck because nobody proposed a
complete definition of the "new" features. Here is a try as a PEP.
The PEP is a draft with open questions. Firs
Antoine Pitrou writes:
> However, interpolating a bytes object isn't out of place, and it is
> what a minimal "formatting" primitive could do.
Something like this?
# VERY incomplete pseudo-code
class str:
# new method
# fmtstring has syntax of .format method's spec, ma
On 9 Jan 2014 11:29, "INADA Naoki" wrote:
>
>
>> And I think everyone was well intentioned - and python3 covers most of
the
>> bases, but working with binary data is not only a "wire-protocol
programmer's"
>> problem.
If you're working with binary data, use the binary API offered by bytes,
bytear
On Thu, 09 Jan 2014 03:54:13 +
MRAB wrote:
> I'm thinking that the "i" format could be used for signed integers and
> the "u" for unsigned integers. The width would be the number of bytes.
> You would also need to have a way of specifying the endianness.
>
> For example:
>
> >>> b'{:<2i}'.f
On Jan 08, 2014, at 01:51 PM, Stephen J. Turnbull wrote:
>Benjamin Peterson writes:
>
> > I agree. This is a very important, much-requested feature for low-level
> > networking code.
>
>I hear it's much-requested, but is there any description of typical
>use cases?
The two unported libraries that
On 9 Jan 2014 06:43, "Antoine Pitrou" wrote:
>
>
> Hi,
>
> With Victor's consent, I overhauled PEP 460 and made the feature set
> more restricted and consistent with the bytes/str separation.
+1
I was initially dubious about the idea, but the proposed semantics look
good to me.
We should probab
On Fri, 10 Jan 2014 05:26:04 +1000
Nick Coghlan wrote:
>
> We should probably include format_map for consistency with the str API.
Yes, you're right.
> >However, I
> > also added bytearray into the mix, as bytearray objects should
> > generally support the same operations as bytes (and they can
On 10 Jan 2014 03:32, "Antoine Pitrou" wrote:
>
> On Fri, 10 Jan 2014 05:26:04 +1000
> Nick Coghlan wrote:
> >
> > We should probably include format_map for consistency with the str API.
>
> Yes, you're right.
>
> > >However, I
> > > also added bytearray into the mix, as bytearray objects should
On Fri, 10 Jan 2014 11:32:05 +1000
Nick Coghlan wrote:
> >
> > It's consistent with bytearray.join's behaviour:
> >
> > >>> x = bytearray()
> > >>> x.join([b"abc"])
> > bytearray(b'abc')
> > >>> x
> > bytearray(b'')
>
> Yeah, I guess I'm OK with us being consistent on that one. It's still
> weird
On 1/10/2014 12:17 PM, Juraj Sukop wrote:
> (Sorry if this messes-up the thread order, it is meant as a reply to the
> original RFC.)
>
> Dear list,
>
> newbie here. After much hesitation I decided to put forward a use case
> which bothers me about the current proposal. Disclaimer: I happen to
>
On 06/01/2014 13:24, Victor Stinner wrote:
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
Twisted projects. The issue #3982 was stuck because nobody proposed a
complete definition of the "new" features. Here is a try as a PEP.
Apologies if this has already been said, b
Am 10.01.2014 18:56, schrieb Eric V. Smith:
> On 1/10/2014 12:17 PM, Juraj Sukop wrote:
>> (Sorry if this messes-up the thread order, it is meant as a reply to the
>> original RFC.)
>>
>> Dear list,
>>
>> newbie here. After much hesitation I decided to put forward a use case
>> which bothers me a
On Fri, Jan 10, 2014 at 9:17 AM, Juraj Sukop wrote:
> As you may know, PDF operates over bytes and an integer or floating-point
> number is written down as-is, for example "100" or "1.23".
>
Just to be clear here -- is PDF specifically bytes+ascii?
Or could there be some-other-encoding unicode
2014/1/10 Juraj Sukop :
> In the case of PDF, the embedding of an image into PDF looks like:
>
> 10 0 obj
> << /Type /XObject
> /Width 100
> /Height 100
> /Alternates 15 0 R
> /Length 2167
> >>
> stream
> ...binary image data...
> ends
On 1/10/2014 5:12 PM, Victor Stinner wrote:
> 2014/1/10 Juraj Sukop :
>> In the case of PDF, the embedding of an image into PDF looks like:
>>
>> 10 0 obj
>> << /Type /XObject
>> /Width 100
>> /Height 100
>> /Alternates 15 0 R
>> /Length 2167
>> >
On Fri, 10 Jan 2014 12:56:19 -0500
"Eric V. Smith" wrote:
>
> I agree. I don't see any reason to exclude int and float. See Guido's
> messages http://bugs.python.org/issue3982#msg180423 and
> http://bugs.python.org/issue3982#msg180430 for some justification and
> discussion.
If you are represent
On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
> On Fri, 10 Jan 2014 12:56:19 -0500
> "Eric V. Smith" wrote:
>>
>> I agree. I don't see any reason to exclude int and float. See Guido's
>> messages http://bugs.python.org/issue3982#msg180423 and
>> http://bugs.python.org/issue3982#msg180430 for some ju
On Fri, 10 Jan 2014 17:20:32 -0500
"Eric V. Smith" wrote:
>
> Isn't the point of the PEP to make it easier to port 2.x code to 3.5?
> Is
> there really existing code like this in 2.x?
No, but so what? The point of the PEP is not to allow arbitrary
Python 2 code to run without modification under
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:
> >>
> >> I agree. I don't see any reason to exclude int and float. See Guido's
> >> messages http://bugs.python.org/issue3982#
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:
I agree. I don't see any reason to exclude int and float. See Guido's
messages http:/
On Fri, 10 Jan 2014 14:58:15 -0800
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:
>
>
On 1/10/2014 6:02 PM, Antoine Pitrou wrote:
> On Fri, 10 Jan 2014 14:58:15 -0800
> 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:5
On Fri, 10 Jan 2014 18:14:45 -0500
"Eric V. Smith" wrote:
>
> >> Because embedding the ASCII equivalent of ints and floats in byte streams
> >> is a common operation?
> >
> > Again, if you're representing "ASCII", you're representing text and
> > should use a str object.
>
> Yes, but is there e
On Fri, Jan 10, 2014 at 10:52 PM, Chris Barker wrote:
> On Fri, Jan 10, 2014 at 9:17 AM, Juraj Sukop wrote:
>
>> As you may know, PDF operates over bytes and an integer or floating-point
>> number is written down as-is, for example "100" or "1.23".
>>
>
> Just to be clear here -- is PDF specifical
On Fri, Jan 10, 2014 at 11:12 PM, Victor Stinner
wrote:
>
> What not building "10 0 obj ... stream" and "endstream endobj" in
> Unicode and then encode to ASCII? Example:
>
> data = b''.join((
> ("%d %d obj ... stream" % (10, 0)).encode('ascii'),
> binary_image_data,
> ("endstream endobj").e
On Sat, 11 Jan 2014 00:43:39 +0100
Juraj Sukop wrote:
> Basically, to ".encode('ascii')" every possible
> number is not exactly simple or pretty.
Well it strikes me that the PDF format itself is not exactly simple or
pretty. It might be convenient that Python 2 allows you, in certain
cases, to "i
On Fri, Jan 10, 2014 at 3:40 PM, Juraj Sukop wrote:
> What this all means is that the PDF objects are expressed in ASCII,
> "stream" objects like images and fonts may have a binary part and I never
> saw those UTF+16 strings.
>
hmm -- I wonder if they are out there in the wild, though
> u
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 clarify: one does not think in "writing text in Unicode"-terms in
PDF.
On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
With Victor's consent, I overhauled PEP 460 and made the feature set
more restricted and consistent with the bytes/str separation.
From the PEP:
=
Python 3 generally mandates that text be stored and manipulated as
unicode (i.e. str ob
On Fri, 10 Jan 2014 16:23:53 -0800
Ethan Furman wrote:
> On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
> >
> > With Victor's consent, I overhauled PEP 460 and made the feature set
> > more restricted and consistent with the bytes/str separation.
>
> From the PEP:
> =
> > Python 3 gen
On 1/10/2014 8:12 PM, Antoine Pitrou wrote:
> On Fri, 10 Jan 2014 16:23:53 -0800
> Ethan Furman wrote:
>> On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
>>>
>>> With Victor's consent, I overhauled PEP 460 and made the feature set
>>> more restricted and consistent with the bytes/str separation.
>>
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/issue3982#msg180432 .
Then we might as well not do anything, since any attempt to advance
things is met by stubborn o
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/issue3982#msg180432 .
Then we might as well not do anything, since any at
1 - 100 of 171 matches
Mail list logo
