Hi,
now I have a good reason for 2.8. I would like to:
- switch compilers on windows to VS2010
- only add features if they are in Python3 as well
- maybe remove bsddb (because 3.x tossed it)
I am working right now with a windows 2.7 version that I modified for
VS2010,
but life would be much easier if we decide to make the compiler
transition.
Because no official 2.8 will exist, this is a fine move.
Also I struggled quite a lot buildin pywin32 for it. With 2.8, this will
need
no new special version, but the transition can be very easily done.
pywin32 decides by
# vs2008 or vs2010
if sys.hexversion < 0x3030000:
which could become
# vs2008 or vs2010
if sys.hexversion < 0x2080000 or sys.hexversion in
xrange(0x3000000, 0x3030000):
And python 2.8 without stackless is implicitly possible by defining
STACKLESS_OFF ;-)
Any objections?
all the best - Chris
On 06.11.13 21:03, Anselm Kruis wrote:
Hi,
I agree, that we should continue to support Python 2. Our customers
operate large data centers and implement processes using python 2.
They won't migrate this code unless there is a very compelling (=
saves money) reason.
As long as the PSF releases new versions of Python 2.7, we should
follow the 2.7 release cycle. This way we can guarantee that Stackless
2.7.x is compatible to C-Python 2.7.x. After the last C-Python
release, we can continue to add bug fixes and support for new
platforms or OS versions.
About a Stackless 2.8: I like the idea, but we should keep a tight
rein on it and only accept back-ports of features already in
(Stackless-) Python 3.x. Otherwise we won't be able to keep a
reasonable quality. And nobody will use a Stackless 2.8, if there is
no reasonable migration path to (stackless) python 3.x. But if we add
proven 3.x features, a stackless 2.8 could become an attractive option
on the way to python 3.
About Stackless 3.x: new features - except stackless related ones -
should go to C-Python. We don't have enough resources to keep up the
quality of the code and - more important - nobody will accept a
stackless based solution, if stackless becomes an esoteric and
incompatible fork of Python.
Regards
Anselm
Am 31.10.2013 14:16, schrieb Kristján Valur Jónsson:
Fair enough.
How hard are those to set up?
2.8-slp could be branched off when we feel like it.
I could be an enhanced 2.7 with the added benefit of having slp.
There would be no stackless-less 2.8 :)
Of course it will be an absolute bastard in terms of featuritis
unless we keep a tight rein on it :)
K
-----Original Message-----
From: [email protected] [mailto:stackless-
[email protected]] On Behalf Of Richard Tew
Sent: 30. október 2013 18:14
To: The Stackless Python Mailing List
Subject: Re: [Stackless] Fwd: [Stackless-checkins] stackless
(2.7-slp): add a
filter function to zipfile.PyZipFile.
No, let me be clear. I do not have an opinion about the source
control.
I am suggesting that Stackless-related discussion stay on this
mailing list. It is
a general topic that covers 2.x and 3.x and does not relate to
enhancing the
2.x line.
And that Python 2.x development go on another mailing list.
Hi,
now I have a good reason for 2.8. I would like to:
- switch compilers on windows to VS2010
- only add features if they are in Python3 as well
- maybe remove bsddb (because 3.x tossed it)
I am working right now with a windows 2.7 version that I modified for
VS2010,
but life would be much easier if we decide to make the compiler
transition.
Because no official 2.8 will exist, this is a fine move.
Also I struggled quite a lot buildin pywin32 for it. With 2.8, this will
need
no new special version, but the transition can be very easily done.
pywin32 decides by
# vs2008 or vs2010
if sys.hexversion < 0x3030000:
which could become
# vs2008 or vs2010
if sys.hexversion < 0x2080000 or sys.hexversion in
xrange(0x3000000, 0x3030000):
And python 2.8 without stackless is implicitly possible by defining
STACKLESS_OFF ;-)
Any objections?
all the best - Chris
On 06.11.13 21:03, Anselm Kruis wrote:
Hi,
I agree, that we should continue to support Python 2. Our customers
operate large data centers and implement processes using python 2.
They won't migrate this code unless there is a very compelling (=
saves money) reason.
As long as the PSF releases new versions of Python 2.7, we should
follow the 2.7 release cycle. This way we can guarantee that Stackless
2.7.x is compatible to C-Python 2.7.x. After the last C-Python
release, we can continue to add bug fixes and support for new
platforms or OS versions.
About a Stackless 2.8: I like the idea, but we should keep a tight
rein on it and only accept back-ports of features already in
(Stackless-) Python 3.x. Otherwise we won't be able to keep a
reasonable quality. And nobody will use a Stackless 2.8, if there is
no reasonable migration path to (stackless) python 3.x. But if we add
proven 3.x features, a stackless 2.8 could become an attractive option
on the way to python 3.
About Stackless 3.x: new features - except stackless related ones -
should go to C-Python. We don't have enough resources to keep up the
quality of the code and - more important - nobody will accept a
stackless based solution, if stackless becomes an esoteric and
incompatible fork of Python.
Regards
Anselm
Am 31.10.2013 14:16, schrieb Kristján Valur Jónsson:
Fair enough.
How hard are those to set up?
2.8-slp could be branched off when we feel like it.
I could be an enhanced 2.7 with the added benefit of having slp.
There would be no stackless-less 2.8 :)
Of course it will be an absolute bastard in terms of featuritis
unless we keep a tight rein on it :)
K
-----Original Message-----
From: [email protected] [mailto:stackless-
[email protected]] On Behalf Of Richard Tew
Sent: 30. október 2013 18:14
To: The Stackless Python Mailing List
Subject: Re: [Stackless] Fwd: [Stackless-checkins] stackless
(2.7-slp): add a
filter function to zipfile.PyZipFile.
No, let me be clear. I do not have an opinion about the source
control.
I am suggesting that Stackless-related discussion stay on this
mailing list. It is
a general topic that covers 2.x and 3.x and does not relate to
enhancing the
2.x line.
And that Python 2.x development go on another mailing list.
--
Christian Tismer :^)<mailto:[email protected]>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship*http://starship.python.net/
14482 Potsdam : PGP key ->http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today?http://www.stackless.com/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless