Thanks for that Justin, much appreciated, here below is my reasoning and
attempts at answers:
* Why do you have local __version__ variables in your methods?
I use them as an internal version tagging system while in early dev so to
say, for easy reading and such I use a local __version__ variable to clearly
indicate at what stage each function is, keeping format, efficiency, and
functionality in mind. In this case I have 4 functions:
1. clean_seperator { version 1.0.0 = done and happy with it, but it’s
a first version and can surely expand }
2. get_version { version 1.0.0 = done and happy with it but it’s a
first version and can surely expand }
3. notes { no version number as I have no intent of keeping it in
there, it’s a temporary thing I want to do entirely differently }
4. save { 0.3.0 = I’ve added new minor features to it 3 times now,
but am still far from thinking it’s doing the full job }
The local __version__ tag then gets stripped off as the actual file gets
committed to a versioning system, such as github, but I don’t feel this
script is anywhere close to being something that can be released as a plugin
or will have any substantial benefit for anyone beyond just me saving out my
files on my laptop but if it gets to that I’ll naturally remove the local
tag and just leave the versioning to git.
* Line 33 is not correct.
How funny, that is very correct, thanks for pointing it out. I was
passing in the just the name without the extension so I hadn’t tested it too
extensively. Ultimately I think this sort of a check belong in a decorator
rather than a function though but still trying to nail down a good and solid
check that works, in the past I’ve simply called shell scripts to get
pattern matching in my shell but this whole regular expressionism in python
appears to behave in a similar fashion just without all the added
complications of wrapping shell commands into python with slash escape
trickeries. Good stuff, and thanks.
Have updated the clean_seperator function and made it a decorator, using
your example and tested it using the filename “a silly ! looking __
@windows - file.ext“ it looks to do it’s thing, attaching it to the
get_version function cleans this up as the script goes along.
--[ The decorator:
def clean( value ):
"""Renames the return value of a function this is decorated with."""
def renamed():
name, ext = os.path.splitext( value() )
name = re.sub( r'[^a-zA-Z0-9]+' , ' ' , name ).strip()
return ''.join( [ name , ext ] )
return renamed
@clean
def something(name='a silly ! looking __ @windows - file.ext'):
return name
print something()
#returns: a silly looking windows file.ext
That only leaves the fact that I don’t just use this decorator in this
script alone, if I wish to emulate this exact same behaviour but using
another 3D application, the save function will be completely different in
that script as my current one makes use of Maya’s internal commands, this
test class eventually goes into a Maya dependant utility class while the
decorator is more of a generic shell utility. Adding clean as an extension
of the shutil module for example would be a little bit funny for various
reasons.
* Pythonic idiom
Side effects are fun as well but naturally not the way to go in this case,
have updated my function to include set(things) instead of [things] , thanks
for the tip.
* Windows-specific ctypes call for creating a hard link
No reason I used ctypes instead of os.link really beyond I was writing
this on my Windows laptop and os.link is not available on Windows, something
like:
try:
ctypes.windll.kernel32.CreateHardLinkA( str(destination) , str(current)
, 0 )
except OsError as e:
os.link( current , destination )
Should make it multi-platform, would be awesome if anyone on OSX can
verify such is the case. The fundamental difference and reasoning for using
a hard link rather than a symbolic link would be the fact they share an
inode so if the link source is removed for some reason the hard link target
becomes the only instance of that inode and the link doesn’t break like a
symbolic link does, marginal disk usage reduction says a thing or two as
well but hardly a crucial factor.
http://docs.python.org/2/library/os.html
* Popups
I still have my promptDialog popup appearing every time I click my save
button but most of the time I don’t have a comment I wish to add so I’m
doing a lot of “click to save – click again to verify no comment” instead of
just “click to save” so it feels like I’m going through double the clicking
effort, if my button just saves normally but picks up a comment if I’ve
placed a + at the start of my command executer at the bottom left hand of
the screen I have this as a seamless process and can move onto reading my
notes back in before I load the files.
But I’m at an absolute loss as to what Maya calls that executer window,
English is my third language but I usually get by ok, but what I then refer
to as a command executer is actually the terminology for the commandExecuter
files that save whatever you are typing into your script editor into your
home directory as text files, what’s this thing in the bottom left corner
called then? Google or the Autodesk documentations can’t help since I have
to keyword to search for. It’s a pickle, I know :)
* Messages
I have no idea either what Autodesk are calling those new style message
windows but I have it confirmed that they are “open” and we should be able
to play with them all we want for our own purposes. Some people have an
elaborate interest in other Maya features while that one I personally find
extremely exciting, not only for tutorial building and such but it’s a
cleaner way to report messages from tools and scripts in the same manner as
I’ve done in the past relying on things like kdialog or the windows
notification centre to get passive multi line messages to appear,
headsUpmessage is great, but in all honesty they feel a bit 1990’s and in
this case they “stop working” right away at this stage even though I want to
display only 2 lines, a filename and a version, single line support means I
need to choose between them.
///
No update to the script itself as I’m testing the decorator and trying to
find a better way than that popup, I can add a custom line input field below
my shelf bar to achieve the same, but I usually try to stick to what is
already in there.
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.