On Sat, Jan 19, 2008, Guido van Rossum wrote:
I believe that a constraint should be that by default (without -3 or a
__future__ import) str and bytes should be the same thing. Or, another
way of looking at this, reads from binary files and reads from sockets
(and other similar things, like
On Jan 20, 2008 6:56 AM, Aahz [EMAIL PROTECTED] wrote:
On Sat, Jan 19, 2008, Guido van Rossum wrote:
I believe that a constraint should be that by default (without -3 or a
__future__ import) str and bytes should be the same thing. Or, another
way of looking at this, reads from binary
Neil Schemenauer wrote:
I like this solution because of its simplicity.
I've implemented and submitted the feature yesterday:
Python 2.6a0 (trunk:60048M, Jan 18 2008, 19:08:16)
[GCC 4.2.1 (Ubuntu 4.2.1-5ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
b'a'
'a'
Guido van Rossum [EMAIL PROTECTED] wrote:
bytes is an alias for str (not even a subclass)
b is an alias for
One advantage of a subclass is that there could be a flag that warns
about combining bytes and unicode data. For example, bx + uy
would produce a warning. As someone who writes
On Jan 19, 2008 10:53 AM, Neil Schemenauer [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
bytes is an alias for str (not even a subclass)
b is an alias for
One advantage of a subclass is that there could be a flag that warns
about combining bytes and unicode data. For
On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
There is no way to know whether that return value means text or data
(plenty of apps legitimately read text straight off a socket in 2.x),
IMHO, this is a stretch of the word legitimately ;-). If you're
reading from a socket, what you're getting
On Jan 19, 2008 5:54 PM, [EMAIL PROTECTED] wrote:
On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
There is no way to know whether that return value means text or data
(plenty of apps legitimately read text straight off a socket in 2.x),
IMHO, this is a stretch of the word legitimately ;-). If
On 04:26 am, [EMAIL PROTECTED] wrote:
On Jan 19, 2008 5:54 PM, [EMAIL PROTECTED] wrote:
On 19 Jan, 07:32 pm, [EMAIL PROTECTED] wrote:
Starting with the most relevant bit before getting off into digressions
that may not interest most people:
Why can't we get that warning in -3 mode just the
Guido van Rossum wrote:
Oh, you won't. Just don't use the -3 command-line flag and don't put
from __future__ import whatever at the top of your modules, and
you won't have to change your ways at all. You can continue to
distribute your packages in 2.5 syntax that will also work with 2.6,
and
Guido van Rossum wrote:
I don't think any of that is necessary. I would rather have the
following two in the language by default (see my response to Terry and
Raymond):
bytes is an alias for str (not even a subclass)
b is an alias for
Ah, you like to keep it simple. The aliases are easily
On Jan 18, 2008 12:27 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Oh, you won't. Just don't use the -3 command-line flag and don't put
from __future__ import whatever at the top of your modules, and
you won't have to change your ways at all. You can continue to
On Jan 17, 2008 11:24 PM, Thomas Heller [EMAIL PROTECTED] wrote:
Is the bytes type required for PEP3118 'Revising the buffer protocol'?
I don't think so. I would like to see this PEP backported (but keep
the old 'buffer' of course for b/w compatibility). Whenever this PEP
talks about bytes we
On Jan 17, 2008 9:30 PM, Terry Reedy [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Is it reading text or binary data from stream blah? We can't tell. If
| it's meant to be reading text, 2to3 should leave it alone. But if it's
| meant to
2008/1/18, Guido van Rossum [EMAIL PROTECTED]:
I don't think any of that is necessary. I would rather have the
following two in the language by default (see my response to Terry and
Raymond):
bytes is an alias for str (not even a subclass)
b is an alias for
+1
--
.Facundo
Blog:
Christian Heimes wrote:
Ah, you like to keep it simple. The aliases are easily to implement.
Give me twenty minutes to implement it and write some unit tests.
http://bugs.python.org/issue1865
___
Python-Dev mailing list
Python-Dev@python.org
I believe the issue of whether and how to backport bytes (and
bytearray?) from 3.0 to 2.6 has come up before, but I don't think
we've come to any kind of conclusion. It's quite subtle. In a private
email, Thomas Wouters and I discussed this:
[Guido]
Perhaps the biggest question in my mind is
[GvR]
I believe the issue of whether and how to backport bytes
(and bytearray?) from 3.0 to 2.6 has come up before, but
I don't think we've come to any kind of conclusion.
My recommendation is to leave it out of 2.6.
Not every 3.0 concept has to be backported. This particular one doesn't
On Jan 17, 2008 6:00 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[GvR]
I believe the issue of whether and how to backport bytes
(and bytearray?) from 3.0 to 2.6 has come up before, but
I don't think we've come to any kind of conclusion.
My recommendation is to leave it out of 2.6.
*If* we provide some kind of backport of
bytes (even if it's just an alias for or trivial
subclass of str), it should be part of a strategy
that makes it easier to write code that
runs under 2.6 and can be automatically translated
to run under 3.0 with the same semantics.
If it's just an
On Jan 17, 2008 7:11 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
*If* we provide some kind of backport of
bytes (even if it's just an alias for or trivial
subclass of str), it should be part of a strategy
that makes it easier to write code that
runs under 2.6 and can be automatically
Raymond Hettinger writes:
One other thought. I'm guessing that apps that would
care about the distinction are already using unicode
and are already treating text as distinct from arrays
of bytes.
Indeed. Mailman, for instance. Yet Mailman still has problems with
(broken) wire protocol
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Is it reading text or binary data from stream blah? We can't tell. If
| it's meant to be reading text, 2to3 should leave it alone. But if it's
| meant to be reading binary data, 2to3 should change the string
| literals
having b and bytes as aliases for and
str in 2.6 would mean that we could write 2.6 code that correctly
expresses the use of binary data -- and we could use u and unicode
for code using text, and 2to3 would translate those to and str and
the code would be correct 3.0 text processing code.
On 04:43 am, [EMAIL PROTECTED] wrote:
Just being able to (voluntarily! on a
per-module basis!) use a different type name and literal style for
data could help forward-looking programmers get started on making the
distinction clear, thus getting ready for 3.0 without making the jump
just yet (or
Guido van Rossum schrieb:
I believe the issue of whether and how to backport bytes (and
bytearray?) from 3.0 to 2.6 has come up before, but I don't think
we've come to any kind of conclusion. It's quite subtle. In a private
email, Thomas Wouters and I discussed this:
[Guido]
Perhaps the
25 matches
Mail list logo
