Prothon gets Major Facelift in Vers 0.1.0 [Prothon]

[Mark Hahn]

There is a new release of Prothon that I think is worth mentioning here.
Prothon version 0.1.0 has changed almost beyond recognition compared to what
was discussed here before. For example: the "Perl-like" symbols are gone
and the "self" keyword is back, replacing the period. Prothon has gotten
more "python-like", simpler, and more powerful, all at the same time.

There is a new tutorial that covers Prothon completely without assuming any
knowledge of Python or any other language. The Prothon/Python differences
page now has links to the relevant section of this tutorial.
See http://prothon.org.

Some of these differences are:

Locals and globals are gone and replaced by a simple scheme that allows you
to access any local or external variable from inside a block or function
scope by name. You may also modify any existing variable outside of the
current scope by simply prepending "outer" to the variable name as in
"outer.x = 1". You can even do this "outer access" when the variable is in
a function that has quit running, giving you "closures" with no need for a
special syntax.

There is a new powerful self-binding method syntax that gives you the
ability to explicitly specify the "self" to bind to a function call with
"obj.func{self}(args)". This allows the full power of message-passing to be
used without compromising the simplicity of function calling. This powerful
and general scheme also solves the problem of calling methods when there is
no such thing as a class to define what a method is. Intelligent defaults
for {self} allow most method calls to be the intuiitive and simple form
obj.call().

The "with" keyword now just creates a new local scope instead of another
"self" which was so confusing before. So "self" is now the simple meaning
of the instance object inside a method as it is in Python.

There is a new "object" keyword which works almost identically to the
"class" keyword, yet also works as a general object creation and
initialization statement. It combines object creation and the "with"
statement.

 

[simo]

One thing that might attract me from Python to Prothon is if it had
proper private medthods - i.e. not just name mangling like __myDef
which can be overridden using _myClass__myDef (as the interpreter
does).

Proper encapsulation is needed before the C++ brigade will take
P[y/ro]thon seriously as an OO language, oh and a machinecode compiler
;-)

 

[moma]

One thing that might attract me from Python to Prothon is if it had
proper private medthods - i.e. not just name mangling like __myDef
which can be overridden using _myClass__myDef (as the interpreter
does).

Proper encapsulation is needed before the C++ brigade will take
P[y/ro]thon seriously as an OO language, oh and a machinecode compiler
;-)

PROthon should implement {...} as optional block-beg and end marks.

# Original PROthon code (uses indentation)
def abc(_x):
if _x ...:
do_1()
do_2()
do_3()


Could become

#!/usr/bin/pROthon
#pragma(C_STYLE_BLOCK=1) # <- Valid within this file/module scope

def abc(_x):
{
if _x ...:
{
do_1()
do_2()
}
do_3()
}

----------------------------------------

The lack of "class" type and direct creation and use of objects is very
handy for "Prototype-based Programming" (that's PROthon)

Who said OO-programming must have a class type ?

// moma
http:/www.futuredesktop.org

 

[Skip Montanaro]

simo> Proper encapsulation is needed before the C++ brigade will take
simo> P[y/ro]thon seriously as an OO language, ...

Note that Python is not targeted at winning over C++ programmers, so that's
unlikely to motivate anyone to tighten up Python's current name mangling.
That's designed to prevent accidents, not access.

Skip

 

[Peter Hansen]

Proper encapsulation is needed before the C++ brigade will take
P[y/ro]thon seriously as an OO language

If by "C++ brigade" you mean simply "C++ programmers", then
I can assure you that you are wrong since I was, once, such
a beast.

If by "C++ brigade" you mean "programmers who think C++ does
things the right way" then the only way to get them to take
Python seriously will be either (a) to change Python into
something that closely resembles C++, or (b) to change those
programmers so that their thinking fits Python better.

Merely adding "proper encapsulation" (and I happen to believe
Python already has encapsulation that is quite proper) will
not suffice. And that's a good thing, too.... ;-)

-Peter

 

[Roy Smith]

If by "C++ brigade" you mean "programmers who think C++ does
things the right way" then the only way to get them to take
Python seriously will be either (a) to change Python into
something that closely resembles C++, or (b) to change those
programmers so that their thinking fits Python better.

The world doesn't need another language that looks like C++. Java
already fills that niche quite nicely.

Merely adding "proper encapsulation" (and I happen to believe
Python already has encapsulation that is quite proper) will
not suffice. And that's a good thing, too.... ;-)

Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens
wearing a T-shirt about who's in more danger.

 

[Ryan Paul]

One thing that might attract me from Python to Prothon is if it had
proper private medthods - i.e. not just name mangling like __myDef
which can be overridden using _myClass__myDef (as the interpreter
does).

Proper encapsulation is needed before the C++ brigade will take
P[y/ro]thon seriously as an OO language, oh and a machinecode compiler
;-)

