overriding built-ins

Discussion in 'Python' started by dan, Sep 28, 2003.

  1. dan

    dan Guest

    I really have two related questions.

    1) Is it possible (without recompiling and changing the core Python
    behavior) to write functions that utilize the same syntax as built-in
    functions? IE, can I create a function that does this:

    >>>printCaps "hello" #note no parentheses

    HELLO


    2) Is it possible to do this with the built-in keywords themselves, ie
    override functions such as print?

    thanks in advance -
    dan, Sep 28, 2003
    #1
    1. Advertising

  2. dan

    Gerrit Holl Guest

    dan wrote:
    > 1) Is it possible (without recompiling and changing the core Python
    > behavior) to write functions that utilize the same syntax as built-in
    > functions? IE, can I create a function that does this:
    >
    > >>>printCaps "hello" #note no parentheses

    > HELLO


    No. This is not possible.

    > 2) Is it possible to do this with the built-in keywords themselves, ie
    > override functions such as print?


    print is a statement, not a function. Builtin functions can be overwritten.
    Statements cannot be overwritten. You can override functions like len, map,
    etc. though, but it is not recommended.

    Gerrit.

    --
    53. If any one be too lazy to keep his dam in proper condition, and
    does not so keep it; if then the dam break and all the fields be flooded,
    then shall he in whose dam the break occurred be sold for money, and the
    money shall replace the corn which he has caused to be ruined.
    -- 1780 BC, Hammurabi, Code of Law
    --
    Asperger Syndroom - een persoonlijke benadering:
    http://people.nl.linux.org/~gerrit/
    Het zijn tijden om je zelf met politiek te bemoeien:
    http://www.sp.nl/
    Gerrit Holl, Sep 28, 2003
    #2
    1. Advertising

  3. dan

    John Roth Guest

    "dan" <> wrote in message
    news:...
    > I really have two related questions.
    >
    > 1) Is it possible (without recompiling and changing the core Python
    > behavior) to write functions that utilize the same syntax as built-in
    > functions? IE, can I create a function that does this:
    >
    > >>>printCaps "hello" #note no parentheses

    > HELLO


    There is no special syntax for built-in functions.
    If you really meant your example the way you wrote it,
    that's a statement, not a function, in which case the answer
    is a categorical no.

    Built-in functions are simply functions that are in a special
    dictionary that Python searches after not finding the requested
    function anywhere else. If you want to replace one, feel free.
    Then don't feel slighted when nobody else wants to deal with
    your program... [grin.]

    The Python developers are considering making at least some
    built-ins immutable and not overridable, though. That is, not changable at
    run time.
    The reason is performance - a large number of built-ins are
    simply calls to magic methods, so there's a performance gain
    to avoiding the search and extra method invocation required
    to go through the built-in dictionary for functions like len().

    > 2) Is it possible to do this with the built-in keywords themselves, ie
    > override functions such as print?


    No.

    John Roth
    >
    > thanks in advance -
    John Roth, Sep 28, 2003
    #3
  4. dan wrote:

    > I really have two related questions.
    >
    > 1) Is it possible (without recompiling and changing the core Python
    > behavior) to write functions that utilize the same syntax as built-in
    > functions?


    Yes, but don't confuse functions with statements. It seems you
    are systematically doing just that.

    > IE, can I create a function that does this:
    >
    >>>>printCaps "hello" #note no parentheses

    > HELLO


    No. You are thinking of "imitating" print, which is a STATEMENT,
    *NOT* a built-in function.

    Examples of built-in functions are input, hex, max. What they have
    in common, which sharply distinguishes them from statements: they
    use perfectly normal function syntax, and their names are not in any
    way reserved.

    > 2) Is it possible to do this with the built-in keywords themselves, ie
    > override functions such as print?


    print is a statement, not a function. No, there is no way to use
    any Python keyword except as Python uses it.


    Alex
    Alex Martelli, Sep 28, 2003
    #4
  5. dan

    dan Guest

    Thanks for the responses, and my apologies for getting the terminology
    confused. What I really should have asked is this:

    * Is there any way to create your own statements?
    and,
    * if so, can they override the names of built-in statements such as
    'print'?

    To which the answers seem to be, no, and definitely not (with a strong
    hint of "why would you ever want to do that"?)



    (dan) wrote in message news:<>...
    > I really have two related questions.
    >
    > 1) Is it possible (without recompiling and changing the core Python
    > behavior) to write functions that utilize the same syntax as built-in
    > functions? IE, can I create a function that does this:
    >
    > >>>printCaps "hello" #note no parentheses

    > HELLO
    >
    >
    > 2) Is it possible to do this with the built-in keywords themselves, ie
    > override functions such as print?
    >
    > thanks in advance -
    dan, Sep 30, 2003
    #5
  6. dan wrote:

    > Thanks for the responses, and my apologies for getting the terminology
    > confused. What I really should have asked is this:
    >
    > * Is there any way to create your own statements?
    > and,
    > * if so, can they override the names of built-in statements such as
    > 'print'?
    >
    > To which the answers seem to be, no, and definitely not (with a strong


    Right.

    > hint of "why would you ever want to do that"?)


    Actually, I suspect it's pretty obvious to most respondents why one
    might want to create their own language, embedded inside Python but
    enriched and modified. Guido himself is on record as having the far
    _dream_ of one day managing to let people define "application-specific
    languages" inside Python -- IF he can come up with a smart way to
    do it, one that won't destroy Python's simplicity and utter
    straightforwardness. I suspect that "strong hint" reflects a deep
    distrust that any such silver bullet exists, and a deep fear that in
    the pursuit of such elusive goals Python's simplicity and philosophy
    of "there should be only one way to do it" might be destroyed.

    There exist languages which have very powerful macro systems. Common
    Lisp is the canonical example, but if you prefer syntax that is rather
    more Python-like you might look into Dylan instead. Lisp and Dylan
    also share the powerful concept of "multiple dispatch", a way to do
    OO that is as superior to C++'s or Python's as the latter is superior
    to that of _purely_ single-inheritance languages [ones without even
    such helpers as Java interfaces or Ruby mixins]. Some languages do
    not really have such power, but can still come close -- e.g., in
    Smalltalk, "IF" is not a _statement_, just a method to which you pass
    code blocks, so there is little impediment to piling up "more of the
    same" to make your own application-specific language inside it; to
    a lesser extent, you can do somewhat similar things in Ruby -- and
    Perl has its own inimitable way (google for "Lingua Latina Perligata"
    if you're REALLY TRULY into such... ahem... divertissements:).

    A widespread feeling around the Python community is that Python's own
    uniqueness is SIMPLICITY. Python is straightforward and thereby most
    productive because it DOESN'T EVEN TRY to let you bend its syntax in
    strange ways (in that, it's closest to Java -- i.e., it even lacks the
    puny "preprocessor" that C and C++ come with). If you want an
    application-specific language, you design and implement it in the good
    old time-trusted way -- lexx and yacc, or their Python equivalents (of
    which there are quite a few) -- Python stays Python, your language
    is your own, and everybody (hopefully) is happy...;-).


    Alex
    Alex Martelli, Sep 30, 2003
    #6
  7. dan

    dan Guest

    Alex Martelli <> wrote in message news:<Yfbeb.194368$>...
    ....
    > Actually, I suspect it's pretty obvious to most respondents why one
    > might want to create their own language, embedded inside Python but
    > enriched and modified. Guido himself is on record as having the far
    > _dream_ of one day managing to let people define "application-specific
    > languages" inside Python -- IF he can come up with a smart way to
    > do it, one that won't destroy Python's simplicity and utter
    > straightforwardness. I suspect that "strong hint" reflects a deep
    > distrust that any such silver bullet exists, and a deep fear that in
    > the pursuit of such elusive goals Python's simplicity and philosophy
    > of "there should be only one way to do it" might be destroyed.


    Excellent response -- of course that is exactly what I would like to
    do. And I appreciate that Python's simplicity and uniformity can be
    seen as pluses. Perhaps this is a request for a different type of
    meta-language, and shouldn't be shoe-horned into Python. I'll look at
    Dylan and some of the other stuff you mention.

    Of course Python would be a great language in which to develop a
    parser/interpreter/compiler for such a language. Perhaps it would
    make sense to develop a new syntax that shares the Python bytecodes
    and import methodology, so you could start with a large library of
    support modules and such.

    However that brings up an interesting issue: the plethora of new
    languages with bytecode interpreters (Java, Python, C#) are starting
    to concern me. It seems like there could be a place for some sort of
    standardized, low-level bytecode syntax, so that work on things like
    JIC compilation can occur independently of high-level changes and
    alternatives to source syntax.

    >
    > There exist languages which have very powerful macro systems. Common
    > Lisp is the canonical example, but if you prefer syntax that is rather
    > more Python-like you might look into Dylan instead. Lisp and Dylan
    > also share the powerful concept of "multiple dispatch", a way to do
    > OO that is as superior to C++'s or Python's as the latter is superior
    > to that of _purely_ single-inheritance languages [ones without even
    > such helpers as Java interfaces or Ruby mixins]. Some languages do
    > not really have such power, but can still come close -- e.g., in
    > Smalltalk, "IF" is not a _statement_, just a method to which you pass
    > code blocks, so there is little impediment to piling up "more of the
    > same" to make your own application-specific language inside it; to
    > a lesser extent, you can do somewhat similar things in Ruby -- and
    > Perl has its own inimitable way (google for "Lingua Latina Perligata"
    > if you're REALLY TRULY into such... ahem... divertissements:).
    >
    > A widespread feeling around the Python community is that Python's own
    > uniqueness is SIMPLICITY. Python is straightforward and thereby most
    > productive because it DOESN'T EVEN TRY to let you bend its syntax in
    > strange ways (in that, it's closest to Java -- i.e., it even lacks the
    > puny "preprocessor" that C and C++ come with). If you want an
    > application-specific language, you design and implement it in the good
    > old time-trusted way -- lexx and yacc, or their Python equivalents (of
    > which there are quite a few) -- Python stays Python, your language
    > is your own, and everybody (hopefully) is happy...;-).
    >
    >
    > Alex
    dan, Oct 2, 2003
    #7
  8. dan

    Andrew Dalke Guest

    dan:
    > However that brings up an interesting issue: the plethora of new
    > languages with bytecode interpreters (Java, Python, C#) are starting
    > to concern me. It seems like there could be a place for some sort of
    > standardized, low-level bytecode syntax, so that work on things like
    > JIC compilation can occur independently of high-level changes and
    > alternatives to source syntax.


    The .Net system was supposed to help some of that. As I recall, some
    changes were made to make it easier to support tail recursive languages.

    For something targeted to dynamically typed languages, look up
    "Parrot", which is part of the Perl6 effort and which is also supposed
    to support Python. There's a challenge out that Parrot will run some
    appropriate benchmark (yet to be decided) faster than the CPython
    implementation by some time next year. (OSCON?)

    Andrew
    Andrew Dalke, Oct 2, 2003
    #8
    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. Pettersen, Bjorn S

    RE: overriding built-ins

    Pettersen, Bjorn S, Oct 2, 2003, in forum: Python
    Replies:
    1
    Views:
    393
    John Roth
    Oct 2, 2003
  2. Marco Aschwanden
    Replies:
    3
    Views:
    289
    Carlos Ribeiro
    Sep 3, 2004
  3. Carlos Ribeiro
    Replies:
    3
    Views:
    279
  4. Jp Calderone
    Replies:
    3
    Views:
    274
    Carlos Ribeiro
    Sep 6, 2004
  5. Carlos Ribeiro
    Replies:
    30
    Views:
    736
    Alex Martelli
    Sep 9, 2004
Loading...

Share This Page