os.getcwd()

[TedCronin]

So, I am being seeing more and more of the samples using os.getcwd(), is this a better approach than setting a wrksp variable with env.workspace?  I mean the code looks pretty smooth, then throw on os.path.join to combine your gdb paths with your fd/fc, does look cleaner, rather than having a lot of wrksp and swrksp 1,2,3,4 and so forth.

[curtvprice]

So, I am being seeing more and more of the samples using os.getcwd(), is this a better approach than setting a wrksp variable with env.workspace?

Ted, I wouldn't recommend this -- in the context of ArcGIS script tools, the workspace is used in tool parameter validation (to generate default output workspace paths in output parameters) and by the geoprocessor methods, and the scratchWorkspace allows user, model, and script control of where scratch files are written.  I think that by far it is best practice to use these arcpy environments and keep consistent with what ArcGIS standard tools do.

I mean the code looks pretty smooth, then throw on os.path.join to combine your gdb paths with your fd/fc, does look cleaner, rather than having a lot of wrksp and swrksp 1,2,3,4 and so forth.

Functions like arcpy.ListFeatureClasses() use the current workspace, and tools write to the current workspace without you having to specify paths. You still can use os.path.join(), os.path.dirname(), os.path.normpath() etc. as you need to.

I afraid I don't know what you mean by "a lot of wrksp and swrksp 1,2,3,4 and so forth."

[TedCronin]

This wasn't a question necessarily for end users, but more for the creators of the samples in the help perhaps it can be taken offline or a followup at the UC.  Also, the help i am referring to is 10.1. Someone Checked as Answered; I unchecked because the answer was not answered.  I know about os, and I know about arcpy and tools.   1,2,3,4, etc, is really in the context of explicit over implicit for setting multiple wrksp in a script and having a natural flow for the code. 

I guess this is an argument on why end users shouldn't give themselves a check box, or why esri shouldn't give end users the rights to give the power users on here the power to give points to themselves when it would be their opinion especially if its from their answers.  Now perhaps their ability to check an answer as answered makes sense when it wasn't them answering the question, perhaps that could be a rule ESRI.  If you give these Forums MVP the rights to check something as answered, it should be ONLY if they did not provide the answer.  To answer a question and then give points to oneself (NOT IMPLYING ANYTHING HERE) to receive points is very subjective, even if the answer provided did not really answer the intent of the question.

So, it seems the power has been handed over to some lucky few power users (So Watch Out), I will have to be more diligent now when posting.

Well Perhaps Not for all the forums users....

[curtvprice]

This wasn't a question necessarily for end users, but more for the creators of the [10.1] samples in the help perhaps it can be taken offline or a followup at the UC.

Thanks for the clarification, Ted. I think it's annoying that we have yet another path in the ArcGIS environment to consider (I could about six right now.)

If any of the sample authors can chime in, this would be good to see here. Some of us can't make it to San Diego, unfortunately, and this is a good venue to discuss it I think.

[If we] give the power users on here the power to give points to themselves when it would be their opinion especially if its from their answers.

I'm innocent, Ted! I did not check my own answer, and if I had the power would not do it that lightly. (Note, I don't even see the check icon on my screen, either.)

I agree if this power is given to MVPs we should get some guidance. One would be not to check your own answer unless the user has responded that it solved their problem.

[TedCronin]

Thanks for the clarification, Ted. I think it's annoying that we have yet another path in the ArcGIS environment to consider (I could about six right now.)

If any of the sample authors can chime in, this would be good to see here. Some of us can't make it to San Diego, unfortunately, and this is a good venue to discuss it I think.

Yes, I follow your logic where I explicit set env.workspace alot, perhaps I could streamline my code more with using better practices (which is why I love this python category on the forums), and os methods may help in that light, but for now just reading code from the samples is very intriguing to me.

I'm innocent, Ted! I did not check my own answer, and if I had the power would not do it that lightly. (Note, I don't even see the check icon on my screen, either.)

I agree if this power is given to MVPs we should get some guidance. One would be not to check your own answer unless the user has responded that it solved their problem.

I tested myself as well and don't see any check boxes, that's good to hear Curtis.  I tweaked my response hopefully to not imply anything.  I hope its clear.

[JasonScheirer · Accepted solution]

Long story short: it matters a whole lot less than you think it does.

os.chdir() and os.getcwd() manage the working directory of the process and therefore of builtin functions like open(), env.workspace does not. That is the only difference. It's not a matter of better style, it's a matter of what behavior you need to do what you need to do. getcwd works in standalone scripts that aren't necessarily script tools or ArcGIS related, env.workspace is ArcGIS Geoprocessing specific.

[TedCronin]

Long story short: it matters a whole lot less than you think it does.

Thank you Jason.