Hi!
David Scherer on idle-dev@python.org:
[...]
> in the interpreter* is fast. In principle, one could put THREE operators in
> the language: one with the new "float division" semantics, one that divided
> only integers, and a "backward compatibility" operator with EXACTLY the old
> semantics:
[...]
> An outline of what I did:
[...]
Yes, this really clever. I like the ideas.
[me]:
> > 2. What should the new Interpreter do, if he sees a source file without a
> > pragma defining the language level? There are two possibilities:
[...]
> > 2. Assume, it is a new source file and apply language level 2 to it.
> > This has the disadvantage, that it will break any existing code.
> I think the answer is 2. A high-quality script for adding the pragma to
> existing files, with CLI and GUI interfaces, should be packaged with Python.
> Running it on your existing modules would be part of the installation
> process.
Okay. But what is with the Python packages available on
the Internet? May be the upcoming dist-utils should handle this?
Or should the Python core distribution contain a clever installer
program, which handles this?
> Long-lived modules should always have a language level, since it makes them
> more robust against changes and also serves as documentation. A version
> statement could be encouraged at the top of any nontrivial script, e.g:
>
> python 1.6
[...]
global python_1_5 #implies global old_division
or
global python_1_6 #implies global old_division
or
global python_1_7 #may be implies global new_division
may be we can solve another issue just discussed on python_dev with
global source_iso8859_1
or
global source_utf_8
Cute idea... but we should keep the list of such pragmas short.
> Personally, I think that it makes more sense to talk about ways to
> gracefully migrate individual changes into the language than to put off
> every backward-incompatible change to a giant future "flag day" that will
> break all existing scripts. Versioning of some sort should be encouraged
> starting *now*, and incorporated into 1.6 before it goes final.
Yes.
> Indeed, but Guido has spoken:
>
> > Great ideas there, Bruce! I hope you will post these to an
> > appropriate mailing list (perhaps idle-dev, as there's no official SIG
> > to discuss the Python 3000 transition yet, and python-dev is closed).
May be someone can invite you into 'python-dev'? However the archives
are open to anyone and writing to the list is also open to anybody.
Only subscription is closed. I don't know why.
Regards, Peter
P.S.: Redirected Reply-To: to David and python-dev@python.org !
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
David Scherer on idle-dev@python.org:
[...]
> in the interpreter* is fast. In principle, one could put THREE operators in
> the language: one with the new "float division" semantics, one that divided
> only integers, and a "backward compatibility" operator with EXACTLY the old
> semantics:
[...]
> An outline of what I did:
[...]
Yes, this really clever. I like the ideas.
[me]:
> > 2. What should the new Interpreter do, if he sees a source file without a
> > pragma defining the language level? There are two possibilities:
[...]
> > 2. Assume, it is a new source file and apply language level 2 to it.
> > This has the disadvantage, that it will break any existing code.
> I think the answer is 2. A high-quality script for adding the pragma to
> existing files, with CLI and GUI interfaces, should be packaged with Python.
> Running it on your existing modules would be part of the installation
> process.
Okay. But what is with the Python packages available on
the Internet? May be the upcoming dist-utils should handle this?
Or should the Python core distribution contain a clever installer
program, which handles this?
> Long-lived modules should always have a language level, since it makes them
> more robust against changes and also serves as documentation. A version
> statement could be encouraged at the top of any nontrivial script, e.g:
>
> python 1.6
[...]
global python_1_5 #implies global old_division
or
global python_1_6 #implies global old_division
or
global python_1_7 #may be implies global new_division
may be we can solve another issue just discussed on python_dev with
global source_iso8859_1
or
global source_utf_8
Cute idea... but we should keep the list of such pragmas short.
> Personally, I think that it makes more sense to talk about ways to
> gracefully migrate individual changes into the language than to put off
> every backward-incompatible change to a giant future "flag day" that will
> break all existing scripts. Versioning of some sort should be encouraged
> starting *now*, and incorporated into 1.6 before it goes final.
Yes.
> Indeed, but Guido has spoken:
>
> > Great ideas there, Bruce! I hope you will post these to an
> > appropriate mailing list (perhaps idle-dev, as there's no official SIG
> > to discuss the Python 3000 transition yet, and python-dev is closed).
May be someone can invite you into 'python-dev'? However the archives
are open to anyone and writing to the list is also open to anybody.
Only subscription is closed. I don't know why.
Regards, Peter
P.S.: Redirected Reply-To: to David and python-dev@python.org !
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)