Python is readable

[Nathan Rice]

On Sat, Mar 31, 2012 at 2:15 AM, Lie Ryan <lie.1296 at gmail.com> wrote:
> On 03/21/2012 03:55 AM, Nathan Rice wrote:
>>
>> <snip>
>
> I think you've just described that greedy algorithm can't always find the
> globally optimal solution.

Right.  Using gradient descent on an algebraic surface is probably the
most natural example of why this is the case, since balls rolling down
a surface from a starting point to the bottom of a bowl is an exact
analogy.

On Sat, Mar 31, 2012 at 4:05 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, Mar 31, 2012 at 10:01 AM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> It seems to me that Indented blocks of text are used pretty frequently
>> to denote definition bodies, section subordinate paragraphs and
>> asides.  The use of the colon seems pretty natural too.  Parentheses
>> are fairly natural for small asides.  The notion of character
>> delimiters for large sections of text is actually pretty unnatural
>> with the exception of  quotes.
>
> Perhaps in formal written English, but not in spoken, and often not in
> casual writing either. Play around with my actual example, an "if"
> clause, and see where the punctuation goes in English - and how easily
> you can construct ambiguous sentences.

Sure

an event has occurred recently if it occurred in the last time step.

if xyz has occurred recently, that implies abc will occur in the next time step.

when event abc occurs, all unbound floops become bound, and at most
three newly bound floops are eaten by blargs.

blargs that have not eaten in the last 3 time steps eat before blargs
that have eaten in those time steps.

Notice I don't talk about HOW anything is done, just the logic of what
is happening.  The computer should be capable of making an inventory
of exactly what it will need to do given the statements I have made,
and choose the best data structures and algorithms for the job.  If we
are in undecidable/halting problem territory (indefinite recursion)
then the computer should at least be nice enough to tell you it is
confused and would like some help.

>> I don't like declarations, my personal preference is to have typed
>> signatures, and implicit declaration with type inference elsewhere.  I
>> view it as a matter of personal preference though, the result should
>> be the same, and it should be possible to view the code either way.
>
> I'm not sure what you mean by "typed signatures", can you elaborate please?

Just like the standard way in the Haskell community.  To demonstrate
using Python annotations...

def myfunc(Sequence : a, Integral : b, Map : c) -> Sequence:
    ...

Given starting types and ending types, you can correctly infer some
VERY complex internal types. Haskell will let you omit signature types
as well, but that is really a bad idea because they add readability
and you will have to add them often anyhow if you are dealing with
complex types.  Better to be consistent...

As a funny aside, people usually provide input type and return type
annotations to python functions, as part of the docstring (for
sphinx).

To be honest, I like having types baked into my code, though not
nominal types (the sort that is an A because it was declared as an A
or a subclass of A), but rather structural types (i.e. Abstract base
classes, or Java interfaces, if you didn't have to add the implements
...).  I don't like having to verbosely tell the computer about the
types of everything I'm going to use, I only care that it gives me the
output I want if I give it some agreed upon input.  It should be smart
enough to check the little things.