Feedback wanted on programming introduction (Python in Windows)
Ethan Furman
ethan at stoneleaf.us
Thu Oct 29 18:16:13 EDT 2009
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~
More information about the Python-list
mailing list