On Mon, Oct 6, 2008 at 7:47 PM, Barry Warsaw barry@python.org wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

So, we need to come up with a new release schedule for Python 3.0. My suggestion:

15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 rc 2 19-Nov-2008 3.0 rc 3 03-Dec-2008 3.0 final

Given what still needs to be done, is this a reasonable schedule? Do we need two more betas?

I'm not sure we do. Correct me if I'm wrong, but the "big ticket", issue bytes/unicode filepaths, has been resolved. And looking at the tracker, I only see 18 release blockers.

-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Oct 6, 2008, at 9:48 PM, Raymond Hettinger wrote:

[Barry Warsaw]

...

So, we need to come up with a new release schedule for Python 3.0.
My suggestion: 15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 rc 2 19-Nov-2008 3.0 rc 3 03-Dec-2008 3.0 final Given what still needs to be done, is this a reasonable schedule?
Do we need two more betas?

Yes to both questions.

I think that's contradictory :). If we need two betas, then 05-Nov
becomes beta 5, 19-Nov is rc 2. If we don't need another rc then we
can still do a final release on 03-Dec, otherwise we probably go 2
weeks later. I don't want to go much later than that though because
then we get into the holiday season.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOrFs3EjvBPtnXfVAQJceQP/QJN7oLM4nG+iXmgdb0NmKzOzaE3J89sQ UWZnc/hp618QNH4JWC8v2bYApFu+iVg3pcv1Lnmhuql6mOuDhSuKKJVA5jTdR7U2 2enhAEY2DXtmav/29nn2Fy6PYcWJy9pE2xBsbBW8qXc6tYww0iEBsz9SU68jPzPk x5LFC5NqmXo= =Kyr4 -----END PGP SIGNATURE-----

On Tue, Oct 07, 2008 at 09:20:23AM -0300, Facundo Batista wrote:

I don't want to keep deferring 3.0 months and months, I prefer to have a redesigned schedule now, and stick to it as much as possible, even if the 3.0 version is not as robust as we would want.

Another, related policy issue: must 3.1 be compatible with 3.0? Or is 3.0 an experimental version in some respects (for example, the stdlib) and 3.1 the 'final' version?

--amk

More specifically, I think 2to3 is shaping up well. pywin32 is taking the approach of "port where possible, but keep in py2x syntax and convert at 'setup.py' time" and this is working out fairly well

I can't say how glad I am that you say that. It supports lib2to3 being a proper library, despite the problems that this may cause in itself.

• Better support for 2to3 in distutils (specifically, the support in build_py is stale, plus 'build_scripts' and 'install_data' should convert .py files to py3k syntax.)

Please do create a bug report for that. It sounds like it's easy to fix.

An 'example' project that uses py2k syntax and "just works" on py3k using this strategy might be useful here.

Perhaps pywin32 :-?

I don't think a demo project would do much good, as it doesn't exercise all the issues that may occur.

• A standard 'helper script' that allows people to use py3k to execute a py2x syntax script by auto-converting the code. I've a 10ish-line script that uses lib2to3 plus exec() to achieve that result, but a helper in 2to3 for this would be nice. For a concrete use-case, we want to keep our distutils script in py2x syntax, but execute it via py3k. Its very possible this already exists and I've just missed it...

For the case of setup.py, I was hoping that it could be written in compatible syntax even without needing conversion. That worked fine for my Django port. Is that not the case for pywin32?

This specific issue might be out of scope for 3.x, IMO.

Either way, I'm fairly confident a pywin32 build for py3k will be available in the next month or 2 (but as a result, I'm not really in a position to help with the above for that period...)

But please do file bug reports, preferably along with any patches to distutils that you already have.

Regards, Martin

Barry Warsaw wrote:

On Oct 6, 2008, at 9:48 PM, Raymond Hettinger wrote:

...

[Barry Warsaw]

...

So, we need to come up with a new release schedule for Python 3.0. My suggestion: 15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 rc 2 19-Nov-2008 3.0 rc 3 03-Dec-2008 3.0 final Given what still needs to be done, is this a reasonable schedule? Do we need two more betas?

...

Yes to both questions.

I think that's contradictory :). If we need two betas, then 05-Nov becomes beta 5, 19-Nov is rc 2. If we don't need another rc then we can still do a final release on 03-Dec, otherwise we probably go 2 weeks later. I don't want to go much later than that though because then we get into the holiday season.

Do we need the full two weeks between rc's? Or is it too much of a pain to cut releases 3 weeks in a row?

E.g. something like:

15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 beta 5 19-Nov-2008 3.0 rc 2 26-Nov-2008 3.0 rc 3 (if needed) 03-Dec-2008 3.0 final

Cheers, Nick.

Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/ncoghlan%40gmail.com

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

        http://www.boredomandlaziness.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:

On Mon, Oct 6, 2008 at 5:47 PM, Barry Warsaw barry@python.org wrote:

...

So, we need to come up with a new release schedule for Python 3.0.
My suggestion:

15-Oct-2008 3.0 beta 4 05-Nov-2008 3.0 rc 2 19-Nov-2008 3.0 rc 3 03-Dec-2008 3.0 final

Given what still needs to be done, is this a reasonable schedule?
Do we need two more betas?

I know I'm contradicting what I said earlier, but perhaps we should just forget going back to beta and stick to ever-more-perfect release candidates? In other worlds release candidates often contain tons of imperfections (I believe I've seen this both for Java and Windows) and the label "release candidate" more clearly encourages people to download and play with it, which is what we need at this point! Then the schedule would be something like

15-Oct-2008 3.0 rc 2 05-Nov-2008 3.0 rc 3 19-Nov-2008 3.0 rc 4 03-Dec-2008 3.0 final

