overriding built-ins

[dan]

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:
HELLO


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

thanks in advance -

 

[Gerrit Holl]

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:

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

 

[John Roth]

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:

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

 

[Alex Martelli]

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:

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

 

[dan]

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

 

[Alex Martelli]

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

 

[dan]

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

 

[Andrew Dalke]

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
(e-mail address removed)