Case Sensitive!

[RDHarles]

What is going on with Arc 10 and the case sensitive stuff???

This works:
arcpy.Clip_management()

This doesn't!!!:
arcpy.clip_management()

Are you telling me I'm going to have to update literally hundreds of thousands of lines of code in hundreds of scripts in order to move from arc 9.x to  Arc 10?

Please tell me this isn't so?
Anyone figured out a way around this?

[DanPatterson_Retired]

Yes Python is case-sensitive...many consider it one of its strengths since it ensures that there is no confusion in the namespace, hence, point is not Point is not POINT.  It assists in writing clear code once you get used to it.
You will have to do search and replace to update, this also happened during the translation from Avenue to Python code.

[RDHarles]

Yes Python is case-sensitive...many consider it one of its strengths since it ensures that there is no confusion in the namespace, hence, point is not Point is not POINT.  It assists in writing clear code once you get used to it.
You will have to do search and replace to update, this also happened during the translation from Avenue to Python code.

My point is that it never mattered before Arc 10 (in writing code against ESRI tools) so why change it now?  If it would have mattered back in 2005 when I started writing this stuff, maybe I would have got into the habit then.  Now it's a disaster!

[ArcGISUser]

What is going on with Arc 10 and the case sensitive stuff???

This works:
arcpy.Clip_management()

This doesn't!!!:
arcpy.clip_management()

Are you telling me I'm going to have to update literally hundreds of thousands of lines of code in hundreds of scripts in order to move from arc 9.x to  Arc 10?

Please tell me this isn't so?
Anyone figured out a way around this?

Yep it is so. When I took a python class last year, they let everyone know that this would change in 10, so I just started the habit of typing it out correctly since then.*shrugs*

[ChrisSnyder]

Yes, Python has always been case sensitive.

BUT

The GP stuff has NEVER been case sensitive (at least prior to v10). Which is why so many of us build up GP code that won't work in v10 without tons of rewrites...

shapeFieldName = gp.DeScRiBe(myFC).SHAPEfieldNAME #works great in v93

I am starting to really understand why all the ArcObjects people get so mad with every new major ArcGIS release...

R.D. - I feel your pain.

Not sure why ESRI makes all these "sweeping" changes (as in sweeps my existing code into the garbage can)!

Here's a wish for an enlightened future of syntax stability...

[DavidWynne]

Not sure why ESRI makes all these "sweeping" changes (as in sweeps my existing code into the garbage can)!

Hi Chris,
The case-sensitivity of arcpy is something of a trade-off.  By providing early binding with arcpy (giving you drop-downs, code completion, etc), it locks us into case-sensitivity. 

The important thing to note is that this change does not affect any Python scripts written using a geoprocessor object.  Any scripts written on past releases of ArcGIS, don't need to be updated--they should just work.

-Dave

[ChrisSnyder]

By providing early binding with arcpy (giving you drop-downs, code completion, etc), it locks us into case-sensitivity

I get it, thanks for the explanation. I made a little .py module of my own a while back, and so I see your point. A small price to pay for code completion perhaps...

I'm probably not as bad off as most (that want to completely update their gp code to use arcpy only) since I always copied the tool syntax out of the Help syntax example. Most of my problem code is in the methods and properties.

.shapefieldname #v93 (camel case? no way! - I don't even GaF! I'll do it my way - Wo hoo!)
.ShapeFieldName #v10 (uh oh, now case sensitive - I must obey ESRI synax - case by case!)

Toolwise though, I have a lot of coworkers that have code like:

gp.union(this + ";" + that, theOther)

They are not so fortunate! Rewrite city for them!

BTW: I know you've heard it a million times, but it sure would be cool to have an arcpy OMD that showed the 'correct' method/property case spellings in v10 (like the v9.0 - 9.3 ones). I use my GP OMD all the time as a cheat sheet (too bad I didn't always follow the case-spellings!). No one would care if there were > 1 pages (just as long as we can print/read them on 11 x 17). I guess code completion is sort of like a cheat sheet, but it is SO NICEto have everything you need on an 'old-fashioned' printed page sometimes.

[RDHarles]

The case-sensitivity of arcpy is something of a trade-off.  By providing  early binding with arcpy (giving you drop-downs, code completion, etc),  it locks us into case-sensitivity. 
-Dave

At least I understand why.

The important thing to note is that this change does not affect any  Python scripts written using a geoprocessor object.  Any scripts written  on past releases of ArcGIS, don't need to be updated--they should just work. -Dave

This didn't even occur to me for some reason.  I was thinking Arc 10 = must use arcpy.  At least that fact buys me some time for the transition.

R.D. - I feel your pain.

Thanks Chris,  I need all the comforting I can get.
The only way I can think to do this is to search for "gp.", look up the correct syntax, then type over or add to the current text.
Maybe when I get some free time:), I'll create a python script containing a giant dictionary will all the tools, methods & properties containing the correct syntax.  Then use that dictionary in a search/replace script to fix all my other scripts!  I'll let you know when I get that written;)

[LoganPugh]

You can get around this by using the text format functions of Python such as

>>>x = "A strAnGle case string"
>>>print x.lower() # This forces it to use lowercase for the variable.

>>>#hope that helps.

The issue is not the case of values, but of the names of methods and properties in ArcPy itself. The only solution to that is to rewrite your code (search and replace in your text editor can help with that though).

[ChrisSnyder]

Ryan - You are on the right track for sure.

You can get the "correct" case tool names I think from gp.listtools() - or arcpy.listtools() and use that to build a crosswalk.
Switching the tool names wouldn't be too horrible, something like...
1. Build a tool name dictionary - toolNameDict[toolName.split("_")[0].lower()] = toolName
     - {"clip":"Clip_Analysis"}
2. Look for lines with "gp."
3. Isolate the part after the "gp." but before the "_' and/or "("
4. Convert to lower()
5. Now scan through the dictionary and hopefully find a match

The methods and properties would be harder, although most of them tend to be pretty specific keywords like ".getvalue" or ".oidfieldname". Some are not so obscure, like ".name" or ".type".

It'd be pretty hard to get something 100% accurate, but even 50% would be better than 0% (as long as it didn't completely bugger your code).

Anyway, it would be a pretty good challenge... stuff like this puts the P in GISP for sure.