check out ruby. It is very similar to python, but one of the many benefits
it has over python, is ability to distinguish 'real' private, public, and
protected variables/methods. Ruby does not allow multiple inheritance, and
it supports a very powerful mixin system- it's OO mechanisms and syntax
generally seem better than pythons.

I dont understand why everybody seems to want a machinecode compiler. It
wont make a high-level, dynamically typed language run any faster.

--SegPhault

 

[gabor]

The world doesn't need another language that looks like C++. Java
already fills that niche quite nicely.


Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face.

hmmm...i understand that you can cast away const,
but what about...

class C
{
private x;
};

(i hope it's correct c++ (i haven't written c++ in the last 2years)).

so, how can you write to that variable from the outside?

ok, you can take the address of an instance, cast it to (int*) and
somehow calculate the address of C.x .but it's very dangerous,because a
different compiler can compile it to a different thing and so on...

so, except the pointer+offset algo detailed above (which i consider
highly unpropable to happen), how can an user of my class/library access
that variable?

gabor

p.s: just for the record.no, i don't like c++. yes,i would like to have
private variables in python. no, i don't like perl => i don't want to
prefix all my private vars with _.

 

[Mark Hahn]

One thing that might attract me from Python to Prothon is if it had
proper private medthods - i.e. not just name mangling like __myDef
which can be overridden using _myClass__myDef (as the interpreter
does).

Interesting question. We don't have classes, so I'm not sure what we would
be encapsulating and where we would encapsulate it.

I developed Prothon so there would be a language without all this complexity
and things to argue over. I guess people don't want simplicity after all.
Without complexity there would be nothing to argue about on mailing lists


If you want to see what I mean by simplicity, check this out:

http://prothon.org/tutorial/tutorial8.htm#pbp

 

[Mark Hahn]

