2009/11/4 Nick Coghlan ncogh...@gmail.com:
In writing it up, it occurred to me that having that kind of thing in a
py3_compat compatibility module (to be used as, e.g., from py3_compat
import str, bytes) would not only make it easier to use in multiple
modules, but also easier for 2to3 to
2009/11/4 Nick Coghlan ncogh...@gmail.com:
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it effectively really aren't there - lots of areas
Nick Coghlan wrote:
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it effectively really
M.-A. Lemburg wrote:
Nick Coghlan wrote:
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it
Nick Coghlan wrote:
Lennart Regebro wrote:
I also would really like to see a real port of the bytes class to 2.6,
but I have a vague memory that there was some reason that wouldn't
work.
Not so much that it wouldn't work, but that the interfaces to support
using it effectively really
On Wednesday 17 January 2007 05:52, James Y Knight wrote:
Yes, this is it. As a refinement: if the New Way can easily be
backported to 2.5,
Um - 2.5 is _done_. Released. In maintenance mode. New features will
not be getting backported to a 2.5.x release.
Anthony
--
Anthony Baxter
On Jan 17, 2007, at 6:22 PM, Anthony Baxter wrote:
On Wednesday 17 January 2007 05:52, James Y Knight wrote:
Yes, this is it. As a refinement: if the New Way can easily be
backported to 2.5,
Um - 2.5 is _done_. Released. In maintenance mode. New features will
not be getting backported to a
On Jan 12, 2007, at 7:26 PM, Ron Adam wrote:
For me, the thing that will make porting 2.x to 3.x code easy is to
make python
3.0 as clean and organized as you can with excellent
documentation. Half-way
and duel-way approaches will probably not help me as much as this.
Most of the
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
The benefit (to me, and to many others) of 3.x over 2.x is the
promise
of getting rid of cruft.
If we're going to re-add cruft for the sake of temporary
compatibility, we may as well just stick with 2.x. You have to
take a
quantum leap
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
There seems to be rather a lot of confusion. No one is suggesting
Python 3.0 be anything less for the sake of backward compatibility.
Instead, it has been suggested Python 2.6 (and
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
There seems to be rather a lot of confusion. No one is suggesting
Python 3.0 be anything less for the sake of backward compatibility.
On 1/16/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
There seems to be rather a lot of confusion. No one is suggesting
Python 3.0
At 09:50 AM 1/16/2007 -0800, Guido van Rossum wrote:
Actually it's very easy to write code using keys(), items() and
values() that works as well in 2.2 as it works in 3.0: never use the
iter* variants, and don't sweat the performance costs of creating a
list so much. If you can't afford to create
On Jan 16, 2007, at 12:06 PM, Phillip J. Eby wrote:
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of
On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of specifics rather
than attempting at specifying a
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of
On 1/16/07, James Y Knight [EMAIL PROTECTED] wrote:
On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list
On Jan 16, 2007, at 2:35 PM, Guido van Rossum wrote:
Mainly I'd just like to see allowing the ability to write code which
is portable between 2.5 and 3.0 as an explicit goal of the python
3.0 release. I trust that if the developers agree upon that as being
a goal, the right things would
On 1/12/07, Mike Orr [EMAIL PROTECTED] wrote:
On 1/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The benefit (to me, and to many others) of 3.x over 2.x is the promise
of
more future maintenance, not the lack of cruft.
The benefit (to me, and to many others) of 3.x over 2.x is the
Guido van Rossum wrote:
On 1/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently
On Fri, Jan 12, 2007 at 10:14:57AM -0500, Barry Warsaw wrote:
I think there will be at least three areas that will make porting a
challenge:
...
- - Unicode/str/bytes incompatibilities
Something I've been meaning to bring up... do we know what shape the
Unicode/str/bytes resolution will
On 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Fri, Jan 12, 2007 at 10:14:57AM -0500, Barry Warsaw wrote:
I think there will be at least three areas that will make porting a
challenge:
...
- - Unicode/str/bytes incompatibilities
Something I've been meaning to bring up... do we
On Fri, Jan 12, 2007 at 09:51:25AM -0800, Guido van Rossum wrote:
I'm afraid that PEP is not up to date; I don't think I used it as a
reference when I coded up the current bytes type in Py3k. Whenever the
PEP matches the implementation, we can be confident that we have the
right design. Where
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why would I switch to a bytes type
and forgo compatibility with
On 1/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why
On Fri, Jan 12, 2007 at 10:49:13AM -0800, Raymond Hettinger wrote:
I think we should draw a line in the sand and resolve not to garbage-up
Py2.6.
The whole Py3.0 project is about eliminating cruft and being free of the
bonds of backwards compatibility. Adding non-essential cruft to Py2.6
On 06:49 pm, [EMAIL PROTECTED] wrote:
I think we should draw a line in the sand and resolve not to garbage-up Py2.6.
The whole Py3.0 project is about eliminating cruft and being free of the
bonds of backwards compatibility. Adding non-essential cruft to Py2.6
goes against that philosophy.
On 1/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why
A.M. Kuchling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| [*] Anyone else keep wanting to write byte type?
All the other builtin types I can think of are singular. So I think byte
should be also.
___
Python-Dev mailing list
Terry Reedy wrote:
A.M. Kuchling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| [*] Anyone else keep wanting to write byte type?
All the other builtin types I can think of are singular. So I think byte
should be also.
The string holds 'a string' (singular), the bytes
Terry Reedy [EMAIL PROTECTED] wrote:
A.M. Kuchling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| [*] Anyone else keep wanting to write byte type?
All the other builtin types I can think of are singular. So I think byte
should be also.
But a byte already has a standard
On 1/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 06:49 pm, [EMAIL PROTECTED] wrote:
I think we should draw a line in the sand and resolve not to garbage-up
Py2.6.
The whole Py3.0 project is about eliminating cruft and being free of the
bonds of backwards compatibility. Adding
Raymond Hettinger wrote:
[A.M. Kuchling]
2.6 wouldn't go changing existing APIs to begin requiring or returning
the bytes type[*], of course, but extensions and new modules might use
it.
The premise is dubious.
If I am currently maintaining a module, why would I switch to a bytes type
Josiah Carlson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
|
| Terry Reedy [EMAIL PROTECTED] wrote:
| A.M. Kuchling [EMAIL PROTECTED] wrote in message
| news:[EMAIL PROTECTED]
| | [*] Anyone else keep wanting to write byte type?
|
| All the other builtin types I can think of
35 matches
Mail list logo
