Alf P. Steinbach wrote:
* Ethan Furman:
Alf P. Steinbach wrote:
* James Harris:
You get way too deep into Python in places (for a beginner's course in
programming). For example, "from now on I’ll always use from
__future__ in any program that uses print."
Sorry, but I think that hiding such concerns is a real disservice.
The disservice is in teaching folks to use non-standard elements,
which is (sort-of) what __future__ is. Changes to the language are
experimented with in __future__ and can change from one release to the
next. If memory serves, the with statement is an example of having
different behavior when it was moved out of __future__ and made a
standard part of the language.
That's a bit of a straw man argument.
You don't agree, so it's a straw man? You didn't know, and when the
information is pointed out, it's a straw man?
I used "from __future__" to write
forward-compatible calls of print, so that those examples would not
mysteriously work or not depending on the Python version.
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import print_function
File "<stdin>", line 1
SyntaxError: future feature print_function is not defined
Hmmm... Doesn't seem to work in 2.5. So much for not working on a
different version.
I did not use
it to access experimental features.
From what I've seen of your posts so far, you wouldn't have known if
the print in __future__ was slightly different from the actual print in
3.x anyway.
However, I didn't know then that the language has changed so much in 3.x
that it isn't practical to aim at general forward compatibility or
version independence.
And I didn't know until your comment above that some features,
apparently, only exist in __future__ but are not part of the language,
subject to change.
Which is precisely the point raised by several -- writing a book for
novices, while still a novice, is going to be risky... especially if you
keep disregarding good advice about what to include and exclude.
Is there a current example?
And, just a suggestion, would it not be better to have a different name
for such experimental (as opposed to future language version) features,
e.g. "from __experimental__", differentiating between forward
compatibility in e.g. production code, and trying out experimental
subject-to-change features?
You're missing the point. If it's in __future__ it's subject to change.
Most likely it won't be a drastic change, but it *can* change. The
'experimental' is more along the lines of "hey, this is coming down the
pike, let's do some stress-testing so we can nail down the final
implementation".
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
