Re: Misleading wikipedia article on Python 3?
Evan Klitzke wrote: You can easily modify print in a safe way. Yes, but you'd still have to replace the builtin print function with your own to get it used by non-cooperative code. That doesn't seem to gain you much over replacing sys.stdout with something that intercepts and logs stuff written to it. What do you find wrong with this sort of monkeypatching? At least sys.stdout was designed somewhat with the possibility of replacing it in mind. It's not an entirely unexpected thing to do. Replacing something in the builtin namespace seems like a more drastic step, somehow. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Evan Klitzke wrote:
On 8/8/07, greg [EMAIL PROTECTED] wrote:
Istvan Albert wrote:
A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand.
If the code has been written with calls to a builtin
print function, the situation isn't much better. You
could monkeypatch the print function, but that's
probably worse than swapping sys.stdout.
You can easily modify print in a safe way. Here's an example, that
will work in any recent version of Python:
import sys
def print_(s):
print s
def logger(method):
def wrapper(s):
sys.stderr.write('Logging: %s\n' % s)
method(s)
return wrapper
print_ = logger(print_)
print_('hello')
Running this code will do a regular print of 'hello', as well as
logging it to stderr. As a function, you can convert print wholesale
to another logging function, or wrap it transparently like this to
provide additional logging functionality. What do you find wrong with
this sort of monkeypatching?
foolish question maybe.
Why wouldn't you do it this way ?
def print_(s):
print s
def logger(m):
sys.stderr.write('Logging: %s\n' % m)
method(m)
print_ = logger(print_)
print_('hello')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On Aug 6, 6:49 am, Neil Cerutti [EMAIL PROTECTED] wrote: Incidentally, from the second link I find it shocking that the keyword parameter file shadows a builtin. It seems to endorse a bad practice. I believe that the file builtin has been removed as well so it won't shadow anything. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On Aug 6, 6:11 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Why on earth did they make this change? It just seems gratuitous. Having print a function (with parameters) makes is very easy to modify where the output goes. Say you want to have some prints go to one particular file, today you cannot easily do it, you have to either do a regex based search/ replace or fiddle with the sys.stdout etc. both have substantial drawbacks. A solution would be writing the code with a logging function to begin with, alas many times that is out of one's hand. I wished print was a function great many times. I bet Guido has had similar experiences, note that attempt to keep print in the current form but have it print to a file ... with that crazy syntax, print f, ... alas that did not solve anything It is time to fix it for good. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 8 Aug, 16:26, Istvan Albert [EMAIL PROTECTED] wrote: On Aug 6, 6:11 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Why on earth did they make this change? It just seems gratuitous. Having print a function (with parameters) makes is very easy to modify where the output goes. I'm not arguing with this. Say you want to have some prints go to one particular file, today you cannot easily do it, you have to either do a regex based search/ replace or fiddle with the sys.stdout etc. both have substantial drawbacks. Well, you could find all print statements reliably using various parsing solutions provided with Python. It's interesting that for this reason, migrating from the print statement is not particularly difficult whereas identifying invocations of the upcoming print built- in function will not be a trivial task. I'm not passing judgement on the introduction of the print function here, but I find such properties of the language very interesting - it's not too far removed from the static typing debate or people's fascination with making domain-specific languages. A solution would be writing the code with a logging function to begin with, alas many times that is out of one's hand. I wished print was a function great many times. I bet Guido has had similar experiences, note that attempt to keep print in the current form but have it print to a file ... with that crazy syntax, print f, ... alas that did not solve anything Yes, print f is a bit of a hack which I must admit to using occasionally. However, for every enthusiast of one approach, there will always be an enthusiast for another (see point #6): http://mechanicalcat.net/cgi-bin/log/2003/09/02#anti-pitfalls It is time to fix it for good. Well, it has always been possible to use a logging function, just not one called print exactly. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On Aug 8, 12:08 pm, Paul Boddie [EMAIL PROTECTED] wrote: However, for every enthusiast of one approach, there will always be an enthusiast for another (see point #6): True. For example I for one also like the way the current print adds a newline, the vast majority of the time that is exactly what I want. I don't know if this will be kept when print becomes a function (might be that some default parameters make it work the same way) Which reminds me of an experience I had when I originally learned how to program in Pascal, then moved on to C. At first it felt wrong that I had to include the \n to print a new line at the end, seemed unreadable (Pascal had separate functions: write and a writeln for it). Today I'd consider it appallingly bad design to have separate functions for such a small difference. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 2007-08-08, Istvan Albert [EMAIL PROTECTED] wrote: On Aug 6, 6:49 am, Neil Cerutti [EMAIL PROTECTED] wrote: Incidentally, from the second link I find it shocking that the keyword parameter file shadows a builtin. It seems to endorse a bad practice. I believe that the file builtin has been removed as well so it won't shadow anything. I can't find any evidence of that in the PEPs. Do you have a reference? I thought, in fact, that open was on more shaky ground. ;) -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On Aug 8, 2:00 pm, Neil Cerutti [EMAIL PROTECTED] wrote: I thought, in fact, that open was on more shaky ground. ;) yeah, that too ... I can't find any evidence of that in the PEPs. Do you have a reference? here is something: http://svn.python.org/view/python/branches/p3yk/Misc/NEWS?rev=56685view=auto look for : - Removed these Python builtins: apply(), callable(), coerce(), file(), reduce(), reload() i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 2007-08-08, Istvan Albert [EMAIL PROTECTED] wrote: On Aug 8, 2:00 pm, Neil Cerutti [EMAIL PROTECTED] wrote: I thought, in fact, that open was on more shaky ground. ;) yeah, that too ... OK, I had misremembered. The current docs say that open is preferred, and that file should rather be used as a type name. I can't find any evidence of that in the PEPs. Do you have a reference? here is something: http://svn.python.org/view/python/branches/p3yk/Misc/NEWS?rev=56685view=auto look for : - Removed these Python builtins: apply(), callable(), coerce(), file(), reduce(), reload() Thanks very much. -- Neil Cerutti Outside of the killings, Washington has one of the lowest crime rates in the country. --Marion Barry -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Istvan Albert [EMAIL PROTECTED] writes: apply(), callable(), coerce(), file(), reduce(), reload() reduce() is really gone? Maybe itertools can get an ireduce function or something like that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 2007-08-08, Paul Rubin http wrote: Istvan Albert [EMAIL PROTECTED] writes: apply(), callable(), coerce(), file(), reduce(), reload() reduce() is really gone? Maybe itertools can get an ireduce function or something like that? I don't see how file() can be removed, actually, unless the file type itself is getting axed. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
I don't see how file() can be removed, actually, unless the file type itself is getting axed. Indeed, that's the case. Py3k won't use stdio for file input and output, but the io module. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Istvan Albert wrote: A solution would be writing the code with a logging function to begin with, alas many times that is out of one's hand. If the code has been written with calls to a builtin print function, the situation isn't much better. You could monkeypatch the print function, but that's probably worse than swapping sys.stdout. (I agree that print should be a function, simply because there's no strong reason for it *not* to be. But I don't think it makes a difference to this particular problem.) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 8/8/07, greg [EMAIL PROTECTED] wrote:
Istvan Albert wrote:
A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand.
If the code has been written with calls to a builtin
print function, the situation isn't much better. You
could monkeypatch the print function, but that's
probably worse than swapping sys.stdout.
You can easily modify print in a safe way. Here's an example, that
will work in any recent version of Python:
import sys
def print_(s):
print s
def logger(method):
def wrapper(s):
sys.stderr.write('Logging: %s\n' % s)
method(s)
return wrapper
print_ = logger(print_)
print_('hello')
Running this code will do a regular print of 'hello', as well as
logging it to stderr. As a function, you can convert print wholesale
to another logging function, or wrap it transparently like this to
provide additional logging functionality. What do you find wrong with
this sort of monkeypatching?
--
Evan Klitzke [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Carsten Haese [EMAIL PROTECTED] writes: On Sun, 2007-08-05 at 23:09 +, John J. Lee wrote: I just wanted to know: is it easy to make my code so it runs on 2.6 and 3.0, without funny stuff like a code translator? That depends on your definitions of easy and funny stuff. I'm pretty sure you'll be able to run the same source code on Python 2.6 and Python 3.0 without either one breaking, as long as the code is written sufficiently carefully. You may have to give up some Python 3.0 features and/or write compatibility shims depending on what features you'll need. Whether that's acceptable depends on the features you need and how much yak shaving you find acceptable. [...] If I had wanted to start analysing requirements for some specific project, I'd have gone and done that!-) I was actually interested in the general case (all existing projects), as perhaps you'll see if you read my original post (my followup question you quote above was deliberately blunt for rhetorical let's-move-this-discussion-along purposes -- sigh honestly, these literal-minded programmer types, what CAN you do with them?-). Do you *really* think that projects will fall 50-50 into the yes and no camps, as you seem to imply -- after all, if you thought that one case was more common, why wouldn't you mention which it was? (where yes == feasible to keep a single source code working in both 2.6 and 3.0, and of course it's taken as read that you can do the generalisation to the -- I hope -- obvious continuum of cases between yes and no without our needing to tiresomely spell it out here) I'll also add that previous comments from Guido have implied (to my reading, admittedly without studying them like biblical texts) that the great majority of projects will/should fall pretty squarely, in his judgement, into the no camp -- i.e. NOT practical to keep 2.6 and 3.0 comptibility from a single source code without use of a translation tool. Does your pretty sure-ness stem from 1) a knowledge of how 3.0 will look when it's done, 2) experience of playing with the Py3k project as it is right now or 3) other? What sort of frequencies does your understanding of Py3k predict for the yes and no cases? By all means use your skill and judgement in answering, rather than asking for clarification -- since that would rather defeat the point of the question. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Do you *really* think that projects will fall 50-50 into the yes and no camps, as you seem to imply -- after all, if you thought that one case was more common, why wouldn't you mention which it was? I know you didn't ask me this time, but I answer anyway: I don't know. I *really* think that only experience can tell, and that any kind of prediction on that matter is futile FUD (as FUD, it might be successful, of course). I do so using all my skill and judgment. Only when people actually start to try porting, list specific issues that they actually ran into (rather than listing issues they anticipate to run into), only then I can make guesses as to what the common case will be. Ask this question a year from now again. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Martin v. Löwis [EMAIL PROTECTED] writes: Do you *really* think that projects will fall 50-50 into the yes and no camps, as you seem to imply -- after all, if you thought that one case was more common, why wouldn't you mention which it was? I know you didn't ask me this time, but I answer anyway: I don't know. I *really* think that only experience can tell, and that any kind of prediction on that matter is futile FUD (as FUD, it might be successful, of course). I do so using all my skill and judgment. Only when people actually start to try porting, list specific issues that they actually ran into (rather than listing issues they anticipate to run into), only then I can make guesses as to what the common case will be. [...] By this criterion, Guido himself is engaging in FUD, as near as I can tell (of course, I don't believe he is doing that; I also can't believe that the effective requirements for the project are quite as decoupled from source compatibility considerations as has sometimes been implied by some of those working on the project). John -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On Sun, 2007-08-05 at 23:09 +, John J. Lee wrote: I just wanted to know: is it easy to make my code so it runs on 2.6 and 3.0, without funny stuff like a code translator? That depends on your definitions of easy and funny stuff. I'm pretty sure you'll be able to run the same source code on Python 2.6 and Python 3.0 without either one breaking, as long as the code is written sufficiently carefully. You may have to give up some Python 3.0 features and/or write compatibility shims depending on what features you'll need. Whether that's acceptable depends on the features you need and how much yak shaving you find acceptable. For instance, if you never use print statements in your code, you won't notice that print is becoming a function. If you do, you'll have to make appropriate accommodations. HTH, -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Carsten Haese [EMAIL PROTECTED] writes: For instance, if you never use print statements in your code, you won't notice that print is becoming a function. If you do, you'll have to make appropriate accommodations. Why on earth did they make this change? It just seems gratuitous. Is the assert statement also being changed? Are they going to update all the docs that say that the yield statement works like the print statement? -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 2007-08-06, Paul Rubin http wrote: Carsten Haese [EMAIL PROTECTED] writes: For instance, if you never use print statements in your code, you won't notice that print is becoming a function. If you do, you'll have to make appropriate accommodations. Why on earth did they make this change? It just seems gratuitous. Is the assert statement also being changed? Are they going to update all the docs that say that the yield statement works like the print statement? From the footnotes of PEP 3100: http://mail.python.org/pipermail/python-dev/2005-September/056154.html http://www.python.org/dev/peps/pep-3105 -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 2007-08-06, Neil Cerutti [EMAIL PROTECTED] wrote: On 2007-08-06, Paul Rubin http wrote: Carsten Haese [EMAIL PROTECTED] writes: For instance, if you never use print statements in your code, you won't notice that print is becoming a function. If you do, you'll have to make appropriate accommodations. Why on earth did they make this change? It just seems gratuitous. Is the assert statement also being changed? Are they going to update all the docs that say that the yield statement works like the print statement? From the footnotes of PEP 3100: http://mail.python.org/pipermail/python-dev/2005-September/056154.html http://www.python.org/dev/peps/pep-3105 Incidentally, from the second link I find it shocking that the keyword parameter file shadows a builtin. It seems to endorse a bad practice. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
On 6 Aug, 12:11, Paul Rubin http://[EMAIL PROTECTED] wrote: Carsten Haese [EMAIL PROTECTED] writes: For instance, if you never use print statements in your code, you won't notice that print is becoming a function. If you do, you'll have to make appropriate accommodations. Why on earth did they make this change? It just seems gratuitous. Is the assert statement also being changed? Are they going to update all the docs that say that the yield statement works like the print statement? Indeed: practicality beats purity [1]. Uh, wait a moment! Paul [1] http://www.python.org/dev/culture/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
I'm surprised to read this: http://en.wikipedia.org/wiki/Python_3 Note that while there is no explicit requirement that code be able to run unmodified in both versions, in practice it is quite likely for most code. As of January 2007, it looks like most reasonable code should run quite well under either branch. It's difficult to predict the future, but I think this statement is a fair description. I haven't been following Python 3 development recently. Have things really changed that much? Last time I looked, e.g. dict.items() no longer returned a list. Correct. Seems unlikely that most code will run on 2 and 3, in that case, Why that? Most reasonable code doesn't care what dict.items returns, as it reads like for k,v in dict.items(): do_something_with(k,v) and IIUC Guido has said all along that not much code will run on both. I think you misunderstood. It's not a design goal that code works without modifications, yet most reasonable code will even without that being an explicit goal. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Martin v. Löwis [EMAIL PROTECTED] writes: I'm surprised to read this: http://en.wikipedia.org/wiki/Python_3 Note that while there is no explicit requirement that code be able to run unmodified in both versions, in practice it is quite likely for most code. As of January 2007, it looks like most reasonable code should run quite well under either branch. It's difficult to predict the future, but I think this statement is a fair description. I haven't been following Python 3 development recently. Have things really changed that much? Last time I looked, e.g. dict.items() no longer returned a list. Correct. Seems unlikely that most code will run on 2 and 3, in that case, Why that? Most reasonable code doesn't care what dict.items returns, as it reads like for k,v in dict.items(): do_something_with(k,v) We could discuss that. However, my example wasn't really intended to relate strictly to that technical feature. Rather, to the intent of the Python 3 developers, as suggested by things like that change, and by what they've said over the last year or so (I think I've seen that specific change used several times by people explaining that 2.6 / 3.0 compatibility will be impractical, which is why I chose it). and IIUC Guido has said all along that not much code will run on both. I think you misunderstood. It's not a design goal that code works without modifications, yet most reasonable code will even without that being an explicit goal. I think the design goals have been fairly clear. What hasn't been clear (to me, at least) is the practical question of the feasibility of code working unchanged on both 2.6 and 3.0. http://www.python.org/dev/peps/pep-3000/ There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.) Though certainly neither quote is precise enough to pin it down formally, certainly the tone of the first quote (from the Wikipedia article) to my ear makes it sound like (at minimum!) it will be practical for most projects, if they do the work to support both 3.0 and 2.6, to run simultaneously on 2.6 and 3.0 without use of a translation tool. The second quote makes it sound like that will be highly impractical. That picture is reinforced by what follows (in PEP 3000): The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows: 0. You should have excellent unit tests with close to full coverage. 1. Port your project to Python 2.6. 2. Turn on the Py3k warnings mode. 3. Test and edit until no warnings remain. 4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the output! 5. Test the converted source code under 3.0. 6. If problems are found, make corrections to the 2.6 version of the source code and go back to step 3. 7. When it's time to release, release separate 2.6 and 3.0 tarballs (or whatever archive form you use for releases). It is recommended not to edit the 3.0 source code until you are ready to reduce 2.6 support to pure maintenance (i.e. the moment when you would normally move the 2.6 code to a maintenance branch anyway). So which is it? That is, will it be practical for most projects to support 2.6 and 3.0 simultaneously, from the same codebase, without relying on translation tools? I'm assuming the practicalities of this *are* clear by now to the Python 3 developers -- is that right? It seems to me that if I don't understand what the Python 3 developers expect the practicalities to be, most other interested people won't either (interested in the opposite sense to disinterested rather than to uninterested). John -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
I think you misunderstood. It's not a design goal that code works without modifications, yet most reasonable code will even without that being an explicit goal. I think the design goals have been fairly clear. What hasn't been clear (to me, at least) is the practical question of the feasibility of code working unchanged on both 2.6 and 3.0. http://www.python.org/dev/peps/pep-3000/ There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.) That's a different statement, though: It is likely that code will not run unmodified on 3k. For example, print is now a statement, and many many modules use that statement somewhere; they break in 3k. However, it *is* a design goal to make 2.6 so that transition to 3k becomes simpler. That's not a 3k feature, but a 2.6 one. Though certainly neither quote is precise enough to pin it down formally, certainly the tone of the first quote (from the Wikipedia article) to my ear makes it sound like (at minimum!) it will be practical for most projects, if they do the work to support both 3.0 and 2.6, to run simultaneously on 2.6 and 3.0 without use of a translation tool. The second quote makes it sound like that will be highly impractical. That picture is reinforced by what follows (in PEP 3000): The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows: That's Guido's recommendation, yes: use the 2to3 tool. There are certainly projects for which this might be the only reasonable strategy. However, whether that will be the *common* strategy remains to be seen. I personally believe that many projects won't need the 2to3 tool, if they are willing to compromise on the notations used in the source code. So which is it? Both. That is, will it be practical for most projects to support 2.6 and 3.0 simultaneously, from the same codebase, without relying on translation tools? That remains to be seen. I believe it will be, yes. Only when people start trying we will actually know. Personal preference will vary across projects; some will use the conversion tool even though they could have come up with a single-source solution, others will fight for a single-source solution even though life would have been much simpler with the conversion tool. I'm assuming the practicalities of this *are* clear by now to the Python 3 developers -- is that right? Not at all (at least now to me). I know what kind of changes *I* regularly do to make code run in 3k, namely, put parentheses around into the print statements. I can live with that. Whether it is practical to run, say, Django unmodified, I don't know - I have not looked into Django with that much detail, let alone tested whether it will work. Note that I'm primarily talking about pure Python here; for C code, you can get a single-source version only with a lot of #ifdefs (but again, I believe it is practical to make it work that way). It seems to me that if I don't understand what the Python 3 developers expect the practicalities to be, most other interested people won't either (interested in the opposite sense to disinterested rather than to uninterested). I think comp.lang.python is then the wrong place to find out; the py3k list likely reaches more of these developers. OTOH, I don't know whether they all want to participate in a survey of their expectations... Rather than studying people's opinions, why don't you try to port your own projects to 3k, and report whether you found it practical to use a single source (assuming you would prefer such a solution for your own project)? Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
Martin v. Löwis [EMAIL PROTECTED] writes: [... snip stuff I don't follow ...] However, it *is* a design goal to make 2.6 so that transition to 3k becomes simpler. That's not a 3k feature, but a 2.6 one. Not sure I care about this sort of thing for the purpses of my question. I just wanted to know: is it easy to make my code so it runs on 2.6 and 3.0, without funny stuff like a code translator? Seems wikipedia said yes and Guido said no. [...] to be seen. I personally believe that many projects won't need the 2to3 tool, if they are willing to compromise on the notations used in the source code. OK, so there's disagreement on this point amongst the Python 3 developers. That's interesting (I don't mean that in a negative way). [...] It seems to me that if I don't understand what the Python 3 developers expect the practicalities to be, most other interested people won't either (interested in the opposite sense to disinterested rather than to uninterested). I think comp.lang.python is then the wrong place to find out; the py3k list likely reaches more of these developers. OTOH, I don't know whether they all want to participate in a survey of their expectations... I was also hoping to get a quick answer rather than a long discussion, if any Python 3 developers were around to talk to the broader range of people that read this list. You have given your answers, I wonder if anybody else will turn up. Rather than studying people's opinions, why don't you try to port your own projects to 3k, and report whether you found it practical to use a single source (assuming you would prefer such a solution for your own project)? Because that might well tell me much less than asking a Python 3 developer, and yet take far more time, and fail to inform everybody else. John -- http://mail.python.org/mailman/listinfo/python-list
Re: Misleading wikipedia article on Python 3?
John J. Lee schrieb: Martin v. Löwis [EMAIL PROTECTED] writes: [... snip stuff I don't follow ...] However, it *is* a design goal to make 2.6 so that transition to 3k becomes simpler. That's not a 3k feature, but a 2.6 one. Not sure I care about this sort of thing for the purpses of my question. I just wanted to know: is it easy to make my code so it runs on 2.6 and 3.0, without funny stuff like a code translator? Seems wikipedia said yes and Guido said no. Neither of these are qualified to make any statements about your code. Only you can find out yourself. OTOH, neither of these *did* make any statement about *your* code. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
