On Friday 12 January 2007 19:19, Martin v. Löwis wrote:
Georg Brandl schrieb:
It has always been planned that in those cases that allow it,
the new way to do it will be introduced in a 2.x release too,
and the old way removed only in 3.x.
What does that mean for the example James gave: if
Georg Brandl [EMAIL PROTECTED] writes:
Armin Rigo schrieb:
Hi Paul,
On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to Py3K, I
wonder?
FWIW: Psyco.
What will PyPy do? It will certainly support compiling Py3k code
On 11 Jan, 08:22 pm, [EMAIL PROTECTED] wrote:
On 1/11/07, James Y Knight [EMAIL PROTECTED] wrote:
If the goal is really to have Py 3.0 be released later this year,
There will certainly be demand for an asynchronous server in 3.0,
To flip the question around: there might be a demand for Twisted
On 01:12 am, [EMAIL PROTECTED] wrote:
On Friday 12 January 2007 06:09, James Y Knight wrote:
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to
Py3K, I wonder?
I certainly can't speak for the project as a
On 07:56 am, [EMAIL PROTECTED] wrote:
Additionally, without a 2.x-3.x upgrade path 3.x is essentially a
new language, having to build a new userbase from scratch. Worse
yet, 2.x will suffer as people have the perception Python 2?
That's a dead/abandoned language
It's worse than that. This
On 10:12 am, [EMAIL PROTECTED] wrote:
For practical reasons (we have enough work to be getting on with) PyPy
is more-or-less ignoring Python 2.5 at the moment. After funding and
so on, when there's less pressure, maybe it will seem worth it. Not
soon though.
I think I know what you mean from
On Friday 12 January 2007 21:42, [EMAIL PROTECTED] wrote:
If the plan is to provide a smooth transition, it would help a
lot to have this plan of foward and backward compatibility
documented somewhere very public. It's hard to find information
on Py3K right now, even if you know your way
On 11:22 am, [EMAIL PROTECTED] wrote:
FWIW, I also agree with James that Python 3 shouldn't even be
released until the 2.x series has reached parity with its feature
set. However, if there's continuity in the version numbers
instead of the release dates, I can at least explain to Twisted
Martin v. Löwis schrieb:
Georg Brandl schrieb:
If Python 3.0 was simply a release which removed deprecated features,
there would clearly be no issue. I would update my code in advance of
the 3.0 release to not use any of those features being removed, and
I'm all set. But that's not what
Hi,
currently, changes in the trunk are merged to the p3yk branch.
What about changes such as the discussed -3 warn option, or __future__
imports for stuff that'll be in 3k anyway?
Can/should these revisions just be excluded from the merge? Or would
it be better to apply them to a new branch?
AFAIK Thomas just excludes these from the merge, or occasionally (if
they make it through) they will be eradicated in the p3yk branch, and
then they'll be excluded from future merges of related changes (since
those would be flagged as conflict).
On 1/12/07, Georg Brandl [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote:
Well, that is one of the cases in which that won't be possible ;)
I think there will be at least three areas that will make porting a
challenge:
- - APIs where the semantics have changed instead
On 1/12/07, Guido van Rossum [EMAIL PROTECTED] wrote:
AFAIK Thomas just excludes these from the merge,
Indeed I would.
or occasionally (if
they make it through) they will be eradicated in the p3yk branch, and
then they'll be excluded from future merges of related changes (since
those would
Ron Adam wrote:
I thinking that the 3.0.X version be considered a try it out (alpha) release
to
generate plenty of feed back, and the 3.1.X version be the first version
meant
for actual development use.
+1 for this approach.
I think it's very clear, and everybody will understand it
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
At 11:59 AM 1/12/2007 +, [EMAIL PROTECTED] wrote:
In order to do this, everything that has been changed in 3.0 has to have
some mechanism for working both ways in some 2.x release. I phrased this
as its feature set because I am not aware of any new functionality in
3.0 that simply isn't
Forwarded for discussion from http://www.python.org/sf/1633665.
--amk
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
Why not file()? Currently, file(open(something,
On 1/12/07, Facundo Batista [EMAIL PROTECTED] wrote:
Ron Adam wrote:
I thinking that the 3.0.X version be considered a try it out (alpha)
release to
generate plenty of feed back, and the 3.1.X version be the first version
meant
for actual development use.
+1 for this approach.
I
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 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
Forwarded for discussion from http://www.python.org/sf/1633665.
--amk
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et
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 1/12/07, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote:
Well, that is one of the cases in which that won't be possible ;)
I think there will be at least three areas that will make porting a
On 1/12/07, Steven Bethard [EMAIL PROTECTED] wrote:
Yeah, when this was talked about last time, I wrote PEP 3002 which
requests exactly this:
http://www.python.org/dev/peps/pep-3002/
It basically proposes that all backwards-incompatible changes be
discussed in a PEP somewhere, and that
ISTM, we can decide to limit 3.0's impact to a single compatibility module,
essentially as an alternate set of builtins.
import __new_builtins__
for name in 'bytes dict coerce'.split(): # list any new features you want
to support
setattr(__builtins__, name, getattr(__new_builtins__,
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
On 1/12/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
ISTM, we can decide to limit 3.0's impact to a single compatibility module,
essentially as an alternate set of builtins.
import __new_builtins__
for name in 'bytes dict coerce'.split(): # list any new features you want
to support
Georg Brandl wrote:
Martin v. Löwis schrieb:
What does that mean for the example James gave: if dict.items is
going to be an iterator in 3.0, what 2.x version can make it return
an iterator, when it currently returns a list?
There simply can't be a 2.x version that *introduces* the new
On 09:04 pm, [EMAIL PROTECTED] wrote:
I'm wondering if we might be going the wrong way about warning about
compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0
alpha had a 2.x compatibility mode command-line flag, which is removed late
in the beta cycle.
Please, no.
I don't
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
On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
On 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
I'm not sure I understand the use case; I don't believe I've
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
On 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
Forwarded for discussion from http://www.python.org/sf/1633665.
--amk
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et
On 12:37 am, [EMAIL PROTECTED] wrote:
For security reasons I might be asking for file's constructor to be
removed from the type for Python source code at some point (it can be
relocated to an extension module if desired). By forcing people to go
through open() to create a file object you can
On 1/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 12:37 am, [EMAIL PROTECTED] wrote:
For security reasons I might be asking for file's constructor to be
removed from the type for Python source code at some point (it can be
relocated to an extension module if desired). By forcing
On 02:42 am, [EMAIL PROTECTED] wrote:
Wrapper around open() that does proper checking of its arguments. I
will be discussing my security stuff at PyCon if you are attending and
are interested.
I am both, so I guess I'll see you there :).
___
Jack Jansen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
|
| On 12-Jan-2007, at 19:01 , Guido van Rossum wrote:
|
| On 1/12/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
| Many types in Python are idempotent, so that int(1) works
| as expected, float(2.34)==2.34,
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
Patch / Bug Summary
___
Patches : 421 open ( +3) / 3530 closed ( +8) / 3951 total (+11)
Bugs: 963 open ( +4) / 6426 closed (+21) / 7389 total (+25)
RFE : 255 open ( +5) / 246 closed ( +1) / 501 total ( +6)
New / Reopened Patches
__
The
45 matches
Mail list logo
