Re: Making class attributes non-case-sensitive?



Just so I don't hijack my own thread, the issue is 'how to wrap an
object which is not case sensitive'.

The reason I am stuck dealing with this?... The application's API is
accessed through COM, so I don't know if I can do anything but react
to what I get. The API was written while the app (Softimage|XSI - one
of 3 leading 3D applications for high-end visual effects) was owned by
Microsoft. I'm not sure if it is standard for Microsoft or just the
way this app was implemented (perhaps because under-users were
scripting in VBscript which is not case sensitive).

XSI allows many languages to be used via COM, even from within the
software (there are built-in code editors). In the early days,
VBScript was the most common scripting language used while anything
more hard-core was done in C++ (of course the C implementation is case
sensitive - well as far as I know). Then JScript became the most
common, now Python is considered standard.

Anyway, the standard practice is to use mixed-case, so I need to
adhere to it as the resulting framework I am creating needs to be
intuitive to use (my end-user is still writing code. It's an API for
an API I guess...)

I don't *think* I need to worry too much about performance because I'm
not doing any serious processing, this is more about convention
enforcement and quality control rather than number crunching. I might
try to write something generic which gets executed by the wrappers
__getattr__ and __setattr__, but I was hoping for some nifty
workaround, maybe in the form of a decorator or something? Again...
any ideas?


Cheers,

- Rafe


On Oct 13, 4:15 pm, "Diez B. Roggisch" <de...@xxxxxxxxxxxxx> wrote:
Rafe wrote:
Hi,

I'm working within an application (making a lot of wrappers), but the
application is not case sensitive. For example, Typing obj.name,
obj.Name, or even object.naMe is all fine (as far as the app is
concerned). The problem is, If someone makes a typo, they may get an
unexpected error due accidentally calling the original attribute
instead of the wrapped version. Does anyone have a simple solution for
this?

I can protect against some cases just by making an 'alias':
class AClass(object):
    def name(self):
        print "hello"

    Name = name

...but this doesn't protect against typos, it gets more complicated
with multi-word attribute names, and it makes my epydocs confusing to
read since all spelling versions are shown (I AM concerned about my
docs being clear, but not as much as stopping typo related errors).

I thought about using my wrapper's __getattr__ and __setattr__, but I
I am concerned about the overhead of every delegated attribute call
running a search and compare (<paramName>.lower() based compare?).

Any ideas or precedence?

Ideas? Don't do that...

Seriously: where does that code come from, who's typing it? If it is python,
then make people follow python's rules. If it is some sort of homebrewn
language you map to python, adapt the mapper to enforce lower-case and make
all your properties lower case.

Diez

.



Relevant Pages

  • Re: CRT and Win32 SDK
    ... However, it might give a reader an impression that when doing embedded programming one typically has a full-fledged language at hand, where in effect the runtime library implements what the OS would provide on e.g. a PC. ... The C and C++ standards differentiate between hosted and free-standing implementation to deal with the special constraints of embedded programming, where free-standing doesn't need to provide all of the language's standard library, but even that distinction does in practice not go far enough: it might be that fundamental language features such as static variables and exceptions are not available on the embedded platform's language implementation. ... Both the user-mode Win32 API and the kernel ... The documentation remarks are very important parts of that documentation and form the main part of it. ...
    (microsoft.public.vc.language)
  • Re: Accessors in Python (getters and setters)
    ... used it in 27000 lines of Python code (which certainly took some time to ... develops might misinterpret exactly what "tmp" does. ... Failing to understand a language semantics ... But it's *your* responsability to choose good names for the API.> ...
    (comp.lang.python)
  • Re: Modernizing Common Lisp
    ... > worry about the idiosyncrasies of their vendor's network API or threads ... While a "standard" API is all peachy and wonderful, ... ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL ...
    (comp.lang.lisp)
  • Re: Accessors in Python (getters and setters)
    ... "tmp" sucks. ... gives no right to complain about the language. ... But it's *your* responsability to choose good names for the API.> ... And anyway, 27000 lines of Python ...
    (comp.lang.python)
  • Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
    ... It's the second meaning. ... >> the language, they type something into their interpreter. ... meaning of "standard", ... >> thing that could happen to Python is an ANSI standard. ...
    (comp.lang.lisp)