Python String-Inferred Names (working title)
UPDATE:
As it turns out, an idea that is similar (though not quite the same) to this one has already been proposed to the appropriate people--and rejected.
See PEP 363 for details.
Also, the recent PEP 3003 says that no more changes can be made to the Python syntax until more than a year from now in order to allow the various Python implementations to catch up to the current spec.
It looks like this idea won't see the light of day for quite some time, if ever.
I have an idea for a new feature to the Python programming language, but I have no idea how to go about getting it implemented, so I'm just going to describe it here.
This isn't a major feature--it's not even a very original one--and it will not make anything particularly new or exciting possible which is not already possible. However, I believe that a feature such as this would make certain tasks much easier to perform, and would make the code for such tasks easier to read and understand by others. This feature would in no way interfere with existing code as it relies on the use of an operator which the python interpreter currently does not recognize, the dollar sign ($), except in the rare and unusual circumstance that someone's code relies on a SyntaxError occurring. It would, however, make code using this new feature incompatible with older Python code.
So, what is the feature? Essentially, it is a way to combine the built-in functions
What this illustrates is that the syntax
Likewise,
...is equivalent to...
...and...
...is the same as...
As you can see, this syntax merely makes an existing feature of Python more concise rather than makes anything possible that is not already possible...unless you extend it to allow access to names in the current scope rather than names of a particular object, as illustrated below:
Effectively what this does is that it takes the value "somevar" of the variable in
Although an assignment like the one above is currently impossible, it actually is possible to emulate a reference/return using the built-in
So, why should anyone bother to implement this new syntax? Why add yet another syntactical element to the already feature-rich Python language? My primary reason has to do with metaprogramming.
One of the big uses for metaclasses is the ability to dynamically generate new properties and methods for classes. Through metaclassing, it is possible for all sorts of interesting, useful and time-saving feature sets to be added to classes with relative ease. Creating such metaclasses themselves, however, can be quite messy as it tends to rely on many calls to the
Using $ syntax, the
I know one of the big arguments against a feature like this is that we don't really need it. Well guess what? It's true. We don't need it. But we don't really "need" a lot of the neat little features that exist in Python, like decorators, iterators, generators, list comprehensions, ... but the fact of the matter is that we like them, and they are very useful, and they serve to make the language much easier to use and, many times, easier to understand. A feature like the one I am proposing, although perhaps not AS useful as some of the existing features that I just mentioned, would certainly make the meaning of code clearer and would therefore be useful enough to be implemented.
Another complaint I might here is that a feature such as this may lead to bad code. And to a small extent, I guess I agree; it could be used for bad code. But although it could, it doesn't have to. Just like nearly any feature of nearly any language, it could be abused, yet these features exist and are well used all the time. In other words, I don't really see how the possibility to misuse a feature could be interpreted as a reason not to implement it. Like any feature, simply use common sense and learn from your mistakes, and you will be able to determine when to use the feature and when not to.
That's all I have to say about it for now. I may revise later.
As it turns out, an idea that is similar (though not quite the same) to this one has already been proposed to the appropriate people--and rejected.
See PEP 363 for details.
Also, the recent PEP 3003 says that no more changes can be made to the Python syntax until more than a year from now in order to allow the various Python implementations to catch up to the current spec.
It looks like this idea won't see the light of day for quite some time, if ever.
I have an idea for a new feature to the Python programming language, but I have no idea how to go about getting it implemented, so I'm just going to describe it here.
This isn't a major feature--it's not even a very original one--and it will not make anything particularly new or exciting possible which is not already possible. However, I believe that a feature such as this would make certain tasks much easier to perform, and would make the code for such tasks easier to read and understand by others. This feature would in no way interfere with existing code as it relies on the use of an operator which the python interpreter currently does not recognize, the dollar sign ($), except in the rare and unusual circumstance that someone's code relies on a SyntaxError occurring. It would, however, make code using this new feature incompatible with older Python code.
So, what is the feature? Essentially, it is a way to combine the built-in functions
getattr, setattr, and delattr into a single concise symbol. It is best illustrated with the following Python psuedocode:
>>> class Foo(object):
... def __init__(self):
... self.myattr = "hello"
>>>
>>> f = Foo()
>>> attrname = "myattr"
>>>
>>> # Here it is in use:
>>> f.$attrname = "goodbye"
>>>
>>> # Here is the result:
>>> f.myattr
"goodbye"
What this illustrates is that the syntax
obj.$attr = value is effectively an alternate way of writing setattr(obj, attr, value).Likewise,
myvar = obj.$attr...is equivalent to...
myvar = getattr(obj, attr_expr)...and...
del obj.$attr...is the same as...
delattr(obj, attr)As you can see, this syntax merely makes an existing feature of Python more concise rather than makes anything possible that is not already possible...unless you extend it to allow access to names in the current scope rather than names of a particular object, as illustrated below:
>>> name = "somevar"
>>> $name = 123456
>>> somevar
123456
Effectively what this does is that it takes the value "somevar" of the variable in
name and uses it as an actual name in the current scope, then assigns the value 123456 to that name.Although an assignment like the one above is currently impossible, it actually is possible to emulate a reference/return using the built-in
eval function. For example, the expression $name is basically the same as eval(name, globals(), locals()).So, why should anyone bother to implement this new syntax? Why add yet another syntactical element to the already feature-rich Python language? My primary reason has to do with metaprogramming.
One of the big uses for metaclasses is the ability to dynamically generate new properties and methods for classes. Through metaclassing, it is possible for all sorts of interesting, useful and time-saving feature sets to be added to classes with relative ease. Creating such metaclasses themselves, however, can be quite messy as it tends to rely on many calls to the
getattr and setattr functions. Using these functions a lot in the same chunk of code tends to make it hard to read: Firstly, it draws out the normally trivial tasks of variable assignment and referencing into function calls, and secondly, it makes the object-oriented nature of the code less obvious. (I don't think this is a good thing. Do you?)Using $ syntax, the
getattr, setattr, and delattr needn't be used at all. We can reference attributes and assign to them with a syntax that more closely resembles what is actually going on conceptually.I know one of the big arguments against a feature like this is that we don't really need it. Well guess what? It's true. We don't need it. But we don't really "need" a lot of the neat little features that exist in Python, like decorators, iterators, generators, list comprehensions, ... but the fact of the matter is that we like them, and they are very useful, and they serve to make the language much easier to use and, many times, easier to understand. A feature like the one I am proposing, although perhaps not AS useful as some of the existing features that I just mentioned, would certainly make the meaning of code clearer and would therefore be useful enough to be implemented.
Another complaint I might here is that a feature such as this may lead to bad code. And to a small extent, I guess I agree; it could be used for bad code. But although it could, it doesn't have to. Just like nearly any feature of nearly any language, it could be abused, yet these features exist and are well used all the time. In other words, I don't really see how the possibility to misuse a feature could be interpreted as a reason not to implement it. Like any feature, simply use common sense and learn from your mistakes, and you will be able to determine when to use the feature and when not to.
That's all I have to say about it for now. I may revise later.
posted by The Music Guy @ 5:02 PM
4 Comments
Links to this post
