On 10 Jan 2014 03:32, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 10 Jan 2014 05:26:04 +1000
Nick Coghlan ncogh...@gmail.com 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
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
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 questions.
Hi,
2014/1/8 Mark Shannon m...@hotpy.org:
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
Hi,
2014/1/8 M.-A. Lemburg m...@egenix.com:
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
On Wed, Jan 8, 2014 at 9:12 PM, Victor Stinner victor.stin...@gmail.com 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
On Wed, 08 Jan 2014 13:51:36 +0900
Stephen J. Turnbull step...@xemacs.org 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
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner victor.stin...@gmail.com 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
Hi Victor,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner victor.stin...@gmail.com 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
On Tue, Jan 7, 2014 at 10:36 AM, Stephen J. Turnbull step...@xemacs.org 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
On 01/08/2014 02:28 AM, Antoine Pitrou wrote:
On Wed, 8 Jan 2014 11:02:19 +0100
Victor Stinner victor.stin...@gmail.com 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
2014/1/8 Ethan Furman et...@stoneleaf.us:
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
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 that makes it
On Wed, Jan 8, 2014 at 3:40 AM, M.-A. Lemburg m...@egenix.com 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
On Wed, 8 Jan 2014 11:16:49 -0700
Eric Snow ericsnowcurren...@gmail.com 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
On Mon, Jan 6, 2014 at 6:24 AM, Victor Stinner victor.stin...@gmail.com 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
On Wed, 8 Jan 2014 11:59:51 -0700
Eric Snow ericsnowcurren...@gmail.com 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 victor.stin...@gmail.com wrote:
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
Twisted
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 for
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.
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, maybe
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 make a
On 7 January 2014 09:40, Georg Brandl g.bra...@gmx.net 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
2014/1/7 Paul Moore p.f.mo...@gmail.com:
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
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 victor.stin...@gmail.com wrote:
2014/1/7 Paul Moore
On 7 Jan 2014 18:18, Donald Stufft don...@stufft.io 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
Am 07.01.2014 10:59, schrieb Paul Moore:
On 7 January 2014 09:40, Georg Brandl g.bra...@gmx.net 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
On Tue, 07 Jan 2014 10:40:15 +0100
Georg Brandl g.bra...@gmx.net 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
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl g.bra...@gmx.net 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
Antoine Pitrou solip...@pitrou.net 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
Am 07.01.2014 12:16, schrieb Antoine Pitrou:
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl g.bra...@gmx.net 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.
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
+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
On 01/07/2014 06:24 AM, Stefan Krah wrote:
Antoine Pitrou solip...@pitrou.net 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
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
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 when
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 stefan...@behnel.de:
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
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
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
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw ba...@python.org 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.
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw ba...@python.org 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
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 helps
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 don...@stufft.io 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
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 the big
On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote:
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw ba...@python.org 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
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 ba...@python.org 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
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
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner victor.stin...@gmail.com 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
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou solip...@pitrou.net 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
On Tue, 7 Jan 2014 00:54:17 +1100
Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou solip...@pitrou.net wrote:
BTW, there's a subtlety here: ``%s`` currently means insert the result
of calling __str__, but bytes formatting should *not* call __str__.
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 7 Jan 2014 00:54:17 +1100
Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou solip...@pitrou.net
wrote:
BTW, there's a subtlety here: ``%s`` currently means insert the
On Mon, Jan 6, 2014 at 8:44 AM, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner victor.stin...@gmail.com 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
On 6 Jan 2014 22:15, Brett Cannon br...@python.org wrote:
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Tue, 7 Jan 2014 00:54:17 +1100
Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou solip...@pitrou.net
wrote:
BTW,
On 2014-01-06, at 14:44 , Antoine Pitrou solip...@pitrou.net 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?
On 01/06/2014 09:50 AM, Xavier Morel wrote:
On 2014-01-06, at 14:44 , Antoine Pitrou solip...@pitrou.net 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
On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 Jan 2014 22:15, Brett Cannon br...@python.org wrote:
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Tue, 7 Jan 2014 00:54:17 +1100
Chris Angelico ros...@gmail.com wrote:
On Tue, 7 Jan 2014 00:45:58 +1000
Nick Coghlan ncogh...@gmail.com 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.
On 6 Jan 2014 22:56, Brett Cannon br...@python.org wrote:
On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 Jan 2014 22:15, Brett Cannon br...@python.org wrote:
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Tue, 7 Jan
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:
101 - 167 of 167 matches
Mail list logo
