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]

simo wrote:

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.futuredeskt op.org

[gabor]

On Sun, 2004-05-23 at 21:46 +0000, Neil Hodgson wrote:

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_ca st<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.l ength)

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

[gabor]

On Sun, 2004-05-23 at 15:04 -0700, Mark Hahn wrote:

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?

not exactly...

i don't need restriction, only a hint...

if i look thru some java code, i immediately see what variables/methods
should/can i access... it's not the same for python...

for example at work where i use java, there are classes that have
10-15methods, but only 4public ones... it immediately gets simplier to
understand/use the class
gabor

[Bruno Desthuilliers]

Ryan Paul wrote:

On Sat, 22 May 2004 22:53:01 -0700, simo wrote:

(snip)

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

(snip)
I dont understand why everybody seems to want a machinecode compiler. It
wont make a high-level, dynamically typed language run any faster.
Err... You might want to check some Common Lisp implementations .
--SegPhault

Note that here it should read 'sigfault' !-)

Bruno

[Ville Vainio]

>>>>> "Ryan" == Ryan Paul <se*******@sbcg lobal.net> writes:

Ryan> check out ruby. It is very similar to python, but one of the
Ryan> many benefits it has over python, is ability to distinguish
Ryan> 'real' private, public, and protected
Ryan> variables/methods. Ruby does not allow multiple inheritance,
Ryan> and

Python has private methods too:

class C:
def stuff(self):
_privatestuff(s elf,2)
print "val is",self.val

def _privatestuff(s elf, arg):
self.val = arg

Though I would expect the people that read/use my code to understand
that if I prepended a _ on attribute name, they would have the brain
to not use it as a part of the "official" API. If they absolutely need
to use something private (it happens - world has seen several badly
designed APIs), they can. At least they don't need to resort to
various horrible hacks to do it.

I tend to think that emphasizing private/protected access restrictions
is an artifact of not understanding modern programming realities and
dynamics properly. School teaches access labels as an essential
feature of OO (encapsulation) , and it takes some real world experience
implementing something of lasting value *fast* to unlearn it.

Ryan> it supports a very powerful mixin system- it's OO mechanisms
Ryan> and syntax generally seem better than pythons.

Not to mention that it's much closer to Smalltalk. And it's much
better than Perl too. Python OO is a hack! It's an add-on, not
built-in like in Ruby!

etc, ad infinitum.

Inter-newsgroup advocacy efforts are rather pointless and mostly serve
to create yet more flamewars. Ruby and Python are within the same 10%
productivity-wise (which one is winning depends on the programmer),
but Python is massively more mature and popular (e.g. going to be
shipping with Nokia S60 smartphones RSN hopefully [1]). You do the
math.

[1] http://www.guardian.co.uk/online/sto...182803,00.html

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

It could make the language run much faster.

--
Ville Vainio http://tinyurl.com/2prnb

[Mark Hahn]

"gabor" <ga***@z10n.net > wrote

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?
not exactly...

i don't need restriction, only a hint...

if i look thru some java code, i immediately see what variables/methods
should/can i access... it's not the same for python...

for example at work where i use java, there are classes that have
10-15methods, but only 4public ones... it immediately gets simplier to
understand/use the class

I sounds to me like you want a better documentation solution, not an
encapsulation solution. Now that is something I agree with 100% and have
near the top of the list in Prothon. I personally think docs are a weak
point in Python.

[gabor]

On Mon, 2004-05-24 at 18:10, Mark Hahn wrote:

"gabor" <ga***@z10n.net > wrote

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?

not exactly...

i don't need restriction, only a hint...

if i look thru some java code, i immediately see what variables/methods
should/can i access... it's not the same for python...

for example at work where i use java, there are classes that have
10-15methods, but only 4public ones... it immediately gets simplier to
understand/use the class

I sounds to me like you want a better documentation solution, not an
encapsulation solution. Now that is something I agree with 100% and have
near the top of the list in Prothon. I personally think docs are a weak
point in Python.

documentation is fine.... the more the better...

but the argument that
more-docs-should-be-enough-because-you-can-document-which-functions-are-private
reminds me a little of the
but-you-can-write-object-oriented-code-in-assembler....

or that you-can-write-object-oriented-code-in-c...

yes, you can implement the needed mechanism in every language, but it's
not always fun....
:)

gabor

[Mark Hahn]

"gabor" <ga***@z10n.net > wrote

yes, you can implement the needed mechanism in every language, but it's
not always fun....

We'll just have to make sure it's fun in Prothon. Maybe you'll have to
elaborate a little more on what you think is fun encapsulation documentation
and what isn't.

I myself think that putting underbars in front of every var like _var is not
fun. Do you agree?

I also don't think declaring all vars as in "private var" is fun either, do
you? If I did, I'd be using C++.

So to me, documenting the public vars makes the most sense. They need some
explaining anyway. So now the only question is, what is a fun and painless
way to document public vars. It would be nice if it had these properties:

1) There should be some reward or lack of punishment for actually doing the
documentation. I was thinking that Prothon could have some cool doc tool
that programmers would want to use that would choke and refuse to finish
without proper doc definitions. Maybe the interpreter itself could even
give warnings.

2) The doc syntax should be painless, friendly, and intelligent enough so
human-added stuff is minimal.

Any ideas in this area would be greatly welcomed. Implementing a half-baked
scheme would be as good as no scheme because it wouldn't be used.