Indentation and optional delimiters

bearophileHUGS at lycos.com bearophileHUGS at lycos.com
Thu Feb 28 15:40:17 CET 2008


Steven D'Aprano:

>the readability of your posts will increase a LOT if you break it up into paragraphs,<

You are right, I'll try to do it (when I go in flux state I write
quickly, but I tend to produce long paragraphs).


>The thing is, make-another-copy and make-another-reference are semantically different things: they mean something different. Expecting the compiler to tell whether I want "x = y" to make a copy or to make another reference is never going to work,<

But the default behavior may become the "true" copy, that seems
simpler for a newbie to grasp. The language then may give a tool to
use references too (like passing arrays to functions in Pascal, you
can use "var" for pass-by-reference reference).


>It specifically talks about C, but it's relevant to Python, and all hypothetical future languages. Think about string concatenation in Python.<

It's a nice article, and it says many things. (The D language manages
strings in a good enough way, they are represented below the hood as
stack allocated structs of [pointer_begin, length] in UTF8/16/32 (C
strings are available too, static arrays of chars too, etc) that point
to a block on the GC-ected heap. Such representation may change into a
[pointer_begin, pointer_end] in the future, to speed up iterations.
But it lacks still a good way to do a reserve() like in STL C++
Vector, that requires a third value in the struct).

I presume you have linked me that article because it essentially
explains the concept of "leaking abstractions", that is even if your
system allows you to manage it through high-level abstractions, you
often have to know what's under the cover anyway, because the behavior
of such subsystems may have a large impact on the performance of the
high-level operations you try to perform.
If this is why you have pointed me that article, then I have the
following comments:

1) That's why when I have started learning Python I was asking here
about the computational complexity of various operations done by
Python, like the string methods. Later I have found that the best
strategy is to just perform thousands of little benchmarks. Even later
I have started to just read the C sources of Python :-)

2) The language I was talking about isn't meant to replace C or Java,
it's meant for newbies, students, and to be used on small problems. If
the problem is small enough, you can survive even if you ignore the
subsystems of the system you are using. So if you have 10 small
strings that you want to join once in a Python program you can use the
"+" too, without wasting too much running time. If you want more speed
or you want to solve bigger problems you can use different languages.

3) Subsystems may have a different degree of subsystem insulation:

3a) One subsystem that exists when I run a Python program is its GC,
but in most situations I can just ignore it, it works in a transparent
way, the abstraction doesn't leak much. Only in rare situations I may
have to disable it during a very fast creation of a complex data
structure, so it doesn't slow down that too much. When I do even more
complex things, with complex classes that use __del__ I may have to
think about the GC even more, but in most small programs the Python GC
is transparent.

3b) On the other hand, when I use the D language in a simple way I can
ignore its GC, using D almost as Java. But often I have to use D at a
lower level (because otherwise I prefer to use Python), I have to
manually allocate and deallocate data from the C heap or from the GC
heap, and in such cases the situation becomes hairy quickly, because I
don't know how exactly the GC will interact with my manual memory
management (that Python disallows). So often in D the GC is an almost
mysterious subsystem, and a very leaking abstraction (if you do
complex windows programming in C++, with smart pointers, etc, you may
have similar problems, so it's not a problem limited to D).


>They're different from the numbers you can't express exactly in base 2 numbers, and different from the numbers you can't express exactly as rationals, but they're there, waiting to trip you up:<

If you want to become a CS student, a programmer, you have to know
something about IEEE 754, or even you have to study "What Every
Computer Scientist Should Know About Floating-Point Arithmetic". But
for a person that doesn't want to spend so much time to solve a small
and not important problem, and doesn't want to hire a programmer to
solve that problem do that for him/her, a very high level language may
offer ways to the same mathematical operations without too much
problems. If you use an old HP 48 calculator you have to be careful,
but often it gives you good answers :-)

Thank you,
bearophile



More information about the Python-list mailing list