Python 2.4: Why only assignments to None are forbiden?

[Josef Meile]

Hi,

Textually from the highlights of python 2.4:

"Assigning to None - the compiler now treats assigning to None as a
SyntaxError."

I think in general assignments to built-in types, functions, and
variables should be also forbiden. It's a common mistake to do things
like this:

def getFileName(fil e):

.... parts=file.spli t('/')
.... return parts('/')[-1]

Specially if you come from python 2.1.x where "file" didn't exist.
Instead, there was "open"

On the example's context, file is a string and won't cause any damage
because it is inside a function, so, the scope is local and it will be
deleted after the function call. But think what would happen if somebody
defines "file" as a global variable and other people use that code? For
the author won't be any consequences at all, because if s/he does this,
it means that probably s/he isn't working with files, but if somebody
else takes that code and doesn't see this, then s/he will invest some
time trying to find the bug.

Doing this validation for python 2.4.x will break some things, like the
validation with "None" does. But I think it's better when you now that
you are trying to use a "reserved word", you could as well use the "str"
as an example, which I think is also common on newies.

Regards,
Josef

[Andrew Dalke]

Peter Hansen wrote:

One perfectly good reason to assign to builtins (and there are others,
I'm sure) is to provide a "mock" function to replace a standard
one, for use during automated testing.

That's understandable, but it doesn't work for None. At the C
level there is a Py_None object which is the same singleton object
used by None. If you replace the builtin None with a mock None
then almost certainly there will be strange effects.

Eg,

def spam():
print "Here there be Vikings"

x = spam()

At this point, x contains the real None and not the mock one.

class MyList(list):
def get(self, item):
if item.startswith ("__"):
raise AccessDenied(it em)
return list.get(item)

x = MyList().get("w ensleydale")
Again, x is the real None object and not the mock one.

So if reasonable code did the following

if x is None:
print "Sorry, not even wensleydale"
else:
print "Yes, we have it"

then it would break under the mock None case.

In theory it could be possible to make this work. Setting
None in builtins could change some sort of proxy object at
the C level, and ... though the object ids wouldn't be right.
Hmmm. It would be a lot of work for very, very little gain.

So while we do have

Special cases aren't special enough to break the rules.

it's more than trumped by

Although practicality beats purity.

It's almost impossible to make a proxy None object work
correctly.

In a related topic, would you like to have a proxy for the
numbers 0, 1, 2, etc.? Is None special because it's a
variable name that cannot be reassigned or is it not special
because it's just like other builtin objects that cannot
be replaced by user-defined objects?

Andrew
da***@dalkescie ntific.com

[Terry Reedy]

"Andrew Dalke" <ad****@mindspr ing.com> wrote in message
news:ei******** ***********@new sread1.news.pas .earthlink.net. ..

Peter Hansen wrote:

One perfectly good reason to assign to builtins (and there are others,
I'm sure) is to provide a "mock" function to replace a standard
one, for use during automated testing.

That's understandable, but it doesn't work for None.

Peter was not suggesting that replacement of None be allowed but that
replacement of things like file() should continued to be allowed and not
prohibited as someone (I believe other than the OP) suggested.

Terry J. Reedy

[Andrew Dalke]

Terry Reedy wrote:

Peter was not suggesting that replacement of None be allowed but that
replacement of things like file() should continued to be allowed and not
prohibited as someone (I believe other than the OP) suggested.

Ahh, thank you. I didn't catch the shift in topic.

Andrew
da***@dalkescie ntific.com

[Ian Bicking]

Bengt Richter wrote:

Since this is a compile-time issue , perhaps it is time to consider
a pragma statement as a framework for telling python pre-runtime things
like optimization info? E.g., pragma could send in-context meta-info
to various python infrastructure components using python method call syntax
which the compiler could recognize in the token stream and compile and
execute in its working environment right then. So e.g.,

pragma compiler.overri de(len=True, cmp=False)

There's a recipe for doing something very similar to this with the
current Python:

http://aspn.activestate.com/ASPN/Coo.../Recipe/277940

--
Ian Bicking / ia**@colorstudy .com / http://blog.ianbicking.org

[Bengt Richter]

On Mon, 15 Nov 2004 00:35:12 -0600, Ian Bicking <ia**@colorstud y.com> wrote:

Bengt Richter wrote:

Since this is a compile-time issue , perhaps it is time to consider
a pragma statement as a framework for telling python pre-runtime things
like optimization info? E.g., pragma could send in-context meta-info
to various python infrastructure components using python method call syntax
which the compiler could recognize in the token stream and compile and
execute in its working environment right then. So e.g.,

pragma compiler.overri de(len=True, cmp=False)

There's a recipe for doing something very similar to this with the
current Python:

http://aspn.activestate.com/ASPN/Coo.../Recipe/277940

Yes, that's a nice clever decorator thing for certain kinds of optimization
(by Raymond Hettinger), but if file='something ' were disallowed, and you
wanted to do it in a function, I don't think a decorator would get
control early enough to do anything about it, even if there were a hook
for unlocking the bindability of file. But yes, in general, I can see why you
were reminded ;-)

Regards,
Bengt Richter

[Eric Pederson]

I'm seeing Python mentioned a bit more in "help wanted" job descriptions, reflecting, I suppose, a modicum of inroads Python is making into various development or IT environments.

As I contemplated a posted job for a friend who meets the requirements, save the mention of desired Python competence, it occurred to me that it wouldnot be hard for him (a competent SW engineer) to become competent in Python; in fact, that's a real Python strong point.

If we see Python increasingly in help wanted ads, one might expect competent job seekers to take the week or two it would take to get waist deep in Python (or do I over-estimate: is it more like two days for a competent SW engineer to learn and get practiced in Python?)

Python is so easy to learn, it's a natural choice for someone wanting to gain a broader skillset; when breadth of language knowledge becomes important, Python is an easy target.

If the pick-up of Python as an "extra" language becomes a trend, then I believe the tipping point will be reached, and a positive feedback loop will see the language adopted and employed much more widely, and blossom even further in the hands of a larger army of volunteers.
Of course, this would be the end of the IT world, for Python ruins one for programming in much of anything else.
.... yes, I only smoke the good stuff.

What is a Perl?
Eric Pederson
::::::::::::::: ::::::::::::::: :::::
domainNot="@som ething.com"
domainIs=domain Not.replace("s" ,"z")
ePrefix="".join ([chr(ord(x)+1) for x in "do"])
mailMeAt=ePrefi x+domainIs
::::::::::::::: ::::::::::::::: :::::