Home/ Questions/Q 537311
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T09:54:49+00:00

A friend was burned when starting to learn Python, and now sees the language

  • 0

A friend was “burned” when starting to learn Python, and now sees the language as perhaps fatally flawed.

He was using a library and changed the value of an object’s attribute (the class being in the library), but he used the wrong abbreviation for the attribute name. It took him “forever” to figure out what was wrong. His objection to Python is thus that it allows one to accidentally add attributes to an object.

Unit tests don’t provide a solution to this. One doesn’t write unit tests against an API being used. One may have a mock for the class, but the mock could have the same typo or incorrect assumption about the attribute name.

It’s possible to use __setattr__() to guard against this, but (as far as I know), no one does.

The only thing I’ve been able to tell my friend is that after several years of writing Python code full-time, I don’t recall ever being burned by this. What else can I tell him?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “changed the value of an object’s attribute” Can lead to problems. This is pretty well known. You know it, now, also. That doesn’t indict the language. It simply says that you’ve learned an important lesson in dynamic language programming.

    1. Unit testing absolutely discovers this. You are not forced to mock all library classes. Some folks say it’s only a unit test when it’s tested in complete isolation. This is silly. You have to trust the library modules — it’s a feature of your architecture. Rather than mock them, just use them. (It is important to write mocks for your own newly-developed libraries. It’s also important to mock libraries that make expensive API calls.)

      In most cases, you can (and should) test your classes with the real library modules. This will find the misspelled attribute name.

    2. Also, now that you know that attributes are dynamic, it’s really easy to verify that the attribute exists. How?

      Use interactive Python to explore the classes before writing too much code.

      Remember, Python is not Java and it’s not C. You can execute Python interactively and determine immediately if you’ve spelled something wrong. Writing a lot of code without doing any interactive confirmation is — simply — the wrong way to use Python.

      A little interactive exploration will find misspelled attribute names.

    3. Finally — for your own classes — you can wrap updatable attributes as properties. This makes it easier to debug any misspelled attribute names. Again, you know to check for this. You can use interactive development to confirm the attribute names.

    Fussing around with __setattr__ creates problems. In some cases, we actually need to add attributes to an object. Why? It’s simpler than creating a whole subclass for one special case where we have to maintain more state information.

    Other things you can say:

    I was burned by a C program that absolutely could not be made to work because of ______. [Insert any known C-language problem you want here. No array bounds checking, for example] Does that make C fatally flawed?

    I was burned by a DBA who changed a column name and all the SQL broke. It’s painful to unit test all of it. Does that make the relational database fatally flawed?

    I was burned by a sys admin who changed a directory’s permissions and my application broke. It was nearly impossible to find. Does that make the OS fatally flawed?

    I was burned by a COBOL program where someone changed the copybook, forgot to recompile the program, and we couldn’t debug it because the source looked perfect. COBOL, however, actually is fatally flawed, so this isn’t a good example.

    • 0