Re: [Python-Dev] Python 3 design principles
Collin Winter wrote: > Am 31-Aug 05, Charles Cazabon <[EMAIL PROTECTED]> schrieb: > > >>Perhaps py3k could have a py2compat module. Importing it could have the >>effect of (for instance) putting compile, id, and intern into the global >>namespace, making print an alias for writeln, alias the standard library >>namespace, ... ? > > > from __past__ import python2 If we ever get the ast-branch finished, then keeping a copy of the final 2.x parser around that targets the Python AST should actually be feasible, too. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On 2005-09-01, Ron Adam <[EMAIL PROTECTED]> wrote:
> As for functions without '()'s. (Just a thought) You could use '<<' or
> '<<<' (or other symbol) as a way to move data between objects.
>
> ui.write <<< 'Hello World/n' # ui.write('Hello World/n')
>
> ui.writeln <<< counter# ui.writeln(counter.next())
>
> ok = ui.input <<< 'press a key:' # ok = ui.input('press a key:')
>
> The requirement could be that the item on the left is a callable, and
> the item on the right is a sequence or generator.
>
Please don't abuse symbols. Perl's ways of symbols all the way without
intuitive meaning is bad. Use descriptive methods and functions please.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On Thursday 01 September 2005 23:00, [EMAIL PROTECTED] wrote: > Then why remove it at all? Bingo. I don't see any need to remove it. I could live with removing the trailing-comma semi-wart, but there just isn't any need to remove it. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
>> I still hope to see this change to "make print a builtin instead of a >> statement". I'd hate to lose the one-line hello world example due to >> cruft like "from sys import stdout". Barry> I agree. You can't get much simpler to explain or use than the Barry> current print statement. Then why remove it at all? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Reinhold Birkenfeld wrote: > Greg Ewing wrote: > >>There's no way importing a module could add something that >>works like the old print statement, unless some serious >>magic is going on... > > You'd have to enclose print arguments in parentheses. Of course, the "trailing > comma" form would be lost. But you'd still have to rewrite old code to work with it, in which case you might as well change it to whatever the new way is in 3.0. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>Charles Cazabon wrote:
>>
>>
>>>Perhaps py3k could have a py2compat module. Importing it could have the
>>>effect of (for instance) putting compile, id, and intern into the global
>>>namespace, making print an alias for writeln,
>>
>>There's no way importing a module could add something that
>>works like the old print statement, unless some serious
>>magic is going on...
>
>
> You'd have to enclose print arguments in parentheses. Of course, the "trailing
> comma" form would be lost.
>
> Reinhold
The trailing comma is convenient, but I don't think it's that big of a
deal to have two methods.
ui.write()
ui.writeln() # or ui.print()
I'm +1 on making it a method of a "user interface object". Not just a
function.
I want to be able to import an interface, then communicate to it in a
consistent way even though it may look quite different on the screen.
Having a set of standard io methods moves in that direction I think.
import console
ui = console()
ui.write("Hello World\n")
howami = ui.input("How are you today? %s")
import popup
ui = popup('YesNo') # Create a 'YesNo' popup.
ok = ui.input('Ok to proceed?') # Open it and wait for it.
ok2 = ui.input('Are you sure?') # Reopen it and reuse it.
if ok == ok2 == 'Yes':
...
Some possible common methods...
ui.write(data)# non blocking print/output, doesn't wait
ui.send() # non echo write; passwords, config, etc..
ui.input(prompt) # output something and wait for return value
ui.get() # non echo wait for value, or io.next()
ui.read() # non blocking get
As for functions without '()'s. (Just a thought) You could use '<<' or
'<<<' (or other symbol) as a way to move data between objects.
ui.write <<< 'Hello World/n' # ui.write('Hello World/n')
ui.writeln <<< counter# ui.writeln(counter.next())
ok = ui.input <<< 'press a key:' # ok = ui.input('press a key:')
The requirement could be that the item on the left is a callable, and
the item on the right is a sequence or generator.
Cheers,
Ron
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On 9/1/05, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > I'm all for removing the cruft in python 3, and giving it a bit of a > spring clean, but please, please don't make it feel like a different > language otherwise the users will be deserting in droves (no-one likes > to be told that they've been using the wrong language for all these > years). IMO it won't feel like a different language; syntactically, the most far-fetched change is probably dropping the print statement (on which I just opened a new thread). > If come python 3, there is a 99% accurate program which can turn your > python 2.x into python 3 code, then that would ease the transition > greatly. That might not be so easy given the desire to change most list-returning functions and methods into iterator-returning ones. This means that *most* places where you use keys() your code will still run, but *some* places you'll have to write list(d.keys()). How is the translator going to know? Worse, there's a common idiom: L = D.keys() L.sort() that should be replaced by L = sorted(D) how is the translator going to recognize that (given that there are all sorts of variations)? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On Thu, 2005-09-01 at 05:54, Nick Coghlan wrote: > Oren Tirosh wrote: > > * Replacing print with write/writeln > > I still hope to see this change to "make print a builtin instead of a > statement". I'd hate to lose the one-line hello world example due to cruft > like "from sys import stdout". I agree. You can't get much simpler to explain or use than the current print statement. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On Thu, Sep 01, 2005 at 08:55:48AM +0200, Kay Schluehr wrote: > The idea of forking a language with a new release and thereby > deevaluating older code seems somewhat archaic to me. Or the other way > round: archaic materials and media like papyrus and scripture enabled > communication across centurys changing slightly evolutionary and > continously. Form this point of view PL development is still in a state > of modernistic, youthfull irresponsibility. I mostly agree with that. For me personally, one of the big reasons for jumping ship from perl to python (a considerable investment in time and effort) was to avoid perl 6. Its been clear for a long time that perl 6 will be completely different to perl 5, thus making perl 5 an evolutionary dead end. Yes I know about the perl 5 on perl 6 stuff - but who wants to program in a dead language? I'm all for removing the cruft in python 3, and giving it a bit of a spring clean, but please, please don't make it feel like a different language otherwise the users will be deserting in droves (no-one likes to be told that they've been using the wrong language for all these years). If come python 3, there is a 99% accurate program which can turn your python 2.x into python 3 code, then that would ease the transition greatly. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Oren Tirosh wrote: > * Replacing print with write/writeln I still hope to see this change to "make print a builtin instead of a statement". I'd hate to lose the one-line hello world example due to cruft like "from sys import stdout". Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Oren Tirosh wrote: > Python 3 will most probably make big changes in the internal > implementation and the C API. Perhaps it will even be generated from > PyPy. Don't you think the current Python 3 "visions" becomes rather pointless with the raise of PyPy and interpreter extensions that are developed polymorphically? If the distinction between a user defined package and a language extension becomes more or less irrelevant who needs a language design committee for it's control? If someone takes the Python core in order to implement static typing it might be happen and run in a separate object space. But than, I'm almost sure, it won't be an ill-defined concept like "optional static typing" but Hindley-Milnor ( or a generalization ) which restricts dynamicity but enables type safety and static control otherwise. The idea of forking a language with a new release and thereby deevaluating older code seems somewhat archaic to me. Or the other way round: archaic materials and media like papyrus and scripture enabled communication across centurys changing slightly evolutionary and continously. Form this point of view PL development is still in a state of modernistic, youthfull irresponsibility. > I don't think keeping the common subset will really stand in the way > of making big improvements. The proposed 3.x changes that break it > seem more like nitpicking to me than significant improvements. So it seems. Kay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Greg Ewing wrote: > Charles Cazabon wrote: > >> Perhaps py3k could have a py2compat module. Importing it could have the >> effect of (for instance) putting compile, id, and intern into the global >> namespace, making print an alias for writeln, > > There's no way importing a module could add something that > works like the old print statement, unless some serious > magic is going on... You'd have to enclose print arguments in parentheses. Of course, the "trailing comma" form would be lost. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On 9/1/05, Robert Kern <[EMAIL PROTECTED]> wrote: > Oren Tirosh wrote: > > > While a lot of existing code will break on 3.0 it is still generally > > possible to write code that will run on both 2.x and 3.0: use only the > > "proper" forms above, do not assume the result of zip or range is a > > list, use absolute imports (and avoid static types, of course). I > > already write all my new code this way. > > > > Is this "common subset" a happy coincidence or a design principle? > > I think it's because those are the most obvious things right now. The > really radical stuff won't come up until active development on Python > 3000 actually starts. And it will, so any "common subset" will probably > not be very large. Static typing is radical stuff and doesn't hurt the common subset since it's optional. Making unicode the default is pretty radical and can be done without breaking the common subset (with the help of little tweaks like allowing str() to return unicode now like int() can return longs). Iterators and new-style classes were pretty radical changes that were managed elegantly and meet an an even stronger requirement than the common subset - they were achieved with full backward compatibility. Python 3 will most probably make big changes in the internal implementation and the C API. Perhaps it will even be generated from PyPy. I don't think keeping the common subset will really stand in the way of making big improvements. The proposed 3.x changes that break it seem more like nitpicking to me than significant improvements. Python is terrific. I find nothing I really want to change. Remove old cruft and add some brand new stuff, yes. But nothing to change. Oren ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Charles Cazabon wrote: > Perhaps py3k could have a py2compat module. Importing it could have the > effect of (for instance) putting compile, id, and intern into the global > namespace, making print an alias for writeln, There's no way importing a module could add something that works like the old print statement, unless some serious magic is going on... Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On Aug 31, 2005, at 5:00 PM, Robert Kern wrote: > IMO, if we are going to restrict Python 3000 enough to protect that > "common subset," then there's not enough payoff to justify breaking > *any* backwards compatibility. If my current codebase[1] isn't > going to > be supported in Python 3000, I'm going to want the Python > developers to > use that opportunity to the fullest advantage to make a better > language. I disagree fully. As a maintainer in the Twisted project I very much hope that it is possible to adapt the code such that it will work on Python 3 while still maintaining compatibility with Python 2.X. Otherwise, it will be impossible to make the transition to Python 3 without either maintaining two forks of the codebase (I doubt that'll happen) or abandoning all users still on Python 2. And that surely won't happen either, for a while. Maybe by the time Python 3.1 or 3.2 comes out it'll be possible to completely abandon Python 2. I'm perfectly happy to see backwards-incompatible changes in Python 3, as long as they do not make it completely impossible to write code that can run on both Python 3 and Python 2.X. This suggests a few things to me: a) new features should be added to the python 2.x series first wherever possible. b) 3.0 should by and large by simply a feature-removal release, removing support for features already marked as going away by the end of the 2.x series and which have replacements. c) don't make any radical syntax changes which make it impossible to write code that can even parse in both versions. d) for all backwards-incompatible-change proposals, have a section dedicated to compatibility and migration of old code that explains both how to modify old code to do things purely the new way, _and_ how to modify code to work under both the old and new ways. Strive to make this as simple as possible, but if totally necessary, it may be reasonable to suggest writing a wrapper function which changes behavior based on python version/existence of new methods. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Oren Tirosh wrote: > While a lot of existing code will break on 3.0 it is still generally > possible to write code that will run on both 2.x and 3.0: use only the > "proper" forms above, do not assume the result of zip or range is a > list, use absolute imports (and avoid static types, of course). I > already write all my new code this way. > > Is this "common subset" a happy coincidence or a design principle? I think it's because those are the most obvious things right now. The really radical stuff won't come up until active development on Python 3000 actually starts. And it will, so any "common subset" will probably not be very large. IMO, if we are going to restrict Python 3000 enough to protect that "common subset," then there's not enough payoff to justify breaking *any* backwards compatibility. If my current codebase[1] isn't going to be supported in Python 3000, I'm going to want the Python developers to use that opportunity to the fullest advantage to make a better language. [1] By which I mean the sum total of the code that I use not just code that I've personally written. I am a library-whore. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Am 31-Aug 05, Charles Cazabon <[EMAIL PROTECTED]> schrieb: > Perhaps py3k could have a py2compat module. Importing it could have the > effect of (for instance) putting compile, id, and intern into the global > namespace, making print an alias for writeln, alias the standard library > namespace, ... ? from __past__ import python2 Grüße, Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On 8/31/05, Oren Tirosh <[EMAIL PROTECTED]> wrote: > > Writing programs that run on both 2.x and 3 may require ugly > version-dependent tricks like: > > try: > compile > except NameError: > from sys import compile Note we can ease this process a little by making a copy without removing, e.g., adding compile to sys now without removing it. As programs support only Python 2.5+, they could use sys.compile and wouldn't need to resort to the try/except above. I realize this is only a marginal improvement. However, if we don't start making changes, we will be stuck maintain suboptimal behaviour forever. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
Oren Tirosh <[EMAIL PROTECTED]> wrote: > > Not all proposed changes remove redundancy or add completely new > things. Some of them just change the way certain things must be done. > For example: > * Moving compile, id, intern to sys > * Replacing print with write/writeln > And possibly the biggest change: > * Reorganize the standard library to not be as shallow > > I'm between +0 and -1 on these. I don't find them enough of an > improvement to break this "common subset" behavior. It's not quite the > same as strict backward compatibility and I find it worthwhile to try > to keep it. > > Writing programs that run on both 2.x and 3 may require ugly > version-dependent tricks like: > > try: > compile > except NameError: > from sys import compile Perhaps py3k could have a py2compat module. Importing it could have the effect of (for instance) putting compile, id, and intern into the global namespace, making print an alias for writeln, alias the standard library namespace, ... ? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
