Does Python really follow its philosophy of "Readability counts"?

B

bieffe62

That is not what __slot__ is for.


Really? It seems to work:
.... __slots__ = ('a', 'b')
.... def __init__(self): self.not_allowed = 1
....Traceback (most recent call last):
File "<interactive input>", line 1, in <module>

Ciao
 
M

Marc 'BlackJack' Rintsch

Really? It seems to work:

It works but it is not what `__slot__` was invented for. Some call it a
misuse of that feature if you use it to prevent adding attributes
dynamically. And it has some drawbacks when you inherit from such
classes.

Ciao,
Marc 'BlackJack' Rintsch
 
B

Bruno Desthuilliers

Paul Rubin a écrit :
It would be enough to have a way to make specific objects and instance
attributes immutable.


Sure, but why have mutable objects all over the place? And, why
always have attributes visible at all, outside the class definition?
The approach in C++ and Java is to have public and private instance
variables, where the private ones are visible only in the class methods.

Why on earth are you using Python if you don't like the way it work ???
 
P

Paul Rubin

Bruno Desthuilliers said:
Why on earth are you using Python if you don't like the way it work ???

Why on earth keep releasing new versions of Python if the old ones are
already perfect?
 
R

r

Why on earth are you using Python if you don't like the way it work ???

Why on earth are you busting into someone's thread just because you
don't like what they have to say ???
 
S

Steven D'Aprano

Why on earth keep releasing new versions of Python if the old ones are
already perfect?

That's a fallacious argument. Nobody is arguing that any specific version
of Python is perfect, but clearly many people do like the general design
choices of the language, that is, the way it works.

*If* you don't like the way it works, and you have a choice in the
matter, perhaps you should find another language that works more the way
you would prefer.

On the other hand... Bruno's question is unfair. It is perfectly
reasonable to (hypothetically) consider Python to be the best *existing*
language while still wanting it to be improved (for some definition of
improvement). Just because somebody has criticisms of Python, or a wish-
list of features, doesn't mean they hate the language.
 
R

r

[stevie]
On the other hand... Bruno's question is unfair. It is perfectly
reasonable to (hypothetically) consider Python to be the best
*existing*
language while still wanting it to be improved (for some definition
of
improvement). Just because somebody has criticisms of Python, or a
wish-
list of features, doesn't mean they hate the language.
[/stevie]

WOW Steven, i am very impressed. That's the first thing you have said
in a very long time that i totally agree with! Keep this up and i may
put you back on my Python Brethren list :)
 
P

Paul Rubin

Steven D'Aprano said:
*If* you don't like the way it works, and you have a choice in the
matter, perhaps you should find another language that works more the way
you would prefer.

We are in an era for programming languages sort of like the Windows 95
era was for operating systems, where everything is broken but some of
the fixes are beginning to come into view. So there is no language
that currently really works the right way, but some of them including
Python are (one hopes) moving in good directions. Maybe I can help
that process along by posting, maybe not.
 
R

r

We are in an era for programming languages sort of like the Windows 95
era was for operating systems, where everything is broken but some of
the fixes are beginning to come into view.  So there is no language
that currently really works the right way, but some of them including
Python are (one hopes) moving in good directions.  Maybe I can help
that process along by posting, maybe not.

Paul,
Python is the best hope for readable, maintainable very high-level
coding. Python forged the path and showed all other languages for what
they truly are; archaic, redundant, pieces of complete rubbish! In my
mind only 2 languages stand out in the very high level category;
Python and Ruby. Ruby only exists in this world because of the things
it took from Python. Nobody would touch Ruby without it's Pythonisms.
Python wins hands down, WHY? you ask. Well i could list a thousand
reasons why but i will only cover a few.

1.) read-ability
2.) learn-ability
3.) maintain-ability
4.) perfect choice of keywords
5.) no end statement, braces, or lisps!
6.) no forced capitalizations
7.) modules are the actual script name
8.) introspection
9.) class, and class inheritance is beautiful
8.) true procedural support(no instance vars needed)
10.) loads of quality documentation!
11.) IDLE
12.) Guido (the genius that made all this happen!)

I could keep going for days and days. Python is hands down the best
thing that ever happened to the world of programming. Sure it could
use a few improvements, nothing and nobody is perfect. But can any
language stand toe to toe with Python? HELL NO!
 
