Re: Yet another Python textbook
From Yet another Python textbook
On 21/11/2012 5:17 PM, Chris Angelico wrote:
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca wrote:
On 20/11/2012 4:00 PM, Chris Angelico wrote:
To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
strings. Take no notice; the rest of the world sees this as a huge
advantage. Python is now in a VERY small group of languages (I'm aware
of just one other) that have absolutely proper Unicode handling *and*
efficient string handling.
ChrisA
It's interesting to see that someone else finds the format function to be a
pain. Perhaps the problem lies with the documentation.
Hang on, what? I'm not sure where the format function comes in. I was
referring to the underlying representation.
The OP wrote:
The absurd flexible string representation has practically
borrowed the idea to propose once Python has a teaching tool.
I perhaps stretched this to refer specifically on one aspect, formatting
in my comment.
That said, though, I'm just glad that %-formatting is staying. It's an
extremely expressive string formatting method, and exists in many
languages (thanks to C's heritage). Pike's version is insanely
powerful, Python's is more like C's, but all three are compact and
convenient.
str.format(), on the other hand, is flexible. It strikes me as rather
more complicated than a string formatting function needs to be, but
that may be a cost of its flexibility.
ChrisA
Yes is is complicated.
From my reading of the docs, it seems to me that the three following
should be equivalent:
(a) formattingStr.format(values)
with
(b) format(values, formattingStr)
or
(c) tupleOfValues.__format__(formattingStr
Example:
print('{:-^14f}{:^14d}'.format(-25.61, 95 ))
print(format((-25.61, 95), '{:-^14f}{:^14d}'))
(-25.61, 95 ).__format__('{:-^14f}{:^14d}')
The second fails, perhaps because values can only be a single value.
The third fails, the reason is unclear.
Steven D'Aprano earlier said that a better diagnostic tool is planned
for Python 3.4.
Should we retreat to %-formatting for now?
Colin W.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Thu, Nov 22, 2012 at 5:24 AM, Colin J. Williams c...@ncf.ca wrote:
From my reading of the docs, it seems to me that the three following should
be equivalent:
(a) formattingStr.format(values)
with
(b) format(values, formattingStr)
or
(c) tupleOfValues.__format__(formattingStr
Example:
print('{:-^14f}{:^14d}'.format(-25.61, 95 ))
print(format((-25.61, 95), '{:-^14f}{:^14d}'))
(-25.61, 95 ).__format__('{:-^14f}{:^14d}')
The second fails, perhaps because values can only be a single value.
The third fails, the reason is unclear.
The latter two (which are more or less equivalent) fail because they are
intended for invoking the formatting rules of a single value. The
string argument to each of them is not a format string, but a format
specification, which in a format string is only the part that goes
inside the curly braces and after the optional colon. For example, in
this format string:
'Hello world {0!s:_4s}'.format(42)
'Hello world __42'
The format specifier here is _4s:
format('42', '_4s')
'__42'
The valid format specifiers depend upon the type of the object being formatted:
format(42, '04x')
'002a'
format(datetime(2012, 11, 22, 11, 17, 0), 'The time is %Y %d %m %H:%M:%S')
'The time is 2012 22 11 11:17:00'
Custom types can implement custom format specifications by overriding
the __format__ method:
class Foo:
... def __init__(self, value):
... self.value = value
... def __format__(self, spec):
... if spec == 'a':
... return str(self.value)
... if spec == 'b':
... return ''.join(reversed(str(self.value)))
... raise ValueError(Unknown format code {!r}.format(spec))
...
format(Foo(42), 'a')
'42'
format(Foo(42), 'b')
'24'
The same format specifications can then also be passed to str.format:
'{0:a} reversed is {0:b}'.format(Foo(42))
'42 reversed is 24'
Unfortunately, there does not seem to be a good reference to the
format specifications available for built-in types beyond basic
strings and numbers. I only knew about the datetime example because
it is used in an example in the str.format docs. The
datetime.__format__ implementation (which seems to be just a thin
wrapper of datetime.strftime) does not seem to be documented anywhere
in the datetime module docs.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 11/22/2012 7:24 AM, Colin J. Williams wrote:
From my reading of the docs, it seems to me that the three following
should be equivalent:
We read differently...
(a) formattingStr.format(values)
Where 'values' is multiple arguments
with
(b) format(values, formattingStr)
format(value[, format_spec])
Convert a value to a “formatted” representation, as controlled by
format_spec.
I notice that you did not pass multiple args, but indeed just one.
A 'format_spec' is only part of a {} formatting field.
or
(c) tupleOfValues.__format__(formattingStr
tuple.__format__
method '__format__' of 'object' objects
Which of to say, not specific to tuples.
Example:
print('{:-^14f}{:^14d}'.format(-25.61, 95 ))
print(format((-25.61, 95), '{:-^14f}{:^14d}'))
The interpretation of format_spec will depend on the type of the value
argument, however there is a standard formatting syntax that is used by
most built-in types: Format Specification Mini-Language. (The latter is
link to the FSML.
'-^14f' and '^14d' are format_specs.
'{:-^14f}{:^14d}' is a format string that includes two fields with
format specs. It is not a format spec in itself and is therefore invalid
by the doc.
(-25.61, 95 ).__format__('{:-^14f}{:^14d}')
The second fails, perhaps because values can only be a single value.
You only passed one, but you did not pass a format spec and indeed there
is none for tuples. As delivered, format specs only format strings and
numbers as strings. Collection classes other than str recursively format
their members using str() or repr() until they reach strings, numbers,
or customs class instances with custom .__format__ methods.
Should we retreat to %-formatting for now?
Nonsense. The issues above are the same for % formatting. If you try to
format one object with two % format specs, it will fail for the same
reason. Try the % equivalent of what failed.
'%-14f%14d' % ((-25.61, 95 ),)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 22/11/2012 1:27 PM, Ian Kelly wrote:
On Thu, Nov 22, 2012 at 5:24 AM, Colin J. Williams c...@ncf.ca wrote:
From my reading of the docs, it seems to me that the three following should
be equivalent:
(a) formattingStr.format(values)
with
(b) format(values, formattingStr)
or
(c) tupleOfValues.__format__(formattingStr
Example:
print('{:-^14f}{:^14d}'.format(-25.61, 95 ))
print(format((-25.61, 95), '{:-^14f}{:^14d}'))
(-25.61, 95 ).__format__('{:-^14f}{:^14d}')
The second fails, perhaps because values can only be a single value.
The third fails, the reason is unclear.
The latter two (which are more or less equivalent) fail because they are
intended for invoking the formatting rules of a single value. The
string argument to each of them is not a format string, but a format
specification, which in a format string is only the part that goes
inside the curly braces and after the optional colon. For example, in
this format string:
Thanks, this is clear. I wish the docs made this clearer.
You and I used __format__. I understand that the use of double
underscore functions is deprecated. Is there some regular function
which can achieve the same result?
'Hello world {0!s:_4s}'.format(42)
'Hello world __42'
The format specifier here is _4s:
format('42', '_4s')
'__42'
The valid format specifiers depend upon the type of the object being formatted:
format(42, '04x')
'002a'
format(datetime(2012, 11, 22, 11, 17, 0), 'The time is %Y %d %m %H:%M:%S')
'The time is 2012 22 11 11:17:00'
Custom types can implement custom format specifications by overriding
the __format__ method:
class Foo:
... def __init__(self, value):
... self.value = value
... def __format__(self, spec):
... if spec == 'a':
... return str(self.value)
... if spec == 'b':
... return ''.join(reversed(str(self.value)))
... raise ValueError(Unknown format code {!r}.format(spec))
...
format(Foo(42), 'a')
'42'
format(Foo(42), 'b')
'24'
The same format specifications can then also be passed to str.format:
'{0:a} reversed is {0:b}'.format(Foo(42))
'42 reversed is 24'
Unfortunately, there does not seem to be a good reference to the
format specifications available for built-in types beyond basic
strings and numbers. I only knew about the datetime example because
it is used in an example in the str.format docs. The
datetime.__format__ implementation (which seems to be just a thin
wrapper of datetime.strftime) does not seem to be documented anywhere
in the datetime module docs.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 22 November 2012 22:41, Colin J. Williams c...@ncf.ca wrote:
On 22/11/2012 1:27 PM, Ian Kelly wrote:
On Thu, Nov 22, 2012 at 5:24 AM, Colin J. Williams c...@ncf.ca wrote:
From my reading of the docs, it seems to me that the three following
should
be equivalent:
(a) formattingStr.format(values)
with
(b) format(values, formattingStr)
or
(c) tupleOfValues.__format__(**formattingStr
Example:
print('{:-^14f}{:^14d}'.**format(-25.61, 95 ))
print(format((-25.61, 95), '{:-^14f}{:^14d}'))
(-25.61, 95 ).__format__('{:-^14f}{:^14d}'**)
The second fails, perhaps because values can only be a single value.
The third fails, the reason is unclear.
The latter two (which are more or less equivalent) fail because they are
intended for invoking the formatting rules of a single value. The
string argument to each of them is not a format string, but a format
specification, which in a format string is only the part that goes
inside the curly braces and after the optional colon. For example, in
this format string:
Thanks, this is clear. I wish the docs made this clearer.
You and I used __format__. I understand that the use of double underscore
functions is deprecated. Is there some regular function which can achieve
the same result?
help(format)
format(...)
format(value[, format_spec]) - string
Returns value.__format__(format_spec)
format_spec defaults to
*In other words, format(a, b) is the correct way to write
a.__format__(b).*
This is in the same way that a.__add__(b) should be written a + b, or
a.__round__(b) written round(a, b).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Thu, 22 Nov 2012 17:41:22 -0500, Colin J. Williams wrote: You and I used __format__. I understand that the use of double underscore functions is deprecated. Double leading and trailing underscore methods are not deprecated, they are very much part of the public interface. But they are reserved for Python's use, and under normal conditions you should not be using them by hand. For example: y = x.__add__(1) # NO y = x + 1 # YES if mylist.__len__() 2: # NO if len(mylist) 2: # YES Is there some regular function which can achieve the same result? The built-in format() function is the public API for calling the dunder method __format__. So normally you would write: format(value, spec) instead of value.__format__(spec). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
No worries, I've just sent you my pull-request :) On Thu, Nov 22, 2012 at 1:11 PM, Pavel Solin solin.pa...@gmail.com wrote: Hi Alec, Can you put your website—http://femhub.com/textbook-python/—on your github—https://github.com/femhub/nclab-textbook-python? Done, thank you so much. I edited the textbook based on responses that I received. Based on several inquiries we also decided to add Python 3.2 to NCLab. New release is coming in one or two weeks. Cheers, Pavel On Wed, Nov 21, 2012 at 4:34 PM, Alec Taylor alec.tayl...@gmail.com wrote: Dear Prof. Solin, Can you put your website—http://femhub.com/textbook-python/—on your github—https://github.com/femhub/nclab-textbook-python? I will then send you a pull request with a bootstrapped homepage with good UX. All the best, Alec Taylor -- Pavel Solin Associate Professor Applied and Computational Mathematics University of Nevada, Reno http://hpfem.org/~pavel -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
Le mardi 20 novembre 2012 22:00:49 UTC+1, Chris Angelico a écrit : On Wed, Nov 21, 2012 at 1:57 AM, wxjmfa...@gmail.com wrote: - To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. No. Not at all. I'm mainly and deeply disappointed. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 20/11/2012 4:00 PM, Chris Angelico wrote: On Wed, Nov 21, 2012 at 1:57 AM, wxjmfa...@gmail.com wrote: Le mardi 20 novembre 2012 09:09:50 UTC+1, Chris Angelico a écrit : On Tue, Nov 20, 2012 at 7:02 PM, Pavel Solin solin.pa...@gmail.com wrote: Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. If you're teaching Python, the stats are probably about zero for zero. Start them off on Py3 and help move the world forward. ChrisA Do not count with me. The absurd flexible string representation has practically borrowed the idea to propose once Python has a teaching tool. To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA It's interesting to see that someone else finds the format function to be a pain. Perhaps the problem lies with the documentation. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca wrote: On 20/11/2012 4:00 PM, Chris Angelico wrote: To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA It's interesting to see that someone else finds the format function to be a pain. Perhaps the problem lies with the documentation. Hang on, what? I'm not sure where the format function comes in. I was referring to the underlying representation. That said, though, I'm just glad that %-formatting is staying. It's an extremely expressive string formatting method, and exists in many languages (thanks to C's heritage). Pike's version is insanely powerful, Python's is more like C's, but all three are compact and convenient. str.format(), on the other hand, is flexible. It strikes me as rather more complicated than a string formatting function needs to be, but that may be a cost of its flexibility. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 11/21/2012 05:17 PM, Chris Angelico wrote: snip That said, though, I'm just glad that %-formatting is staying. It's an extremely expressive string formatting method, and exists in many languages (thanks to C's heritage). Pike's version is insanely powerful, Python's is more like C's, but all three are compact and convenient. str.format(), on the other hand, is flexible. It strikes me as rather more complicated than a string formatting function needs to be, but that may be a cost of its flexibility. Some don't realize that one very powerful use for the .format style of working is that it makes localization much more straightforward. With the curly brace approach, one can translate the format string into another language, and if the parameters have to be substituted in another order, it's all in one place. Twenty years ago, I implemented such a thing for our product (C++), for just that reason. I'm sure that by now, the libraries exist somewhere in the C++ stdlibs, or at least in Boost. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Wed, Nov 21, 2012 at 3:58 PM, Dave Angel d...@davea.name wrote: Some don't realize that one very powerful use for the .format style of working is that it makes localization much more straightforward. With the curly brace approach, one can translate the format string into another language, and if the parameters have to be substituted in another order, it's all in one place. It only matters with positional placeholders, though. You can achieve the same thing using named placeholders, which both major formatting styles support. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 21 November 2012 22:17, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca wrote:
On 20/11/2012 4:00 PM, Chris Angelico wrote:
To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
strings. Take no notice; the rest of the world sees this as a huge
advantage. Python is now in a VERY small group of languages (I'm aware
of just one other) that have absolutely proper Unicode handling *and*
efficient string handling.
ChrisA
It's interesting to see that someone else finds the format function to
be a
pain. Perhaps the problem lies with the documentation.
Hang on, what? I'm not sure where the format function comes in. I was
referring to the underlying representation.
That said, though, I'm just glad that %-formatting is staying. It's an
extremely expressive string formatting method, and exists in many
languages (thanks to C's heritage). Pike's version is insanely
powerful, Python's is more like C's, but all three are compact and
convenient.
str.format(), on the other hand, is flexible. It strikes me as rather
more complicated than a string formatting function needs to be, but
that may be a cost of its flexibility.
Since we've decided to derail the conversation...
{}.format() is a blessing an % () should go. % has no relevance to
strings, is hard to get and has an appalling* syntax. Having two syntaxes
just makes things less obvious, and the right choice rarer.
str.format is also really easy. I don't understand what makes you disagree.
Easy vs easier:
%s %s %s % (1, 2, 3)
'1 2 3'
{} {} {}.format(1, 2, 3)
'1 2 3'
Easy vs easier:
You have %(spam)s spam and %(eggs)s eggs! % {spam: 43, eggs: 120}
'You have 43 spam and 120 eggs!'
You have {spam} spam and {eggs} eggs!.format(spam=43, eggs=120)
OR
You have {spam} spam and {eggs} eggs!.format(**{spam: 43, eggs:
120})
'You have 43 spam and 120 eggs!'
Eh...? vs easy:
Thing %s has state %+o! % (#432, 14)
'Thing #432 has state +16!
Thing {} has state {:+o}!.format(#432, 14)
'Thing #432 has state +16!'
*Additionally*, a = str.format is much *better* than a = str.__mod__.
I have a piece of code like this:
{fuscia}{{category__name}}/{reset}{{name}} {green}{{version}}{reset}:\n
{{description}}
Which *would* have looked like this:
%(fuscia)s%%(category__name)s/%(reset)s%%(name)s
%(green)s%%(version)s%(reset)s:\n%%(description)s
Which would have parsed to something like:
'FUSCIA{category__name}/RESET{name} GREEN{version}RESET:\n{description}'
and
'FUSCIA%(category__name)s/RESET%(name)s GREEN%(version)sRESET:\n
%(description)s'
Can you seriously say you don't mind the %(name)ss in this?
* A {} is in the {} vs A %s is in the %s?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Wed, 21 Nov 2012 12:03:30 -0500, Colin J. Williams wrote: On 20/11/2012 4:00 PM, Chris Angelico wrote: To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA It's interesting to see that someone else finds the format function to be a pain. Perhaps the problem lies with the documentation. This is nothing to do with the format function. Chris, and JMF, is talking about the internal representation of strings in Python. Python 3.3 fixes a long-running design flaw that causes Unicode strings to be buggy (the use of so-called surrogate pairs for characters outside of the Basic Multilingual Plane), *and* saves up to 75% of the memory used by strings (reducing it from up to 4 bytes per character to as little as 1 byte per character), but at the cost of a trivially small slowdown under some circumstances. JMF is obsessed with the idea that Python is destroying Unicode for the benefit of the Americans. It's quite sad really. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 21/11/2012 23:21, Joshua Landau wrote:
On 21 November 2012 22:17, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 22, 2012 at 4:03 AM, Colin J. Williams c...@ncf.ca wrote:
On 20/11/2012 4:00 PM, Chris Angelico wrote:
To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393
strings. Take no notice; the rest of the world sees this as a huge
advantage. Python is now in a VERY small group of languages (I'm aware
of just one other) that have absolutely proper Unicode handling *and*
efficient string handling.
ChrisA
It's interesting to see that someone else finds the format function to
be a
pain. Perhaps the problem lies with the documentation.
Hang on, what? I'm not sure where the format function comes in. I was
referring to the underlying representation.
That said, though, I'm just glad that %-formatting is staying. It's an
extremely expressive string formatting method, and exists in many
languages (thanks to C's heritage). Pike's version is insanely
powerful, Python's is more like C's, but all three are compact and
convenient.
str.format(), on the other hand, is flexible. It strikes me as rather
more complicated than a string formatting function needs to be, but
that may be a cost of its flexibility.
Since we've decided to derail the conversation...
{}.format() is a blessing an % () should go. % has no relevance to
strings, is hard to get and has an appalling* syntax. Having two syntaxes
just makes things less obvious, and the right choice rarer.
str.format is also really easy. I don't understand what makes you disagree.
Easy vs easier:
%s %s %s % (1, 2, 3)
'1 2 3'
{} {} {}.format(1, 2, 3)
'1 2 3'
Easy vs easier:
You have %(spam)s spam and %(eggs)s eggs! % {spam: 43, eggs: 120}
'You have 43 spam and 120 eggs!'
You have {spam} spam and {eggs} eggs!.format(spam=43, eggs=120)
OR
You have {spam} spam and {eggs} eggs!.format(**{spam: 43, eggs:
120})
'You have 43 spam and 120 eggs!'
Eh...? vs easy:
Thing %s has state %+o! % (#432, 14)
'Thing #432 has state +16!
Thing {} has state {:+o}!.format(#432, 14)
'Thing #432 has state +16!'
*Additionally*, a = str.format is much *better* than a = str.__mod__.
I have a piece of code like this:
{fuscia}{{category__name}}/{reset}{{name}} {green}{{version}}{reset}:\n
{{description}}
Which *would* have looked like this:
%(fuscia)s%%(category__name)s/%(reset)s%%(name)s
%(green)s%%(version)s%(reset)s:\n%%(description)s
Which would have parsed to something like:
'FUSCIA{category__name}/RESET{name} GREEN{version}RESET:\n{description}'
and
'FUSCIA%(category__name)s/RESET%(name)s GREEN%(version)sRESET:\n
%(description)s'
Can you seriously say you don't mind the %(name)ss in this?
* A {} is in the {} vs A %s is in the %s?
C %f style formatting is never going to go so live with it. I know as I
asked maybe two years ago. On Python-dev. I think.
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Wed, Nov 21, 2012 at 4:21 PM, Joshua Landau
joshua.landau...@gmail.com wrote:
{}.format() is a blessing an % () should go. % has no relevance to
strings, is hard to get and has an appalling* syntax. Having two syntaxes
just makes things less obvious, and the right choice rarer.
str.format is also really easy. I don't understand what makes you disagree.
I think it mostly depends on where you come from as a programmer. As
you say, having two syntaxes muddles things up. If you come from C or
C++, then the %s syntax feels natural and intuitive, and trying to
learn the sort-of-similar-but-not-really {} syntax on top of it is
just confusing. Conversely, if you come from Java or C#, then the {}
syntax comes naturally, and having to learn %s in addition will give
one a headache. And then there are those who come from Lisp and want
to know why they can't just use the familiarly easy ~a syntax.
None of these are really any easier than the others. But they are
sort of similar at a superficial level, which just makes it that much
more painful to learn one when you're already accustomed to another.
I think my favorite example from the str.format documentation is this
one. Apart from demonstrating the flexibility of the format system,
it also manages to mix the two systems in a most unholy way:
import datetime
d = datetime.datetime(2010, 7, 4, 12, 15, 58)
'{:%Y-%m-%d %H:%M:%S}'.format(d)
'2010-07-04 12:15:58'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
Hi Alec, Can you put your website—http://femhub.com/textbook-python/—on your github—https://github.com/femhub/nclab-textbook-python? Done, thank you so much. I edited the textbook based on responses that I received. Based on several inquiries we also decided to add Python 3.2 to NCLab. New release is coming in one or two weeks. Cheers, Pavel On Wed, Nov 21, 2012 at 4:34 PM, Alec Taylor alec.tayl...@gmail.com wrote: Dear Prof. Solin, Can you put your website—http://femhub.com/textbook-python/—on your github—https://github.com/femhub/nclab-textbook-python? I will then send you a pull request with a bootstrapped homepage with good UX. All the best, Alec Taylor -- Pavel Solin Associate Professor Applied and Computational Mathematics University of Nevada, Reno http://hpfem.org/~pavel -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 11/21/2012 6:21 PM, Joshua Landau wrote:
Since we've decided to derail the conversation...
{}.format() is a blessing an % () should go. % has no relevance
to strings, is hard to get and has an appalling* syntax. Having two
syntaxes just makes things less obvious, and the right choice rarer.
str.format is also really easy. I don't understand what makes you disagree.
Easy vs easier:
%s %s %s % (1, 2, 3)
'1 2 3'
{} {} {}.format(1, 2, 3)
'1 2 3'
You forgot the cases where % formatting has to be special cased.
The answer is {}..format(1)
'The answer is 1.'
The answer is {}..format((1,))
'The answer is (1,).'
The answer is %s % 1
'The answer is 1'
The anwser is %s % (1,)
'The answer is 1'
The answer is %s % ((1,),)
'The answer is (1,)'
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
Hi Ian, thank you for your comments. On Mon, Nov 19, 2012 at 11:46 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Nov 18, 2012 at 10:30 PM, Pavel Solin solin.pa...@gmail.com wrote: I would like to introduce a new Python textbook aimed at high school students: http://femhub.com/textbook-python/. The textbook is open source and its public Git repository is located at Github: g...@github.com:femhub/nclab-textbook-python.git Feedback and contributions are very much welcome, every contributor becomes automatically a co-author. First impression: I'm opening up the book and reading the introduction, and I get to section 1.6, and the very first code example given is: print Hello, World! :) A fine tradition to be sure, but I have to say that I'm a little disappointed that a new textbook on Python being written in 2012 is focused squarely on Python 2, especially when I just read on the previous page that Python 3 was released in 2008. Is there any work underway get Python 3 into NCLab? There is an ongoing discussion but we are not sure. Are there any reasons except for the print () command and division of integers? The issue comes up again four pages later in section 2.4, when division is being demoed, and the text takes a page-and-a-half detour to caution about the use of floor division for expressions like: 33 / 6 If the book were teaching Python 3, then this warning would be unnecessary, since division in Python 3 is *automatically* true division, unless you go out of your way to invoke floor division by using the special // operator. I think that the earliness and frequency that these differences arise underscore the point that it would be best if the book could simply be teaching Python 3 to start with. Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. Getting off that soapbox and moving along, I notice that on pages 20-22 there are some examples by way of comparison that are written in C, which makes me wonder what audience this textbook is really intended for. The previous pages and references to Karel have given me the impression that this is geared toward beginning programmers, who most likely are not familiar with C. That's exactly right. Unfortunately, many high school teachers are using C++ to teach programming to complete beginners. This comment is for them. It can be removed, you can do it if you like. The code is on Github. The most troublesome is the last of these examples, which is led up to with this text: The asterisks in the code below are pointers, an additional programming concept that one needs to learn and utilize here: This seems to suggest that the reader should stop reading here and do a Google search on pointers, in order to understand the example. Since this is not a textbook on C, and Python has no concept of pointers at all, doing this would be a complete waste of the reader's time. Skimming through a few more chapters, I don't see anything else that sets my spidey sense tingling. I hope that what I've written above gives you some things to consider, though. Thank you once more for the comments. Pavel Cheers, Ian -- Pavel Solin Associate Professor Applied and Computational Mathematics University of Nevada, Reno http://hpfem.org/~pavel -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Tue, Nov 20, 2012 at 7:02 PM, Pavel Solin solin.pa...@gmail.com wrote: Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. If you're teaching Python, the stats are probably about zero for zero. Start them off on Py3 and help move the world forward. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Mon, 19 Nov 2012 17:58:55 +0100, Kwpolska wrote: On Mon, Nov 19, 2012 at 6:30 AM, Pavel Solin solin.pa...@gmail.com wrote: I would like to introduce a new Python textbook aimed at high school students: http://femhub.com/textbook-python/. The textbook is open source and its public Git repository is located at Github: g...@github.com:femhub/nclab-textbook-python.git URL for humans: https://github.com/femhub/nclab-textbook-python Feedback and contributions are very much welcome, every contributor becomes automatically a co-author. Best regards, Pavel You are writing it for something called “NCLab”, not for the general public, and that sucks. I don't see why you say that it sucks. Why do you care if a free, useful Python text book drives some eyeballs to a website? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
Le mardi 20 novembre 2012 09:09:50 UTC+1, Chris Angelico a écrit : On Tue, Nov 20, 2012 at 7:02 PM, Pavel Solin solin.pa...@gmail.com wrote: Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. If you're teaching Python, the stats are probably about zero for zero. Start them off on Py3 and help move the world forward. ChrisA Do not count with me. The absurd flexible string representation has practically borrowed the idea to propose once Python has a teaching tool. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Tue, Nov 20, 2012 at 1:02 AM, Pavel Solin solin.pa...@gmail.com wrote: There is an ongoing discussion but we are not sure. Are there any reasons except for the print () command and division of integers? The big one is that Python 3 holds the future of Python development. There are no more feature releases planned for the 2.x series, only maintenance releases. Eventually, Python 2.7 is going to start looking pretty old. You might look through the whatsnew documents at: http://docs.python.org/3/whatsnew/index.html to get an idea of what features have been added in Python 3. Many of these have been backported to Python 2.6 or 2.7, possibly requiring a __future__ import, but most have not. One change that comes to my mind that might be of interest for NCLab is that in Python 3.3, the decimal module has been rewritten in C for a major speed-up. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Wed, Nov 21, 2012 at 1:57 AM, wxjmfa...@gmail.com wrote: Le mardi 20 novembre 2012 09:09:50 UTC+1, Chris Angelico a écrit : On Tue, Nov 20, 2012 at 7:02 PM, Pavel Solin solin.pa...@gmail.com wrote: Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. If you're teaching Python, the stats are probably about zero for zero. Start them off on Py3 and help move the world forward. ChrisA Do not count with me. The absurd flexible string representation has practically borrowed the idea to propose once Python has a teaching tool. To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 11/20/2012 3:02 AM, Pavel Solin wrote: previous page that Python 3 was released in 2008. Is there any work underway get Python 3 into NCLab? There is an ongoing discussion but we are not sure. Are there any reasons except for the print () command and division of integers? (In addition to Ian's answer, which points to an already long list of new features...) There are two separate questions. First, which versions of Python should NCLab support? I would say both 2.7 and 3.x+. Since Py3 support does not exist now, starting with 3.3+ might work best. Second, if NCLab supported both, which to teach in the book? I would say 3.3+. Python 3 has many improvements from a teaching standpoint. For instance, old-style classes are gone, so class statements produce modern-style classes by default. You can just say that the headers class C: class C(object): have the same effect and never mention that there was once a separate user-class system. Py 3 used unicode for text, and 3.3 now has a correct and portable unicode implementation. While non-ascii and even non-latin1 characters are not needed for interfacing with ascii-only instruments, scientific text uses lots of them. ... Perhaps you are right. Is there any statistics of how many Python programmers are using 2.7 vs. 3? Most of people I know use 2.7. Experienced Python programmers are not the target of your book. Many school/university classes have moved to Py3, and more will in the future. Many people who want to move to Py3 cannot because they *have to use* a Py2-only library. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On 20/11/2012 21:00, Chris Angelico wrote: To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA Rather more polite than the response I've had sitting in my drafts folder for several hours. I'm so pleased I didn't send it, I can now happily delete it and move on :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Wed, Nov 21, 2012 at 8:55 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 20/11/2012 21:00, Chris Angelico wrote: To the OP: jmf has an unnatural hatred of Python 3.3 and PEP 393 strings. Take no notice; the rest of the world sees this as a huge advantage. Python is now in a VERY small group of languages (I'm aware of just one other) that have absolutely proper Unicode handling *and* efficient string handling. ChrisA Rather more polite than the response I've had sitting in my drafts folder for several hours. I'm so pleased I didn't send it, I can now happily delete it and move on :) Polite is good :) Incidentally, if anyone else knows of a language that fits the description above, I'd be most curious. Maybe we're going to see a revolution in language design - with everyone adopting this sort of string handling - or in language usage - with everyone adopting Python or Pike. Hmm. We're having major security issues with Joomla, I wonder how hard it'd be to convince our webmaster to switch to a Python-based web framework... Dreaming-ly yours, ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Mon, Nov 19, 2012 at 6:30 AM, Pavel Solin solin.pa...@gmail.com wrote: I would like to introduce a new Python textbook aimed at high school students: http://femhub.com/textbook-python/. The textbook is open source and its public Git repository is located at Github: g...@github.com:femhub/nclab-textbook-python.git URL for humans: https://github.com/femhub/nclab-textbook-python Feedback and contributions are very much welcome, every contributor becomes automatically a co-author. Best regards, Pavel You are writing it for something called “NCLab”, not for the general public, and that sucks. 1. please use math-compatible fonts in LaTeX, like Computer Modern, Latin Modern, Lucida Bright or MathTime (I suggest one of the first two). This way, stuff in the math environment won’t look differently than the text. Currently, your text is in a fancy font and maths are in Computer Modern. 2. IMO, you should be doing a bit more general usage programming, not science-specific. 3. Code highlighting for inline code and other languages, please. This are just my basic thoughts from looking through it. -- Kwpolska http://kwpolska.tk stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Nov 20, 2:58 am, Kwpolska kwpol...@gmail.com wrote: You are writing it for something called “NCLab”, not for the general public, and that sucks. And making it available to the general public to consume. What's wrong with writing for one audience and providing for a broader? If you're that concerned with the NCLab-ness of it, fork it. 2. IMO, you should be doing a bit more general usage programming, not science-specific. It's produced by the Network Computing Laboratory for Science, Technology, Engineering and Mathematics, of course their focus will be on science. It's not like there's a lack of more generalised programming guides for Python. Some nice bikeshedding there, btw. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another Python textbook
On Sun, Nov 18, 2012 at 10:30 PM, Pavel Solin solin.pa...@gmail.com wrote: I would like to introduce a new Python textbook aimed at high school students: http://femhub.com/textbook-python/. The textbook is open source and its public Git repository is located at Github: g...@github.com:femhub/nclab-textbook-python.git Feedback and contributions are very much welcome, every contributor becomes automatically a co-author. First impression: I'm opening up the book and reading the introduction, and I get to section 1.6, and the very first code example given is: print Hello, World! A fine tradition to be sure, but I have to say that I'm a little disappointed that a new textbook on Python being written in 2012 is focused squarely on Python 2, especially when I just read on the previous page that Python 3 was released in 2008. Is there any work underway get Python 3 into NCLab? The issue comes up again four pages later in section 2.4, when division is being demoed, and the text takes a page-and-a-half detour to caution about the use of floor division for expressions like: 33 / 6 If the book were teaching Python 3, then this warning would be unnecessary, since division in Python 3 is *automatically* true division, unless you go out of your way to invoke floor division by using the special // operator. I think that the earliness and frequency that these differences arise underscore the point that it would be best if the book could simply be teaching Python 3 to start with. Getting off that soapbox and moving along, I notice that on pages 20-22 there are some examples by way of comparison that are written in C, which makes me wonder what audience this textbook is really intended for. The previous pages and references to Karel have given me the impression that this is geared toward beginning programmers, who most likely are not familiar with C. The most troublesome is the last of these examples, which is led up to with this text: The asterisks in the code below are pointers, an additional programming concept that one needs to learn and utilize here: This seems to suggest that the reader should stop reading here and do a Google search on pointers, in order to understand the example. Since this is not a textbook on C, and Python has no concept of pointers at all, doing this would be a complete waste of the reader's time. Skimming through a few more chapters, I don't see anything else that sets my spidey sense tingling. I hope that what I've written above gives you some things to consider, though. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Yet another Python textbook
I would like to introduce a new Python textbook aimed at high school students: http://femhub.com/textbook-python/. The textbook is open source and its public Git repository is located at Github: g...@github.com:femhub/nclab-textbook-python.git Feedback and contributions are very much welcome, every contributor becomes automatically a co-author. Best regards, Pavel -- Pavel Solin Associate Professor Applied and Computational Mathematics University of Nevada, Reno http://hpfem.org/~pavel -- http://mail.python.org/mailman/listinfo/python-list
