[zedshaw]

This book is for people who don't know any programming. So let's catalog your claims in that light:

1. "no use of context managers when working with files" - I teach files early on, before they even know how to make a block. After my book they can easily learn this.

2. "no use of format when working with text formatting and output" - Which format? At the time I was writing this there were what seemed like 10 changes to it and how it worked. The % format syntax works all the time, and it's something found everywhere. Learning it is useful, and doesn't prevent them from using format later.

3. "Avoid any project that mentions "Python 3"" - They should, Python 3 is not ready and is simply frustrating. Python 2 is on all of their computers already for many people, so that's the better one for a beginner. Also after learning 2, they can learn 3 if they need, but if they learn 3, they have to learn 2.

3. "Every if-statement must have an else" - This is for training their ability to think of the entire set of possible boolean results in an if-statement. It's also the cause of many logic bugs and you should consider it as a good way to check your own logic constructs.

4. "no list|dict|generator|set comprehensions." - The book is for beginners who can't even figure out how to run a python script on their own. You think they'll get comprehensions? That's insane. Later they can easily learn this, and I think a theme in your comments is that you think once someone reads one book they are done learning, which is a bizarre idea.

5. "no idiomatic hints" - Which idiom would that be? The early Python that's like JavaWithCamelCase or the new Python that's like c_with_underscores? The problem with Python idioms is they warp fairly regularly depending on what's in vogue at the time, so I just teach the simplest thing that seems to be common among all of them. And again, they will whatever "idiom" you think is important later when someone like you who thinks they're important yells at them about it. Brains are not made of stone.

6. "no gotchas." -- The book has loads of gotchas, AND I have videos that go with it where I show people the gotchas, AND there's additional problems for them to solve at the end of every exercise, AND I encourage them to break their scripts to see how Python gives them errors.

You would do well to ditch the idea that people cannot relearn things. Maybe this is holding you back as well, and it's simply false. Heroin and smoking are "bad habits". Playing a guitar scale wrong is a "bad habit". Whether you use CamelCase or loads_of_underscores is just easily updated information.

[koshak]

1. using context manager when working with io has two pros: no need to think about freeing resources, good style.

2. '{}'.format(). besides, print is a function

3. python versions you use as a ref in your book were released more than 5 years ago. All major projects have dropped support for them in favor of python 3.3+. Today it is difficult to find a project that doesn't support python3. There's not so much diff between py3.4 and py2.7. What is frustrating?

4. Occam's razor and K.I.S.S. tell me keep my stack as small as I can. Beginners better learn right principles than "easiness". Show them what's really effective. Programming is 95% mental work, 1% coding, 4% testing/debugging/optimizing. Teacher cannot inject knowledge into student's mind, but he can show the right direction and help make first steps.

5. comprehensions are idiomatic. context managers are idiomatic. Begin from the beginning. Begin from "import this".

6. well, yes. Your "they will learn that later" mantra is one of them.

I ditched the idea that learning programming begins with choosing a language and learning its basics. Instead you go learn KISS, DRY, YAGNI, etc., history of programming languages, stateful vs stateless, and learn this by practice, by exercise, just like playing the guitar. You begin with handling the instrument the right way and learning basics of music theory and once you get the idea of pentatonic scale and bebop you can go practice it, not vice versa. Well, you can play bebop in pentatonic and not be aware of what you're doing, but understanding the underlying theory and alternative approaches is the key to learning more complex things and discovering new horizons.

Relearning is a bad habit. Reusing your knowledge and expereince is a good one.

[koshak]

I learned programming from Pascal. It was at school.

Later on I was taught some C and x8086 assembly. I needed to forget Pascal. But I didn't get C.

Then I was introduced to OOP and C++ and was pissed off. I needed to forget procedural programming (at that time I didn't even know it was called that). But I didn't get it.

When I started to learn Python I dove deep in its OOP, data model, magic methods, functools, itertools, datatypes, any "writing idiomatic" and "top mistakes python programmers make" articles. When I didn't understand something (and it was a lot!), I walked to read theory about programming approaches, duck typing, functional programming, Guido disgusted by functional programming, difference and tragedy of py2/3 dichotomy, by the way learning a lot about programming, design patterns, computer science and history of all of that.

When I started all my knowledge about programming before learning python this way was just buzz words and almost no real experience.

But learning python this way - the hard way - allowed me to learn programming, its theoretical concepts. When I got stuck with something, I just hadn't move on till I understood everything the right way.

Where do you teach your readers to think right?

[nostrademons]

3. When did you form that opinion? I've found that since Django and numpy ported, Python3's been perfectly usable for a wide variety of uses. My last startup was all on Python3, and the only library I had a problem with was Splunk. Web programming, CLI scripting, deployment, data analysis, integrating with outside data sources - all of that went fine. The situation is quite different from what it was even a year ago.

And with Python3, you don't have to deal with baffling UnicodeDecodeErrors whenever you deal with real-world data, you get sane standard library names, and a lot of other syntactic warts have been cleaned up.

[brudgers]

Programming Languages have Social Mores not Idioms

http://learncodethehardway.org/blog/AUG_19_2012.html