Why does python not have a mechanism for data hiding?

[Paul Boddie]

On 11 Jun, 10:10, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> Russ P. a écrit :
>
> > You may be right to an extent for small or medium-sized non-critical
> > projects, but you are certainly not right in general. I read something
> > a while back about the flight software for the Boeing 777. I think it
> > was something like 3,000,000 lines of Ada code.
>
> I can't obviously back my claim, but you could probably have the same
> feature set implemented in 10 to 20 times less code in Python.

It's easy to make claims like this knowing that people aren't likely
to try and write such a system in Python.

>                                                                Not that
> I suggest using Python here specifically, but just to remind you that
> kloc is not a very exact metric - it's relative to the design, the
> language and the programmer(s). The first project I worked on
> (professionaly) was about 100 000 locs when I took over it, and one year
> later it was about 50 000 locs, with way less bugs and way more
> features. FWIW, the bigger the project, the bigger the chances that you
> could cut it by half with a good refactoring.

Perhaps you should get in touch with the advocacy-sig mailing list and
provide them with the concrete details, because although you and I
(and many others) recognise intuitively that Python code is typically
shorter than, say, Java because the boilerplate of the latter is
unnecessary, the last big discussion I recall about Python code being
shorter than that of statically typed languages didn't really yield
much in the way of actual projects to make the case.

> > Normally, for a
> > project of that magnitude  the final integration would be expected to
> > take something like three months. However, the precise interface specs
> > and encapsulation methods in Ada allowed the integration to be
> > completed in just three days.
>
> > By your recommended method of social interaction, that would be one
> > hell of a lot of talking!
>
> Or just writing and reading.

Maybe, but I'd imagine that the project mentioned is a fairly large
one with all the classic observations by Brooks highly applicable.
Such things can incur huge costs in a large project.

> > I realize that Python is not designed for such large projects,
>
> Clueless again. Python is pretty good for large projects.

It might be good for large projects but is it good for large projects
*such as the one mentioned*?

>                                                           Now the point
> is that it tends to make them way smaller than some other much more
> static languages. As an average, you can count on something between 5:1
> to 10:1 ratio between Java (typical and well-known reference) and Python
> for a same feature set. And the larger the project, the greater the ratio.

Again, I don't doubt this intuitively, but many people do doubt it.
Citation needed!

[...]

> Do you really think you're talking to a bunch of clueless newbies ? You
> can bet there are quite a lot of talented *and experimented* programmers
> here.

Maybe, but with the style of discourse you've been using, you're not
really speaking for them, are you?

> > Perhaps the benefits of interface specs and encapsulation are not as
> > obvious for smaller projects,
>
> Plain wrong.

I'm not a big fan of lots of up-front declarations when the code is
easy to understand intuitively, but what are you trying to say here?
That interface specifications and encapsulation are as essential for a
three line script as they are for a large project?

> > but certainly they are not zero.
>
> You still fail to get the point. Interface specifications and
> encapsulation are design principles. period. These principles are just
> as well expressed with documentation and naming conventions, and the
> cost is way lower.

I guess it depends on how the documentation gets written, because from
what I've seen documentation is one of the more neglected areas of
endeavour in software development, with many development organisations
considering it a luxury which requires only a cursory treatment in
order to get the code out of the door.

> Russ, do yourself a favor : get out of your cargo-cult one minute and
> ask yourself whether all python users are really such a bunch of
> clueless newbies and cowboy hackers. You may not have noticed, but there
> are some *very* talented and *experimented* programmers here.

Maybe, but I'd hope that some of those programmers would be at least
able to entertain what Russ has been saying rather than setting
themselves up in an argumentative position where to concede any
limitation in Python might be considered some kind of weakness that
one should be unwilling to admit.

Paul