- Ryan Bottriell
- David Aguilar
- Ashley Whetter
- Ollie Harding
- Mark Wiebe
- Rick Rickenberg
- JT Nelson
- Robert Vinluan
- Pull together some notes on what SideFX ran into when converting code that uses the raw python C API for the best practices docs Robert Vinluan
- Start opening smaller, curated pull requests against the best practices guide (eventually close the current WIP one) David Aguilar
- add a note to the best practices about the minimum version of modernize that needs to be used to fix the
long -> int
conversion inmaya.cmds
function calls (once a section about modernize has been added to the guide) Ashley Whetter
- Notetaker: Ryan Bottriell
- Review pending action points
- Add What’s new & what’s going away in 3.9 to repo notes JT Nelson
- Curate the guidelines docs David Aguilar
- Any blockers
- Additional items
- review action item: Add What’s new & what’s going away in 3.9 to repo notes
- JT Nelson will be meeting with another python group next saturday to discuss
- review action item: curate the guidlines docs
- David Aguilar gave an overview / update on the PR and open quesitons:
- mostly taken from python3 porting guide and futurize cheat sheet and is generally inline with python3 porting guide
- not recommending the standard library monkeypatching that futurize does
- because most of our code is library code which needs to mingle in production, not stanalone so we're leaning towards being conservative
- also not recommending using builtins imports from futurize
- like above, this adds additional types that can cause more confusion
- eg comparing
type(var) == some_buitin_type
, where var might come from the futuruze builtin and not match - again, we all have library code that must mingle in production in unknown ways, so it's better if the type set remains consistent
- recommending only first stage of futurize plus some extra flags for getting all the __future__imports
- not recommending the modernize tool due to lack of ongoing support, though it may still be useful
- possibly separating some of the general python stuff into a best practices
- Ryan Bottriell unsure about including the unicode_strings import as part of the futurize
- a specific callout for this one in the doc seems like a good idea
- Ashley Whetter do we go with a guide or a presentation of all options
- a step-by-step seems to be the most useful to the community
- Robert Vinluan, Ashley Whetter modernize actually has a fork that is maintained and is being used by some studios, probably worth keeping in there as a recommendation
- Ryan Bottriell likes that we are recommending pylint to check for issues in the code, this has been a good process for helping devs discover their problem areas at Imageworks
- Ashley Whetter modernize has a check flag as well but pylint is easier to use and configure/check
- David Aguilar will start opening new pull requests against the best practices guide, will eventually close the current WIP one
- David Aguilar gave an overview / update on the PR and open quesitons:
- Ashley Whetter has some code that cannot take in unicode strings (mostly boost-python)
- Most are being moved to pybind instead, which also helps reduce code overall
- David Aguilar pybind does the unicode conversion automatically, but boost python needs you to register a translator yourself
- will include this in the best practices guide
- Robert Vinluan should we be making more recommendations on the c/c++ side?
- Ashley Whetter bringing up these differences and supplying common examples that everyone will hit would likely be nicely
- Robert Vinluan swig and c python API. C API doesn't have much online in terms of cheat-sheet, this could be something useful to pull together
- Robert Vinluan will pull together a list of things that SideFX ran into at least
- there are guides that recommend cffi instead of using the python api directly, but that is not always helpful on a legacy code base
- Rick Rickenberg From experience with numpy, it's worth noting that using the c api directly is way faster
- Ashley Whetter we saw speedup in exception handling with pybind over boost because of the way exceptions are handled (a list of all possible exceptions being iterated through) but it seems like as more code moves to pybind this will get worse again