This super seeds #141. This uses format method from String.

hi @r-gaia-cs are you sure about the decision of using the format method? print('weight in pounds:', 2.2 * weight_kg) works perfectly fine and it's way simpler.

I feel the format method introduces unnecessary complexity. Also, the format method was introduced in Python 2.6, so switching to it is somewhat unrelated to moving to Python 3.

are you sure about the decision of using the format method?

Is my preference.

print('weight in pounds:', 2.2 * weight_kg) works perfectly fine and it's way simpler.

I agree it is simpler. I want to use the format method because is probably what people will use if they want complex (and fancy) outputs. I can see myself teaching at a workshop and one of the students asking "And how can I print the value of 2.2 * weight_kg with three decimal values?" that I can only reply with format method and pointing to https://docs.python.org/3/library/string.html#format-specification-mini-language.

Is my preference.

can't argue about that :)

I agree it is simpler. I want to use the format method because is probably what people will use if they want complex (and fancy) outputs. I can see myself teaching at a workshop and one of the students asking "And how can I print the value of 2.2 * weight_kg with three decimal values?" that I can only reply with format method and pointing to https://docs.python.org/3/library/string.html#format-specification-mini-language.

Perhaps there's space for both, we can do the simple way first and then tell the students there's a more powerful way if needed. IMHO using format for very simple statements looks like killing a fly with a bazooka. My 2c anyway.

+1 to keeping it simple (no format), though I am embarrassed to admit I thought some manner of string formatting (either old style %f or new style {}) were required for even simple tasks, and didn't know the simpler option until now (thanks!)

Hi - I'm a mailing list lurker but as someone who's only recently "graduated" from SWC student level I'd like to vote for including the format method. I really love putting numbers in text using, for example {:2.2f}. I think it's really intuitive and much easier to read than the % style.

Keep it simple to start with - you're just trying to demonstrate simple features of numpy and .format distracts from that I think. Later on, make students aware of .format and link to the specification.

I think throwing .format in at the start introduces too many concepts at once. Maybe it would be better to build it up - show simple things like 'a b c'.split() or 'word'.upper() to introduce the idea of simple methods on strings first.

I like the idea of keeping it simple, but to make the students aware of .format later on. Maybe by including it in an exercise towards the end of one of the first lessons?

+1 to using the simpler version but mentioning that the format method exists. The extra complication of using format to start with is likely to interfere with learning of the more important concepts.

I would be inclined to use format(). Whilst it is good to keep things simple for learners, it is also important to think about how they will cope after SWC when they start reading code and documentation without an instructor in the room. format() is very common in Python 3 and I think it would do the learners a disservice if they hadn't seen it at all during the workshops. At the very least they need to know that format() exists, that it takes a number of potentially complex formatting instructions, and they need to know where in the documentation those formatting instructions can be found (for future reference).

+1 to including format towards the end of one of the first lessons. I think adding it as an exercise would be good.

+1 to @andreabedini's suggestion of delaying format to the end. It can be trivially introduced for advanced or C-savvy audiences but introduces an unnecessary mental load for those unaccustomed to string formatting.

The consensus above seems reasonable to me: don't introduce format right away to beginners, but make sure it gets seen at some point.

I'd suggest not using .format initially, and possibly not at all unless a meaningful reason can be found for introducing it. The string formatting mini-language is powerful but complex (like regex), and that makes it potentially quite a significant detour.

So this is a case where a micro-lesson may be appropriate, perhaps similar
to the shell-extras collection.

Sincerely,
Neal Davis, PhD
Training Coördinator
Computational Science and Engineering

2102B National Center for Supercomputing Applications
_1205 W Clark St, MC-257 · _Urbana, IL 61801
217·244·4181

On Thu, Jul 16, 2015 at 11:31 AM, Matt Davis notifications@github.com
wrote:

I'd suggest not using .format initially, and possibly not at all unless a
meaningful reason can be found for introducing it. The string formatting
mini-language is powerful but complex (like regex), and that makes it
potentially quite a significant detour.

—
Reply to this email directly or view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_swcarpentry_python-2Dnovice-2Dinflammation_pull_142-23issuecomment-2D122012597&d=AwMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=YIuGTHLMubt5gSX2YUN8ayNOUM9iTU2ePzZYbsw2lOg&m=FI5r3kCF3WzboxWCfoqDgfCzjIN8Pu31JkMNztj72AM&s=qMzL8zS6Hm5OwQHTfJV0AoSlyRcHlExEsuV2HMgtwLs&e=
.

Thanks to all for the comments. I will remove the format method soon.

@abostroem Could you review this pull request? I dropped the format method.

I agree with the basic points about format method (mention in followup, but don't lead with it).

That said: Software Carpentry does have a repo for an intermediate python lesson- is it actively being worked on? A lot of programming lessons focus on either novices or the very advanced, but teaching str.format in more detail seems like ideal content for people looking to improve. If we do our jobs right, that segment of the population should grow, and it would be a shame to neglect them. :)

https://github.com/swcarpentry/python-intermediate-mosquitoes

@r-gaia-cs This is a great start! I've made a few minor comments in line. The biggest thing is whether we should remove the section in 06-func.md which discusses debugging or replace it with a different bug. Comments welcome.

I've made a few minor comments in line.

Addressed.

The biggest thing is whether we should remove the section in 06-func.md which discusses debugging or replace it with a different bug.

As I said before, I will ask to not block this pull request because of it since this pull request is against py3k branch so it won't go live now. Let create a issue for find a good new bug and keep the working going.

@rgaiacs I've added two notes to the inline comments - once those are taken care of we're ready to merge :)

've added two notes to the inline comments - once those are taken care of we're ready to merge :)

@abostroem I toke care of the comments. Could you review the call out box that I add?

@rgaiacs I think you accidentally committed the html files. Is it possible for you to have this PR only update the md files (I'll regenerate the html files after I merge the PR)?

@QuLogic Thanks for the review.

@abostroem I rebased this pull request so that it could be merge smoothly.

I'm not sure why Github thinks that d312331 and e9413cb are part of this PR, but locally the history looks correct to me, so I'm going to merge this. Thanks for the rebase!