I'm okay with that too. It does seem odd to go back to beta then
release another rc. What's in a name, anyway? <wink>. And it is good
that more people are downloading it now that it's rc.

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOvb93EjvBPtnXfVAQJTQAP/cmNdzd/SRymxXvW85EnW2NTHUkh1Auw9 bGlbSC0BF2p9ArgbDLPh/X4uatB3UaqoNeq5LTWHL2f9iCnsI7lFMPuexGr+3t4l Xmld8qN77j4GpU6bXL8uUo3/vlhU4MiG5ETl0kMH30f47srOAAGEGZAqW9jAM92I YSkQPSgBdYo= =+s9t -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Oct 7, 2008, at 4:28 PM, Guido van Rossum wrote:

15-Oct-2008 3.0 rc 2 05-Nov-2008 3.0 rc 3 19-Nov-2008 3.0 rc 4 03-Dec-2008 3.0 final

I've updated PEP 361 and the Google calendar with this schedule,
except that the PEP says that rc3 and rc4 are planned "if needed".

• -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOvfg3EjvBPtnXfVAQKDfwP/Sz9Ioe1tIrKtvD7JPG2cg2F+wfDJrc+9 vqfh6/eMWiUIOeSKJu6+gye7oXRcHwQXAPivNza3993HesOu0TjudnwXfkAlfsdE m09Rh70AXQQiY7JX46etugRC4BwkuNeBo253cvmfo6hPK0ZhOHZSy3H1LkhvvLA6 Cq56CVqDUgs= =i/Km -----END PGP SIGNATURE-----

...

• Better support for 2to3 in distutils (specifically, the support in build_py is stale, plus 'build_scripts' and 'install_data' should convert .py files to py3k syntax.)

Please do create a bug report for that. It sounds like it's easy to fix.

Yeah, build_py is fairly easy to fix, but I also needed to extend the support to build_scripts and install_data. In addition, some already reported bugs in 2to3 mean that some files fail to convert, and this breaks the entire process - so as a result I ended up duplicating lib2to3's 'refactor_items()' but with exceptions being logged and ingored rather than aborting the process. Oh - and I deleted the .bak files (a copy of the sources are converted, not the sources themselves)

Please see bugs 4072 and 4073 - but as mentioned below, the lack of a test case means I didn't supply a tested patch.

...

An 'example' project that uses py2k syntax and "just works" on py3k using this strategy might be useful here.

Perhaps pywin32 :-?

I don't think a demo project would do much good, as it doesn't exercise all the issues that may occur.

My idea was that the demo project would simply demonstrate the 2to3 concepts that such a project could use. pywin32 isn't a good example as it has a very non-trivial setup.py and a large set of C extensions (the demo I had in mind could avoid C extensions completely - C developers will already assume #ifdef will be their friend, but .py code is the unknown...)

It would basically be a 'distutils demo', could have a single .py module and a single .py script. setup.py would support both 2.x and 3.x and would demonstrate how the source is converted to py3k syntax before it is installed into the py3k distribution.

It would also provide a useful test case - eg, for the distutils bug above, I'm not sure how I can (a) demonstrate it is currently broken and (b) demonstrate a patch corrects the problem.

...

• A standard 'helper script' that allows people to use py3k to execute a py2x syntax script by auto-converting the code. I've a 10ish-line script that uses lib2to3 plus exec() to achieve that result, but a helper in 2to3 for this would be nice. For a concrete use-case, we want to keep our distutils script in py2x syntax, but execute it via py3k. Its very possible this already exists and I've just missed it...

For the case of setup.py, I was hoping that it could be written in compatible syntax even without needing conversion. That worked fine for my Django port. Is that not the case for pywin32?

setup.py catches and examines some exceptions. Consider the more general case though - pywin32 has a number of tests all of which will also be maintained in py2x syntax. It is extremely convenient to be able to execute:

% py3k run2.py my_test.py etc

And have 'my_test.py' (which is 2.x syntax) be executed directly by py3k without doing a full 'setup.py install' or manually invoking 2to3 via a temp file, etc. As mentioned, 'run2.py' is quite short and just uses lib2to3+exec, but I'm not sure everyone will work out how to roll their own...

Specifically, I believe that a script with similar capabilities could be installed with py3k in the "scripts" directory and it advertised as a reasonable way to directly execute your *scripts* which, although py3x compatible, are being maintained in py2x syntax. Below is my quick attempt at such a script, which I promptly stopped looking at as soon as it worked (ie, I'm not sure if all those options are needed, etc), but it does let me execute my tests using py3k directly from the source tree.

Cheers,

Mark

# This is a Python 3.x script to execute a python 2.x script by 2to3'ing it. import sys from lib2to3.refactor import RefactoringTool, get_fixers_from_package

fixers = get_fixers_from_package('lib2to3.fixes') options = dict(doctests_only=False, fix=[], list_fixes=[], print_function=False, verbose=False, write=True) r = RefactoringTool(fixers, options) script = sys.argv[1] data = open(script).read() print("Converting...") got = r.refactor_string(data, script) print("Executing...") # nuke ourselves from argv del sys.argv[1] exec(str(got))

On 10/7/08, Mark Hammond mhammond@skippinet.com.au wrote:

# This is a Python 3.x script to execute a python 2.x script by 2to3'ing it. import sys from lib2to3.refactor import RefactoringTool, get_fixers_from_package

fixers = get_fixers_from_package('lib2to3.fixes') options = dict(doctests_only=False, fix=[], list_fixes=[], print_function=False, verbose=False, write=True)

Note that only the print_function option is used.

r = RefactoringTool(fixers, options) script = sys.argv[1] data = open(script).read() print("Converting...") got = r.refactor_string(data, script) print("Executing...") # nuke ourselves from argv del sys.argv[1] exec(str(got))

---

python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers

-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."