L

Lou Pecora

Roy Smith said:
As the saying goes, "It's possible to write Fortran in any language".

My personal habit is to "declare" all instance variables in the __init__()
method of every class. If there's no better value, I set them to None.
This isn't strictly required, but I think it makes it easier for somebody
reading the code to understand the class.

I agree with you. I do exactly this. It prevents a lot of problems by
giving one place to look for class variables and comments on them.
Setting to None is good, too, since many times if I use one before
setting a value I'll get an exception or really bad results that I can
easily trace to the unset variable.
I'm not a big fan of dogmatic rules, other than the rule that says you
should make your code as easy for somebody else to understand as possible.

Right.
 
P

Paul Rubin

r said:
Python and Ruby. Ruby only exists in this world because of the things
it took from Python. Nobody would touch Ruby without it's Pythonisms.

I confess to not knowing much about Ruby. It looks sort of Perl-ish
to me, and I always hear it is slower than Python, which is already
too slow.
Python wins hands down, WHY? you ask. Well i could list a thousand
reasons why but i will only cover a few.

1.) read-ability
2.) ...
I could keep going for days and days. Python is hands down the best
thing that ever happened to the world of programming. Sure it could
use a few improvements, nothing and nobody is perfect. But can any
language stand toe to toe with Python? HELL NO!

Those things on your list are all nice, but I think Python has
considerable room for improvement in several areas:

1) Parallelism. Commodity desktop computers now have 8 effective cpu
cores or maybe even 16 soon (Mac Pro, Intel Core i7) but Python still
has the evil GIL that forces all threads to run on one core. Java,
Erlang, and Haskell (GHC) all beat Python in this area. By the time
Python 4 comes out, we will probably all be using PC's with 32 or more
cores, so the current limitations will be intolerable. Even today,
since no one doing anything serious uses single core machines any
more, the GIL is a huge pain in the neck which the multiprocessing
module helps only slightly. (While we are at it, lightweight threads
like Erlang's or GHC's would be very useful.)

2) Native-code compilation. Per the Alioth shootouts, Python is much
slower (even on single cores) than Java, Haskell, ML, or even Scheme.
PyPy is addressing this but it will be a while before it replaces
CPython.

3) Data encapsulation, the subject of most of this thread.

4) Static analysis. It would be great if there were a much more
powerful Pylint that could do ML-like type inference among other
things. You could still program in a dynamic, heterogeneous style if
you wanted to, but Pylint would complain about it unless you supplied
some annotations to tell it where the dynamism was and how to separate
it from the rest of the program. This is consistent with Python's
"consenting adults" principle: if consenting adults want to
participate in a BDSM scene, they should be allowed to. There would
probably have to be some new language features to assist in writing
typefully. Python 3.0 has some gestures in this direction but they
are not yet fully formed.

I believe that the PyPy project is developing the above areas in ways
CPython really could not. While we are now committed to Python 3.0
being a CPython revision that makes some minor (and in my view
somewhat gratuitous) changes to the 2.x series, I hope that Python 4.0
will be based on PyPy and have more substantial differences.
 
R

Russ P.

I confess to not knowing much about Ruby. It looks sort of Perl-ish
to me, and I always hear it is slower than Python, which is already
too slow.



Those things on your list are all nice, but I think Python has
considerable room for improvement in several areas:

1) Parallelism. Commodity desktop computers now have 8 effective cpu
cores or maybe even 16 soon (Mac Pro, Intel Core i7) but Python still
has the evil GIL that forces all threads to run on one core. Java,
Erlang, and Haskell (GHC) all beat Python in this area. By the time
Python 4 comes out, we will probably all be using PC's with 32 or more
cores, so the current limitations will be intolerable. Even today,
since no one doing anything serious uses single core machines any
more, the GIL is a huge pain in the neck which the multiprocessing
module helps only slightly. (While we are at it, lightweight threads
like Erlang's or GHC's would be very useful.)

2) Native-code compilation. Per the Alioth shootouts, Python is much
slower (even on single cores) than Java, Haskell, ML, or even Scheme.
PyPy is addressing this but it will be a while before it replaces
CPython.

3) Data encapsulation, the subject of most of this thread.

