Feedback wanted on programming introduction (Python in Windows)

Ethan Furman ethan at
Thu Oct 29 23:16:13 CET 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 


More information about the Python-list mailing list