The lack of "class" type and direct creation and use of objects is very
handy for "Prototype-based Programming" (that's PROthon)

Who said OO-programming must have a class type ?

Unfortunately ten million textbooks say so. That is why when refering to
Prototype-based Programming, we call it "Object-Centric" programming, not
"Object-Oriented".

 

[Mark Hahn]

Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens
wearing a T-shirt about who's in more danger.

I love that analogy. It works on so many levels. I picture the t-shirt as
tie-died and the guy wearing it with a mustache in San Francisco while the
C++ guy has a suit on under the armor.

 

[simo]

I dont understand why everybody seems to want a machinecode compiler. It
wont make a high-level, dynamically typed language run any faster.

I think distribution is the issue really, not speed.

You can have a more secure distributable .exe file and not have to
bundle the huge Python23.DLL. I can do in 8Kb of compiled C++ what I
can only do in about 2Mb of Python (of course it'll take me twice as
long to figure out how to program it in C++, which is the usual
argument for Python).

 

[Mark Hahn]

I think distribution is the issue really, not speed.

You can have a more secure distributable .exe file and not have to
bundle the huge Python23.DLL. I can do in 8Kb of compiled C++ what I
can only do in about 2Mb of Python (of course it'll take me twice as
long to figure out how to program it in C++, which is the usual
argument for Python).

I think that 2 MB could be brought down to something reasonable like 0.1 MB
with a proper "compiler". That is a nice goal to work towards in Prothon.

BTW: The 0.008 MB you are talking about either does nothing useful or is
just calling windows high-level routines. I assume maybe you are
exaggerating?

 

[Neil Hodgson]

gabor:

hmmm...i understand that you can cast away const,
but what about...

class C
{
private x;
};

Technique 1:

class D {
public:
int x;
};

C c;
(reinterpret_cast<D*>(&c))->x = 1;

Technique 2:

#define private public
#include <C_definition.h>
#undef private

C c;
c.x = 1;

In both of these it is obvious that the encapsulation rules are being
broken which is exactly the same situation as when someone uses the mangled
name in Python. I have used technique 2 in production code where a library
could not be altered and access to private methods was required.

Neil

 

[Mark Hahn]

Does any Python user have a story of regret of using an object's attribute
when they should not have and encapsulation would have saved their butts?

In my Python usage when I found that I shouldn't be directly accessing an
attribute it was no different than finding any other bug and I refactored
and moved on. It certainly would have been more work to worry about all the
attributes to start with.

Does anyone have any story of encapsulation being a hero in any situation or
of regret at not having it? I've programmed since the 60's and I have no
regrets in 30+ years in not having encapsulation when I didn't have it and
no hero stories in my four years of using Java.

I certainly don't miss it in my Prothon.

 

[j_mckitrick]

check out ruby. It is very similar to python, but one of the many benefits

it has over python, is ability to distinguish 'real' private, public, and
protected variables/methods. Ruby does not allow multiple inheritance, and
it supports a very powerful mixin system- it's OO mechanisms and syntax
generally seem better than pythons.

But I don't like anything about the syntax of Ruby. Python is so much
more natural to read.

 

[Greg Ewing]

class C
{
private x;
};

so, how can you write to that variable from the outside?

You write your own .h file which is exactly the same
except that it doesn't say "private".

This probably isn't any safer than casting, but the
point is, if you're going to these lengths you know
what you're trying to do and probably have a good
reason for it. Exactly the same thing applies to
Python name mangling. You're prevented from accidentally
messing with things, not from deliberately messing
with them.

 

[Greg Ewing]

BTW: The 0.008 MB you are talking about either does nothing useful or is
just calling windows high-level routines. I assume maybe you are
exaggerating?

I think it depends on what you mean by "useful". I imagine
you could fit a lot of quite useful functionality into that
much code, as long as you didn't require it to have a fancy
GUI interface, etc.

Heck, 8-bit micros used to fit an entire operating system
and BASIC interpreter into 8-16KB or so...

 

[Duncan Booth]

Technique 2:

#define private public
#include <C_definition.h>
#undef private

C c;
c.x = 1;

In both of these it is obvious that the encapsulation rules are
being
broken which is exactly the same situation as when someone uses the
mangled name in Python. I have used technique 2 in production code
where a library could not be altered and access to private methods was
required.

To me, this is one of the greatest arguments against use of private
variables in C++.

I have also been reduced to using exactly this technique when faced with a
library where the implementation was visible to the whole world, but the
public interface didn't make enough of it accessible. I can think of
numerous times when private names have been a real pain, but I have never
had a problem which would have been solved by making a public name private.

In C++ private doesn't hide the implementation at all, it simply restricts
access. In Python, the __ prefix for private variables does some
(rudimentary) hiding but doesn't really restrict access.

In a language where the implementation can be hidden there may perhaps be
reason to use private although defining the public part as an interface is
a better way to go. Even in C++ you can use interfaces to hide the
implementation, and for those (rare) cases where you need to get into the
internals you may safely cast to the specific implementation and get at its
internals (provided nobody used private) without having to resort to
unsightly kludges. Sadly many C++ programmers fail to grasp this concept.

 

[gabor]

gabor:


Technique 1:

class D {
public:
int x;
};

C c;
(reinterpret_cast<D*>(&c))->x = 1;

Technique 2:

#define private public
#include <C_definition.h>
#undef private

C c;
c.x = 1;

thanks...very interesting.

In both of these it is obvious that the encapsulation rules are being
broken which is exactly the same situation as when someone uses the mangled
name in Python. I have used technique 2 in production code where a library
could not be altered and access to private methods was required.

look...i am not asking for a way in python to COMPLETELY RESTRICT the
access to a variable... i hint is enough... now...if i know correctly
that means that i have to prefix my wanto-to-be-private variables with a
"_"... that restriction would be enough for me. my problem is with the
syntax. i HATE anything that even remotely resembles perl/hungarian
notation. why cannot i do it somehow as we create static-methods ....

class C:
def __init__(self):
self.lenght = 5
self.lenght =private(self.length)

or something like it.

the point is:
i only want to WRITE that the variable is private once...
i don't want to deal with _prefixed variables in my whole code...

this is imho of course

gabor