Feedback wanted on programming introduction (Python in Windows)

[Alf P. Steinbach]

* Ethan Furman:
> 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?

No. It's a "straw man" argument when the argument is made against something 
that's not the real position  --  often it's the opposite position  --  of the 
opponent. And that's what you (probably unwittingly, but literally) did: you 
claimed the text used "non-standard elements" and therefore was subject to 
changes in new versions of the language, while the reality was opposite: a 
defense against changes in new versions, and improvement in that respect.

Not that it matters much now. ;-)

I mean, I've started the work to change the text to 3.1.1.


>> 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.

That's a bit of a straw man argument. :-)  "Forward compatibility" is one way. 
What you illustrate is lack of "backward compatibility", which is the other way.

It would be utterly silly to try to make the examples backward compatible.

I mean, how far back? :-D


>> 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.

Then you probably haven't read the passage in ch 2 where I introduced that.

If so then I understand why you commented as you did -- misled by the other 
poster's comment.

That happens a lot on Usenet, people use all kinds of rhetoric devices and 
assumptions, sometimes intentionally and sometimes uninentionally, and sometimes 
that "works", misleading others.


>> 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.

Yes, it's risky.

Although please note that I'm very far from a novice at programming.

I have, through the years, learned quite a number of programming languages 
(started with Basic and 8080 assembler back around 1980), so I believe there is 
a >0 chance of doing this with a positive result, but yes, risky!

And no, I'm not disregarding advice; on the contrary, the reason I asked for 
feedback in a public forum was precisely because I'm *very* aware of the risk, 
as I stated in the thread's starting article. But there is also a risk with this 
public exposure, of course. Not everyone on Usenet is equally serious.

Btw., regarding the serious ones, I really appreciated your point about 
"Tkinter" -> "tkinter", for example. ;-)


>> 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".

Does that mean that 'print' is still subject to change as of 3.1.1?


Cheers,

- Alf