Prothon gets Major Facelift in Vers 0.1.0 [Prothon]

Discussion in 'Python' started by Mark Hahn, May 23, 2004.

  1. Mark Hahn

    Mark Hahn Guest

    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.
     
    Mark Hahn, May 23, 2004
    #1
    1. Advertising

  2. Mark Hahn

    simo Guest

    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
    ;-)
     
    simo, May 23, 2004
    #2
    1. Advertising

  3. Mark Hahn

    moma Guest

    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.futuredesktop.org
     
    moma, May 23, 2004
    #3
  4. 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
     
    Skip Montanaro, May 23, 2004
    #4
  5. Mark Hahn

    Peter Hansen Guest

    simo wrote:

    > 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
     
    Peter Hansen, May 23, 2004
    #5
  6. Mark Hahn

    Roy Smith Guest

    Peter Hansen <> wrote:
    > 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.
     
    Roy Smith, May 23, 2004
    #6
  7. Mark Hahn

    Ryan Paul Guest

    On Sat, 22 May 2004 22:53:01 -0700, 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
    > ;-)


    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
     
    Ryan Paul, May 23, 2004
    #7
  8. Mark Hahn

    gabor Guest

    On Sun, 2004-05-23 at 09:25 -0400, Roy Smith wrote:
    > Peter Hansen <> wrote:
    > > 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.



    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 _.
     
    gabor, May 23, 2004
    #8
  9. Mark Hahn

    Mark Hahn Guest

    "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).


    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, May 23, 2004
    #9
  10. Mark Hahn

    Mark Hahn Guest

    "moma" <> wrote

    > 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, May 23, 2004
    #10
  11. Mark Hahn

    Mark Hahn Guest

    "Roy Smith" <> wrote

    > 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.
     
    Mark Hahn, May 23, 2004
    #11
  12. Mark Hahn

    simo Guest

    Ryan Paul <> wrote:

    > 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).
     
    simo, May 23, 2004
    #12
  13. Mark Hahn

    Mark Hahn Guest

    "simo" <> wrote

    > > 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).


    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?
     
    Mark Hahn, May 23, 2004
    #13
  14. Mark Hahn

    Neil Hodgson Guest

    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
     
    Neil Hodgson, May 23, 2004
    #14
  15. Mark Hahn

    Mark Hahn Guest

    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.
     
    Mark Hahn, May 23, 2004
    #15
  16. Mark Hahn

    j_mckitrick Guest

    > 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.
     
    j_mckitrick, May 24, 2004
    #16
  17. Mark Hahn

    Greg Ewing Guest

    gabor wrote:
    > 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, Computer Science Dept,
    University of Canterbury,
    Christchurch, New Zealand
    http://www.cosc.canterbury.ac.nz/~greg
     
    Greg Ewing, May 24, 2004
    #17
  18. Mark Hahn

    Greg Ewing Guest

    Mark Hahn wrote:
    > 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...

    --
    Greg Ewing, Computer Science Dept,
    University of Canterbury,
    Christchurch, New Zealand
    http://www.cosc.canterbury.ac.nz/~greg
     
    Greg Ewing, May 24, 2004
    #18
  19. Mark Hahn

    Duncan Booth Guest

    "Neil Hodgson" <> wrote in
    news:vY8sc.6634$:

    > 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.
     
    Duncan Booth, May 24, 2004
    #19
  20. Mark Hahn

    gabor Guest

    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_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
     
    gabor, May 24, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kokwooi

    Major Major Problem With ASP.NET

    kokwooi, Sep 18, 2003, in forum: ASP .Net
    Replies:
    6
    Views:
    673
    NuTcAsE
    Sep 19, 2003
  2. Mike

    NEW FACELIFT

    Mike, Apr 10, 2006, in forum: HTML
    Replies:
    0
    Views:
    398
  3. Mark Hahn
    Replies:
    20
    Views:
    593
    Mark Hahn
    Jul 13, 2004
  4. Jef Driesen
    Replies:
    2
    Views:
    1,698
    Jef Driesen
    Jan 12, 2006
  5. ara howard
    Replies:
    0
    Views:
    229
    ara howard
    Oct 28, 2003
Loading...

Share This Page