Is it bad style to override the built-in function `type`?

Discussion in 'Python' started by Michael Herrmann, Nov 23, 2012.

  1. Hi,

    do you think it's bad style to override the built-in function `type`? I'm co-developing a GUI automation library called Automa (http://www.getautoma.com) and 'type' would be a very fitting name for a function that generates artificial key strokes.

    This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.

    For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the other thread.

    Thank you very much!
    Michael
    Michael Herrmann, Nov 23, 2012
    #1
    1. Advertising

  2. On 11/23/2012 8:12 AM, Michael Herrmann wrote:
    > Hi,
    >
    > do you think it's bad style to override the built-in function `type`? I'm co-developing a GUI automation library called Automa (http://www.getautoma.com) and 'type' would be a very fitting name for a function that generates artificial key strokes.
    >
    > This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
    >
    > For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the other thread.
    >
    > Thank you very much!
    > Michael
    >


    http://stackoverflow.com/questions/...n-function-name-as-an-attribute-or-method-ide
    Emile van Sebille, Nov 23, 2012
    #2
    1. Advertising

  3. Michael Herrmann

    Roy Smith Guest

    In article <>,
    Michael Herrmann <> wrote:

    > do you think it's bad style to override the built-in function `type`? I'm
    > co-developing a GUI automation library called Automa
    > (http://www.getautoma.com) and 'type' would be a very fitting name for a
    > function that generates artificial key strokes.


    For local variable names with small scopes, I don't fret much about
    overriding built-in names. For a library, I would try harder to find
    non-conflicting names. How about one of these:

    type_text()
    enter_text()
    keyboard()

    PS, A suggestion about your website. In these days of tech exit
    strategies and M/A crazyness, putting "Purchase" and "Company" as
    adjacent items in the main menu might be misconstrued. At first glance,
    I read it as "Purchase company". Twitter Bootstrap, no?
    Roy Smith, Nov 23, 2012
    #3
  4. Thanks for your replies,

    Emile, the link you gave is about attribute names, and does not give a definite answer. I wrote this post in hope for an answer to the question how many people here think it would be OK to override `type` in the very specificcontext of a GUI automation library, and how many people would not like it..

    Roy, thanks for your input, we already have tried hard in the thread I quoted in my first post (http://bit.ly/10aOy4H). We found some non-conflicting names, however they're not quite as fitting as `type` and I'm here hoping to find out how "bad" overriding type would be, to be able to weigh it against the drawbacks of using a worse-fitting name. Regarding the website: I had never thought of that! ;-) I guess we should rename it to "About"...

    I'm sorry for spamming this mailing list so much... I promise it won't be for much longer.

    Best,
    Michael

    On Friday, November 23, 2012 5:12:39 PM UTC+1, Michael Herrmann wrote:
    > Hi,
    >
    >
    >
    > do you think it's bad style to override the built-in function `type`? I'mco-developing a GUI automation library called Automa (http://www.getautoma..com) and 'type' would be a very fitting name for a function that generatesartificial key strokes.
    >
    >
    >
    > This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
    >
    >
    >
    > For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the otherthread.
    >
    >
    >
    > Thank you very much!
    >
    > Michael
    Michael Herrmann, Nov 23, 2012
    #4
  5. Michael Herrmann

    Terry Reedy Guest

    On 11/23/2012 11:22 AM, Joel Goldstick wrote:
    >
    >
    >
    > On Fri, Nov 23, 2012 at 11:12 AM, Michael Herrmann
    > < <mailto:>>
    > wrote:
    >
    > Hi,
    >
    > do you think it's bad style to override the built-in function
    > `type`? I'm co-developing a GUI automation library called Automa
    > (http://www.getautoma.com) and 'type' would be a very fitting name
    > for a function that generates artificial key strokes.
    >
    > Personally, I think this is a horrible idea. On this list and the tutor
    > list, people often use variable names that are already defined in the
    > language. It leads to non obvious errors -- especially when revisting
    > old code. Why not call the thing 'key_stroke'?


    I agree.

    --
    Terry Jan Reedy
    Terry Reedy, Nov 23, 2012
    #5
  6. Thank you for your feedback. I sent the following reply to Joel but it didn't make it through to the mailing list:

    Hi Joel,

    thanks for your reply. I can see why you think it's a bad idea. The reason why we want to call it `type` is that this is precisely the word that is most commonly used in our context, GUI automation. There are alternative names (see http://bit.ly/10aOy4H for a huge list) , but leaving aside the fact that Python has an overwriteable meaning for `type`, none fits quite as well. One of the main goals of our tool/API is to be as close to everyday English as possible, and thus hopefully to be intuitive also for novice users. For this reason it is very tempting for us to use `type`. Several people inthe original thread http://bit.ly/10aOy4H have suggested `type` because itbest fits our problem domain, and have said that they don't mind it overriding a built-in function.

    I know it's a common beginner's mistake to incautiously override built-in functions. However, we put in a lot of research and have come to the conclusion that, if Python had not already defined it, `type` would be the best name. We are now trying to evaluate how bad the disadvantages you mention arein comparison to the advantage to having a name that is more intuitive to use in the problem domain.

    Can you somehow relate to my explanations, or are your experiences with overwriting built-in variables so bad that you would advise to never ever do it?

    Thanks!
    Michael

    On Friday, November 23, 2012 7:36:20 PM UTC+1, Terry Reedy wrote:
    > On 11/23/2012 11:22 AM, Joel Goldstick wrote:
    >
    > >

    >
    > >

    >
    > >

    >
    > > On Fri, Nov 23, 2012 at 11:12 AM, Michael Herrmann

    >
    > > <Michael Herrmann>

    >
    > > wrote:

    >
    > >

    >
    > > Hi,

    >
    > >

    >
    > > do you think it's bad style to override the built-in function

    >
    > > `type`? I'm co-developing a GUI automation library called Automa

    >
    > > (http://www.getautoma.com) and 'type' would be a very fitting name

    >
    > > for a function that generates artificial key strokes.

    >
    > >

    >
    > > Personally, I think this is a horrible idea. On this list and the tutor

    >
    > > list, people often use variable names that are already defined in the

    >
    > > language. It leads to non obvious errors -- especially when revisting

    >
    > > old code. Why not call the thing 'key_stroke'?

    >
    >
    >
    > I agree.
    >
    >
    >
    > --
    >
    > Terry Jan Reedy
    Michael Herrmann, Nov 23, 2012
    #6
  7. Thank you for your feedback. I sent the following reply to Joel but it didn't make it through to the mailing list:

    Hi Joel,

    thanks for your reply. I can see why you think it's a bad idea. The reason why we want to call it `type` is that this is precisely the word that is most commonly used in our context, GUI automation. There are alternative names (see http://bit.ly/10aOy4H for a huge list) , but leaving aside the fact that Python has an overwriteable meaning for `type`, none fits quite as well. One of the main goals of our tool/API is to be as close to everyday English as possible, and thus hopefully to be intuitive also for novice users. For this reason it is very tempting for us to use `type`. Several people inthe original thread http://bit.ly/10aOy4H have suggested `type` because itbest fits our problem domain, and have said that they don't mind it overriding a built-in function.

    I know it's a common beginner's mistake to incautiously override built-in functions. However, we put in a lot of research and have come to the conclusion that, if Python had not already defined it, `type` would be the best name. We are now trying to evaluate how bad the disadvantages you mention arein comparison to the advantage to having a name that is more intuitive to use in the problem domain.

    Can you somehow relate to my explanations, or are your experiences with overwriting built-in variables so bad that you would advise to never ever do it?

    Thanks!
    Michael

    On Friday, November 23, 2012 7:36:20 PM UTC+1, Terry Reedy wrote:
    > On 11/23/2012 11:22 AM, Joel Goldstick wrote:
    >
    > >

    >
    > >

    >
    > >

    >
    > > On Fri, Nov 23, 2012 at 11:12 AM, Michael Herrmann

    >
    > > <Michael Herrmann>

    >
    > > wrote:

    >
    > >

    >
    > > Hi,

    >
    > >

    >
    > > do you think it's bad style to override the built-in function

    >
    > > `type`? I'm co-developing a GUI automation library called Automa

    >
    > > (http://www.getautoma.com) and 'type' would be a very fitting name

    >
    > > for a function that generates artificial key strokes.

    >
    > >

    >
    > > Personally, I think this is a horrible idea. On this list and the tutor

    >
    > > list, people often use variable names that are already defined in the

    >
    > > language. It leads to non obvious errors -- especially when revisting

    >
    > > old code. Why not call the thing 'key_stroke'?

    >
    >
    >
    > I agree.
    >
    >
    >
    > --
    >
    > Terry Jan Reedy
    Michael Herrmann, Nov 23, 2012
    #7
  8. On 23Nov2012 10:41, Michael Herrmann <> wrote:
    [...]
    | I know it's a common beginner's mistake to incautiously override
    | built-in functions. However, we put in a lot of research and have come to
    | the conclusion that, if Python had not already defined it, `type` would
    | be the best name. We are now trying to evaluate how bad the disadvantages
    | you mention are in comparison to the advantage to having a name that is
    | more intuitive to use in the problem domain.
    |
    | Can you somehow relate to my explanations, or are your experiences
    | with overwriting built-in variables so bad that you would advise to
    | never ever do it?

    My own experience says that it is a thing best avoiding without a truly
    amazing reason not to.

    I urge you not to: type(foo) is a very basic Python idiom and you're
    breaking it. One day it _will_ bite you or your users. You will
    understand, but I would give goods odds that some of your users will not
    the day they go to examine the type of an object for perfectly normal
    pythonic reasons.

    Example: I have a module that stores "objects" and they have as a
    primary key a "name" and a "type" - not Python types, just strings.
    Accordingly I have a similar situation to yours: the desire to use the
    word "type". Fortunately for me, as an attribute in (usually small) code
    chunks I can usually go:

    t = foo.type
    ... work with t here ...

    Where I must pass one as a parameter I use the common convention of
    naming the parameter "type_" at the receiving end.

    For the calling end, as in your case, you want to use:

    type(blah)

    Is it at all possible to make all uses of your "type" function method
    calls? Eg:

    something.type("text to type")

    It avoids the overloading while keeping your desired name.
    --
    Cameron Simpson <>

    Wouldn't it be great if all emergency stopping situations occurred on your
    favourite bit of road......you'd probably know about it before it happened
    and would be able to take other evasive action.
    - Neville Brabet <>
    Cameron Simpson, Nov 23, 2012
    #8
  9. Hi,

    how about "write" instead of "type"? Just came to me in a flash of inspiration. I know it's also pretty general but at least it's not a built-in!

    Thanks!
    Michael

    On Friday, November 23, 2012 11:30:18 PM UTC+1, Cameron Simpson wrote:
    > On 23Nov2012 10:41, Michael Herrmann <> wrote:
    >
    > [...]
    >
    > | I know it's a common beginner's mistake to incautiously override
    >
    > | built-in functions. However, we put in a lot of research and have come to
    >
    > | the conclusion that, if Python had not already defined it, `type` would
    >
    > | be the best name. We are now trying to evaluate how bad the disadvantages
    >
    > | you mention are in comparison to the advantage to having a name that is
    >
    > | more intuitive to use in the problem domain.
    >
    > |
    >
    > | Can you somehow relate to my explanations, or are your experiences
    >
    > | with overwriting built-in variables so bad that you would advise to
    >
    > | never ever do it?
    >
    >
    >
    > My own experience says that it is a thing best avoiding without a truly
    >
    > amazing reason not to.
    >
    >
    >
    > I urge you not to: type(foo) is a very basic Python idiom and you're
    >
    > breaking it. One day it _will_ bite you or your users. You will
    >
    > understand, but I would give goods odds that some of your users will not
    >
    > the day they go to examine the type of an object for perfectly normal
    >
    > pythonic reasons.
    >
    >
    >
    > Example: I have a module that stores "objects" and they have as a
    >
    > primary key a "name" and a "type" - not Python types, just strings.
    >
    > Accordingly I have a similar situation to yours: the desire to use the
    >
    > word "type". Fortunately for me, as an attribute in (usually small) code
    >
    > chunks I can usually go:
    >
    >
    >
    > t = foo.type
    >
    > ... work with t here ...
    >
    >
    >
    > Where I must pass one as a parameter I use the common convention of
    >
    > naming the parameter "type_" at the receiving end.
    >
    >
    >
    > For the calling end, as in your case, you want to use:
    >
    >
    >
    > type(blah)
    >
    >
    >
    > Is it at all possible to make all uses of your "type" function method
    >
    > calls? Eg:
    >
    >
    >
    > something.type("text to type")
    >
    >
    >
    > It avoids the overloading while keeping your desired name.
    >
    > --
    >
    > Cameron Simpson
    >
    >
    >
    > Wouldn't it be great if all emergency stopping situations occurred on your
    >
    > favourite bit of road......you'd probably know about it before it happened
    >
    > and would be able to take other evasive action.
    >
    > - Neville Brabet
    Michael Herrmann, Nov 24, 2012
    #9
  10. Hi,

    how about "write" instead of "type"? Just came to me in a flash of inspiration. I know it's also pretty general but at least it's not a built-in!

    Thanks!
    Michael

    On Friday, November 23, 2012 11:30:18 PM UTC+1, Cameron Simpson wrote:
    > On 23Nov2012 10:41, Michael Herrmann <> wrote:
    >
    > [...]
    >
    > | I know it's a common beginner's mistake to incautiously override
    >
    > | built-in functions. However, we put in a lot of research and have come to
    >
    > | the conclusion that, if Python had not already defined it, `type` would
    >
    > | be the best name. We are now trying to evaluate how bad the disadvantages
    >
    > | you mention are in comparison to the advantage to having a name that is
    >
    > | more intuitive to use in the problem domain.
    >
    > |
    >
    > | Can you somehow relate to my explanations, or are your experiences
    >
    > | with overwriting built-in variables so bad that you would advise to
    >
    > | never ever do it?
    >
    >
    >
    > My own experience says that it is a thing best avoiding without a truly
    >
    > amazing reason not to.
    >
    >
    >
    > I urge you not to: type(foo) is a very basic Python idiom and you're
    >
    > breaking it. One day it _will_ bite you or your users. You will
    >
    > understand, but I would give goods odds that some of your users will not
    >
    > the day they go to examine the type of an object for perfectly normal
    >
    > pythonic reasons.
    >
    >
    >
    > Example: I have a module that stores "objects" and they have as a
    >
    > primary key a "name" and a "type" - not Python types, just strings.
    >
    > Accordingly I have a similar situation to yours: the desire to use the
    >
    > word "type". Fortunately for me, as an attribute in (usually small) code
    >
    > chunks I can usually go:
    >
    >
    >
    > t = foo.type
    >
    > ... work with t here ...
    >
    >
    >
    > Where I must pass one as a parameter I use the common convention of
    >
    > naming the parameter "type_" at the receiving end.
    >
    >
    >
    > For the calling end, as in your case, you want to use:
    >
    >
    >
    > type(blah)
    >
    >
    >
    > Is it at all possible to make all uses of your "type" function method
    >
    > calls? Eg:
    >
    >
    >
    > something.type("text to type")
    >
    >
    >
    > It avoids the overloading while keeping your desired name.
    >
    > --
    >
    > Cameron Simpson
    >
    >
    >
    > Wouldn't it be great if all emergency stopping situations occurred on your
    >
    > favourite bit of road......you'd probably know about it before it happened
    >
    > and would be able to take other evasive action.
    >
    > - Neville Brabet
    Michael Herrmann, Nov 24, 2012
    #10
  11. On 24Nov2012 14:32, Michael Herrmann <> wrote:
    | how about "write" instead of "type"? Just came to me in a flash of inspiration. I know it's also pretty general but at least it's not a built-in!

    +1
    --
    Cameron Simpson <>

    Cars making a sudden U-turn are the most dangerous. They may cut you off
    entirely, blocking the whole roadway and leaving you no place to go.
    - MSF Motorcycle Operator Manual, sixth rev. 1991, page 21
    Cameron Simpson, Nov 24, 2012
    #11
  12. On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:

    > Hi,
    >
    > how about "write" instead of "type"? Just came to me in a flash of
    > inspiration. I know it's also pretty general but at least it's not a
    > built-in!


    "write" is an extremely common operation with a signature very similar to
    that of your function you want. The typical use of your function:

    automata.write("Hello world") # or whatever your module is called

    looks exactly like writing to the file referred to by the name "automata".

    Writing to files is *far* more common than using type. Using the standard
    library for a rough-and-ready test:

    [steve@ando python3.3]$ grep "[.( ]write(" *.py | wc -l
    475
    [steve@ando python3.3]$ grep "[.( ]type(" *.py | wc -l
    161


    If it isn't obvious what I am doing, I am using the Linux "grep" utility
    to search the Python 3.3 standard library for calls to functions or
    methods called "write" vs "type". There are nearly three times as many
    calls to "write".

    If I inspect the way that the functions are used, the difference is
    clear: write is nearly always used as a procedure, while type is used as
    a function. Here are a couple of typical examples:

    copy.py: return type(x)(x.__func__, deepcopy(x.__self__, memo))
    datetime.py: if type(other) != timezone:

    Your "simulate typing" function does not look like this. It doesn't
    return anything. It usually gets used as a procedure, not a function,
    just like the write method:

    base64.py: output.write(line)
    formatter.py: write(word)

    There is far more opportunity for confusion with the name "write" than
    "type":

    * writing to files is much more common than calling type, even in
    expert-level code;

    * beginners are even less likely to be using builtin type;

    * a call to your proposed function "type(string)" does not look
    like a typical call to the builtin type function;

    * but a call to your proposed function "write(string)" does look
    very similar, if not identical, to a typical call to write.


    This is why I maintain that fear of shadowing builtins often becomes
    superstition, not reasonable, reasoned advice. For fear of one (unlikely)
    source of confusion, you are prepared to accept a (more likely) source of
    greater confusion.

    Writing to files is a very common thing to do. Calling type() is not. Way
    back in the early days of Python, it was common to use code like:

    if type(obj) is type([]): ...

    but that is usually wrong (it rejects subclasses) and inelegant. Normally
    people will use:

    if isinstance(obj, list): ...

    or better still, avoid type-testing altogether. One thing that *doesn't*
    get done is call builtin type on a literal string, then ignore the result:

    type("Hello world!")

    What would be the point? That would be better written:

    str

    or even better still, not written at all, since it does nothing sensible.

    But calling file method "write" with a string, or a string literal, is
    extremely common, and sensible. Your proposed "write" will look just like
    writing to a file, when it does something completely different. A couple
    of days ago I said:

    Steven D'Aprano, Nov 25, 2012
    #12
  13. On 25Nov2012 04:06, Steven D'Aprano <> wrote:
    | On Sat, 24 Nov 2012 14:32:19 -0800, Michael Herrmann wrote:
    | > how about "write" instead of "type"? Just came to me in a flash of
    | > inspiration. I know it's also pretty general but at least it's not a
    | > built-in!
    |
    | "write" is an extremely common operation with a signature very similar to
    | that of your function you want. The typical use of your function:
    |
    | automata.write("Hello world") # or whatever your module is called
    |
    | looks exactly like writing to the file referred to by the name "automata".

    Which is actually an argument _for_ his suggestion.

    [...]
    | If I inspect the way that the functions are used, the difference is
    | clear: write is nearly always used as a procedure, while type is used as
    | a function. [...]
    | Your "simulate typing" function does not look like this. It doesn't
    | return anything. It usually gets used as a procedure, not a function,
    | just like the write method:

    Again, an argument _for_ his suggestion.

    |
    | There is far more opportunity for confusion with the name "write" than
    | "type":
    [...]
    | * but a call to your proposed function "write(string)" does look
    | very similar, if not identical, to a typical call to write.

    Again, an argument _for_ his suggestion.

    Why do I find these reasons to be plusses while you find them minuses?
    Because you're conveniently glossing over the fact that almost all
    uses of "write" in the library and common code have an object for
    context.

    And I find his suggestion good because for us old UNIX heads, the way you
    present typed text to a terminal is usually to write it to the master
    side of a pseudotty, thus:

    pty.write("typed text here!")

    The usage is _exactly_ analogous to the conventional uses of write(),
    because "everything is a file" (one of the UNIX mantras). Writing typed
    text is the natural way to express this stuff.

    Your argument seems to be that because his write looks and acts like
    other write()s it is cause for confusion. My argument is that using the
    name "write" is a good thing, _because_ his usage looks and acts like
    the other common uses of write.

    So I maintain it should cause less confusion.

    Cheers,
    --
    Cameron Simpson <>

    It is a tale told by an idiot, full of sound and fury, signifying nothing.
    - William Shakespeare
    Cameron Simpson, Nov 25, 2012
    #13
  14. On Friday, 23 November 2012 21:42:39 UTC+5:30, Michael Herrmann wrote:
    > Hi,
    >
    >
    >
    > do you think it's bad style to override the built-in function `type`? I'm co-developing a GUI automation library called Automa (http://www.getautoma.com) and 'type' would be a very fitting name for a function that generates artificial key strokes.
    >
    >
    >
    > This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
    >
    >
    >
    > For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the other thread.
    >
    >
    >
    > Thank you very much!
    >
    > Michael


    Deleting getattr causes problems with IDLE.
    Also, the accepted answer to http://stackoverflow.com/questions/...n-function-name-as-an-attribute-or-method-ide is not correct.
    See http://bugs.python.org/issue15113#msg163272 .
    Ramchandra Apte, Nov 25, 2012
    #14
  15. Hey everyone,

    this is my final mail. With all your help we have decided on names for our function. It was a surprisingly difficult process but your inputs helped tremendously. I have described our experiences (very good ones here, but somewhat mixed ones with StackOverflow) in a blog entry: http://www.getautoma.com/blog/New-version-of-Automa-with-improved-API

    I will now stop spamming this list. Thank you so much again! If you're interested in how we're getting on in the future, do follow us on Twitter @BugFreeSoftware or on our blog http://www.getautoma.com/blog!

    Thanks again,
    Michael
    Co-founder and lead developer
    @BugFreeSoftware
    http://www.getautoma.com

    On Friday, November 23, 2012 5:12:39 PM UTC+1, Michael Herrmann wrote:
    > Hi,
    >
    >
    >
    > do you think it's bad style to override the built-in function `type`? I'mco-developing a GUI automation library called Automa (http://www.getautoma..com) and 'type' would be a very fitting name for a function that generatesartificial key strokes.
    >
    >
    >
    > This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
    >
    >
    >
    > For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the otherthread.
    >
    >
    >
    > Thank you very much!
    >
    > Michael
    Michael Herrmann, Nov 29, 2012
    #15
  16. Michael Herrmann

    rusi Guest

    On Nov 23, 9:12 pm, Michael Herrmann <>
    wrote:
    > Hi,
    >
    > do you think it's bad style to override the built-in function `type`? I'mco-developing a GUI automation library called Automa (http://www.getautoma..com) and 'type' would be a very fitting name for a function that generatesartificial key strokes.
    >
    > This post is motivated by an already lengthy discussion on this mailing list (http://bit.ly/10aOy4H), where we tried to find alternative names for `type`. Many were found, but none are quite as fitting as 'type'.
    >
    > For the sake of avoiding a discussion that is already being lead elsewhere please confine this thread to what you generally think about overriding `type`, and post suggestions for alternative names or solutions in the otherthread.
    >
    > Thank you very much!
    > Michael


    Im entering this thread late (was off mail for a week), so pardon me
    if someone has already said this -- but have you looked at the
    difference between internal and external dsls:
    http://martinfowler.com/bliki/DomainSpecificLanguage.html (and links
    therein) ?

    Roughly speaking if what you are making is an external dsl, then its
    not really python (it may be python-inspired but thats not really
    germane) and so reusing python lexemes/structures etc in ways not
    exactly consistent with python usage should be no issue

    If its an internal DSL, you are headed for causing/suffering grief.

    I looked at your site [yes it looked almost interesting -- if only it
    ran on linux :-( ] and I cant really decide whether to classify it as
    external or internal
    rusi, Nov 30, 2012
    #16
  17. Hi Rusi,

    > Im entering this thread late (was off mail for a week), so pardon me
    > if someone has already said this -- but have you looked at the
    > difference between internal and external dsls:
    > http://martinfowler.com/bliki/DomainSpecificLanguage.html (and links
    > therein) ?
    > Roughly speaking if what you are making is an external dsl, then its
    > not really python (it may be python-inspired but thats not really
    > germane) and so reusing python lexemes/structures etc in ways not
    > exactly consistent with python usage should be no issue
    >
    > If its an internal DSL, you are headed for causing/suffering grief.
    >
    > I looked at your site [yes it looked almost interesting -- if only it
    > ran on linux :-( ] and I cant really decide whether to classify it as
    > external or internal


    We want to capitalize on all of Python's advantages (tool/IDE support, available libraries etc) and are thus strictly offering an internal DSL (see http://www.getautoma.com/features/python_integration). As you pointed out, that's why it's important to stay consistent with Python's conventions.

    I agree it'd be nice to have Automa run on Linux, but unfortunately that's still a long time away...

    Best,
    Michael
    Michael Herrmann, Dec 3, 2012
    #17
    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. Gilles Arnaud

    "bad argument type for built-in operation"

    Gilles Arnaud, Jan 24, 2005, in forum: Python
    Replies:
    1
    Views:
    404
    John Machin
    Jan 24, 2005
  2. Florian Lindner

    bad argument type for built-in operation

    Florian Lindner, May 10, 2005, in forum: Python
    Replies:
    0
    Views:
    376
    Florian Lindner
    May 10, 2005
  3. Replies:
    2
    Views:
    914
    Bengt Richter
    Aug 1, 2005
  4. Dave W.
    Replies:
    7
    Views:
    2,858
    J. Cliff Dyer
    Apr 16, 2010
  5. rantingrick
    Replies:
    44
    Views:
    1,199
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page