Prev: Picking a license (an atempt to give real advice)
Next: unittest not being run
From: Nobody on 14 May 2010 15:16
On Thu, 13 May 2010 12:29:08 +1200, Lawrence D'Oliveiro wrote:

>> Some people would prefer to have a manageable set of rules rather than
>> having to remember the results of all of the possible combinations of
>> interactions between language features.
>
> What are you accusing Python of, exactly?

I'm not accusing it of anything, exactly. I'm just pointing out that there
are entirely pragmatic reasons for disliking "multi-paradigm" languages.

From: Aahz on 15 May 2010 13:52
In article <mailman.223.1273942083.32709.python-list(a)python.org>,
<travis+ml-python(a)subspacefield.org> wrote:
>
>One very annoying thing in Python is the distinction between
>statements and expressions.

One extremely valuable thing in Python is the distinction between
statements and expressions.

In fact, given the semantic similarity between Python and Lisp, I would
argue that Python having the distinction is partly responsible for its
popularity.
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
From: Terry Reedy on 15 May 2010 18:08
On 5/15/2010 12:42 PM, travis+ml-python(a)subspacefield.org wrote:

> One very annoying thing in Python is the distinction between
> statements and expressions.

GvR regards it as a feature, claiming that research in the 1980s showed
that the syntactic heterogeneity aided comprehension. I believe this is
true for me.

> Ever since learning LISP (well, Scheme) in S&ICP I find myself
> frequently annoyed by this pointless distinction,

You have missed the very important distinction generally reflected in
the statement/expression divide. Some code is meant to be evaluated
immediately and some is meant to be quoted for later evaluation. In
general (yes, there are some exceptions), Python statements are either
restricted gotos or statements that implicitly quote part of the code in
the statement. And in general, with a few exceptions, including lambda,
expressions are completely and immediately evaluated. Changing print and
exec from statements to functions made Py3 more consistent in this
respect this distinction.

In List, one either quotes explicitly or must remember that certain
'functions' are not really functions but are 'special functions' or
'macros' that implicitly quote the code, just like Python statements do.

Simple statement example:

name = expression

The name is implicitely quoted. Behind the scenes, this is a function
call. At module level, one can write the call explictly, with explicit
quotes:

globals().__setitem__('name', expression)

If the statement form annoys you, use the expression equivalent. (Within
functions, however, you do not have this choice in CPython because, for
efficiency, function local namespaces are not Python objects and hence
there is no Python function to directly manipulate them.)

In Lisp, the expression would be something like

(set 'name expression)

Compound statement example:

def f(a, b=3);
'doc for a'
<several lines of body code>

The def keyword, default arg expression(s), and doc string are evaluated
immediately. The function name, parameter names, and body code must be
quoted somehow. In Python, this is done implicitly as signalled by def
being a statement keyword rather than a function name. Behind the
scenes, the def statement is implemented mainly by two function calls:
compile the (quoted) code and create a function object. I believe that
one could define functions with explicit calls rather than a statement,
but it would be much more work and require explicit quotes. Turning a
class statement into an exec() and type() call is easier, but still
extra work.

Terry Jan Reedy

From: Paul Rubin on 16 May 2010 00:36
travis+ml-python(a)subspacefield.org writes:
> To be fair, it appears that Python's whitespace-sensitive syntax sort
> of precludes the "make a complex function on one line" that is typical
> of languages which don't have statement/expression distinctions, but
> I'm not convinced it couldn't be solved, perhaps by allowing anonymous
> functions to span multiple lines, just like named functions.

Haskell has whitespace-based syntax like Python (you can alternatively
use curly braces). Their term for it is "layout". You can
alternatively use curly braces and semi-colons. I'd have to say that
Haskell's indentation rules are a bit harder to understand than Python's
at first.
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Picking a license (an atempt to give real advice)
Next: unittest not being run