4) Static analysis. It would be great if there were a much more
powerful Pylint that could do ML-like type inference among other
things. You could still program in a dynamic, heterogeneous style if
you wanted to, but Pylint would complain about it unless you supplied
some annotations to tell it where the dynamism was and how to separate
it from the rest of the program. This is consistent with Python's
"consenting adults" principle: if consenting adults want to
participate in a BDSM scene, they should be allowed to. There would
probably have to be some new language features to assist in writing
typefully. Python 3.0 has some gestures in this direction but they
are not yet fully formed.

I believe that the PyPy project is developing the above areas in ways
CPython really could not. While we are now committed to Python 3.0
being a CPython revision that makes some minor (and in my view
somewhat gratuitous) changes to the 2.x series, I hope that Python 4.0
will be based on PyPy and have more substantial differences.


Thanks for that nice appraisal. I agree completely.

I've suggested before here (as have others) that some sort of basic
data encapsulation would be nice, but many Python users don't seem to
want anything to do with it.

Also, static analysis would be very desirable for my purposes. I would
be more than happy to declare types if someone else would write an
advanced static analyser that could make use of the type information
and formally check the code for correctness. That has been done for
other languages such as Java and Ada, and it can be very useful for
safety-critical and mission-critical software. (I am currently
developing a research prototype of safety-critical software.)

I started looking at Scala a while back. It is has many nice features.
It seamlessly combines object orientation with advanced functional
programming. It is statically typed, but the types often do not need
to be explicitly declared. It is fully "compatible" with Java, but
(like Python) it is much less verbose and more elegant, typically
requiring less (in some cases, much less) than half the lines of code
for a given task.

But I am reluctant to use Scala for several reasons. For example, it
doesn't have "continue" and "break." The Scala folks claim they are
unnecessary, but they are sure handy sometimes. Maybe my style is bad,
but I use continue and break a lot, particularly continue. Getting by
without them could be hard. The other thing is that Scala has no
default arguments and no argument passing by keyword. Those are a
couple of my favorite Python features. So I'm basically screwed.
 
R

r

I confess to not knowing much about Ruby.  It looks sort of Perl-ish
to me, and I always hear it is slower than Python, which is already
too slow.

There exists in the world of very-high-level languages only two big
players -- Python and Ruby. The only reason Ruby even exist is because
of what Mats stole from Python. Ruby is a corrupting and hideous
language, that will ruin all future "scripters" with it's abominations
of coding styles. Ruby is basically Perl's "Mini-Me". A small but
deadly form of viral infection that will plague us all for many years
to come with unreadable, unmaintainable code! I lament every day the
creation of Ruby language. Ruby took the only good things it possess
from Python.

A little History Lesson:
Python came into being around 1991 by a computer science genius named
"Guido van Rossum". This man is truly a man before his time. Python
revolutionized the world of programming and exposed the other
languages for what they are. Archaic, and redundant pieces of
petrified dino dookie. Python promotes good coding styles by
indentation(ruby stole that) Python's syntax is clear, and choice of
keywords is perfect(ruby stole some of that too). Python allows for
true OOP and true procedural(ruby tried to steal that but failed
miserably)

I like to think of Python as simplistic programming elegance. No other
high level language can compete with Python, so what did Ruby DEV do?
They stole from Python, thats what! And they did not bother to mention
this little tidbit of info to new recruits on their website!Tthey act
as if Ruby were here first. And pay no respect to the path Python
forged. Ruby owes it's very existence to Python!

I will never get over the use of "end". Why on GODS green earth would
you use indentation AND the "end" statement? That's completely
redundant. That would be the same as using two periods at the end of a
sentence.. Complete monkey logic!

Python is better, but we must stay alert and not fall asleep at the
wheel. I think Python DEV has good intention, but they do not realize
the battle that lay ahead. We must fight to get Python in every API we
can. We must stay on our toes and not let Ruby one-up us! I do not
want to see Python go down the evolutionary toilet! Lets send Ruby to
programming HELL!
 
P

Paul Rubin

r said:
Python revolutionized the world of programming and exposed the other
languages for what they are. Archaic, and redundant pieces of
petrified dino dookie. ... We must fight to get Python in every API we
can. We must stay on our toes and not let Ruby one-up us! I do not
want to see Python go down the evolutionary toilet! Lets send Ruby to
programming HELL!

Heh, I have to admire your enthusiasm. That testimonial is truly
suitable for framing ;-)
 
S

Steve Holden

r said:
[stevie]
On the other hand... Bruno's question is unfair. It is perfectly
reasonable to (hypothetically) consider Python to be the best
*existing*
language while still wanting it to be improved (for some definition
of
improvement). Just because somebody has criticisms of Python, or a
wish-
list of features, doesn't mean they hate the language.
[/stevie]

WOW Steven, i am very impressed. That's the first thing you have said
in a very long time that i totally agree with! Keep this up and i may
put you back on my Python Brethren list :)

What can one do to get *off* it? ;-)
 
S

Steve Holden

Paul said:
I confess to not knowing much about Ruby. It looks sort of Perl-ish
to me, and I always hear it is slower than Python, which is already
too slow.


Those things on your list are all nice, but I think Python has
considerable room for improvement in several areas:

1) Parallelism. Commodity desktop computers now have 8 effective cpu
cores or maybe even 16 soon (Mac Pro, Intel Core i7) but Python still
has the evil GIL that forces all threads to run on one core. Java,
Erlang, and Haskell (GHC) all beat Python in this area. By the time
Python 4 comes out, we will probably all be using PC's with 32 or more
cores, so the current limitations will be intolerable. Even today,
since no one doing anything serious uses single core machines any
more, the GIL is a huge pain in the neck which the multiprocessing
module helps only slightly. (While we are at it, lightweight threads
like Erlang's or GHC's would be very useful.)
Of course the tradition answer to this question is "reframe your
algorithm in multi-process form". My response to that tends to be "Isn't
that what computers are for?"
2) Native-code compilation. Per the Alioth shootouts, Python is much
slower (even on single cores) than Java, Haskell, ML, or even Scheme.
PyPy is addressing this but it will be a while before it replaces
CPython.
Speed, of course, isn't everything. But it would be nice to accommodate
those problem classes where it *is* significant.
3) Data encapsulation, the subject of most of this thread.
There's always more to do there, though I fell the thread started out
based on a misapprehension.
4) Static analysis. It would be great if there were a much more
powerful Pylint that could do ML-like type inference among other
things. You could still program in a dynamic, heterogeneous style if
you wanted to, but Pylint would complain about it unless you supplied
some annotations to tell it where the dynamism was and how to separate
it from the rest of the program. This is consistent with Python's
"consenting adults" principle: if consenting adults want to
participate in a BDSM scene, they should be allowed to. There would
probably have to be some new language features to assist in writing
typefully. Python 3.0 has some gestures in this direction but they
are not yet fully formed.
That part of Python 3'sw design is, of course, totally intentional. I
believe Guido is on record as saying that he hopes the uses for the
annotation feature can be concretized (is that a word) down the line
when good use cases have emerged. And I believe they will (as you
suggest to be desirable) always be optional - almost like a pragma in
other languages.
I believe that the PyPy project is developing the above areas in ways
CPython really could not. While we are now committed to Python 3.0
being a CPython revision that makes some minor (and in my view
somewhat gratuitous) changes to the 2.x series, I hope that Python 4.0
will be based on PyPy and have more substantial differences.

I have to confess that I occasionally find some of your posts a bit
pedantic and obscurantist. Just the same I appreciate your continued
presence on the list, because no matter how unreasonable I feel what you
says to be, when I examine it I always find your opinions well expressed
and well thought-out.

Sometimes I just want to shout "be quiet, Python is just fine the way it
is", but alas your objections are usually too sensible to be dismissed
in that way. In the long term I feel it has to be good for Python that
it has such conscientious critics.

Ultimately it may well be that some other project than CPython
represents the way forward for the language. I don't think that day has
arrived yet, but that doesn't mean we should exclude the possibility out
of hand.

regards
Steve
 
H

Hendrik van Rooyen

Steve Holden said:
r wrote: (about another Steven)

What can one do to get *off* it? ;-)

eeh by gum lad - there's nowt for it -
tis direct result of heavy infestation
of people on planet!

- Hendrik
 
S

Steve Holden

Hendrik said:
eeh by gum lad - there's nowt for it -
tis direct result of heavy infestation
of people on planet!
'appen so, but if folk 'ud keep it in ther trousers there'd be less on
'em and I wouldn't be so mithered.

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,011
Latest member
AjaUqq1950

Latest Threads

Top