Closed BigRoy closed 5 years ago
I guess we dont want to and cant, maintain backwards compatibility?
I don't get it. What problem does this solve?
The original issue mentions..
That's bad practice and if you're not careful it may lead to issues.
What issues specifically?
The "bad practice" part must be in reference to declaring open
in the same scope, without a namespace.
open = "c:\my_file.txt"
with open(open) as f:
f.read()
# Having a bad time
But surely, with a namespace this could not possibly be an issue?
workfiles.open("c:\my_file.txt")
# Having a good time
It's not an ideal name, but this is an API we're changing. APIs cannot break; like diamonds they are forever. Either keep both open
and open_file
around, or leave open
as-is.
Might need to tag in the issue author @jasperges
Isn't it bad practice to shadow built-ins anywhere as one might accidentally get bitten by it later? I think it's general bad practice.
Anyway, I've solely set up this PR to correspond with the related issue and because I'm personally fine with it. Also, because it aligns the methods more with the others like current_file()
which is not current()
plus it resolved the shadowing, as such I agree style wise it's a better choice.
Regarding it being an API. Sure. I understand the backwards compatibility notes. However, I am not sure if this ever was part of any front-facing API that was to be used outside of Avalon. It was only the design implemented for the work files tool. But looking at @tokejepsen his comment it seems the function have been referenced outside that scope too. (Or it was just a general question.)
Feel free to do with it what fits best. :) Maybe @jasperge has other notes to add.
Regarding it being an API. Sure. I understand the backwards compatibility notes. However, I am not sure if this ever was part of any front-facing API that was to be used outside of Avalon. It was only the design implemented for the work files tool. But looking at @tokejepsen his comment it seems the function have been referenced outside that scope too. (Or it was just a general question.)
Ahh yeah, its not in the API so should be alright to rename. I'm guessing...
The "bad practice" part must be in reference to declaring
open
in the same scope, without a namespace.
Yeah, that's correct. But I think it would be a real (internal) bad practice if we need to use the built-in open
inside workio.py
in the future.
So I think we do need this be fixed, but also need to expose the open
in each host api for backward compat. :)
Edit: Although it's not in the scope of the top level API, but it's on top of each host, so I think the backwards compatibility still need to be take cared.
Edit: Although it's not in the scope of the top level API, but it's on top of each host, so I think the backwards compatibility still need to be take cared.
I thought of another issue why this PR is necessary. The open
function is also exposed in __init__.py
for all the hosts. That could be dangerous too, right? It's not solely exposed in the workio.py
The open function is also exposed in
__init__.py
for all the hosts. That could be dangerous too, right?
I think it's actually safe, as long as you keep the namespace when you referencing, and the open
won't affect other function which used built-in open
inside other module.
I did a quick test that has this structure:
./testopen
/__init__.py # Importing both following functions in the same scope
/builtin.py # Has a function that used the built-in `open`
/override.py # Has a function called `open`
And they all worked safely. Unless I am testing in wrong direction ?
I think it's actually safe, as long as you keep the namespace when you referencing, and the open won't affect other function which used built-in open inside other module.
That test does seem to cover the use-cases yes. It just means that no __init__.py
for any of the hosts could ever use the built-in open
, but I guess at this stage it's not a big hurdle.
How about introducing the backwards compatibility only at the end of the __init__.py
file?
# Backwards API compatibility
open = open_file
save = save_file
I guess if anyone ever used it from "the host" then they wouldn't have accessed workio.py
directly anyway, which also goes against the rules of the API.
@davidlatwe you should be able to push changes directly into this branch for the PR if you want to implement backwards compatibility. Or let me know if you want me to add those lines and push it to the branch.
It just means that no init.py for any of the hosts could ever use the built-in open
It's not that serious; you can always __builtins__.open()
if you need it. open
in the global scope is convenience at best, and sometimes it makes sense to override it. Like type
.
How about introducing the backwards compatibility only at the end of the
__init__.py
file?
That's what I have in mind, yes :D And sure, I'll push them later :muscle:
If checked, users with write access to getavalon/core can add new commits to your fix407 branch. You can always change this setting later.
That option is checked. Hmm...
Anyway, on it!
@davidlatwe let me know if it's all good like this. 👍
Merge !
This resolves #407 so that the Work Files API does not shadow the built-in function
open
and refactors it toopen_file
. To keep a consistent API I've implemented the same change forsave
tosave_file
.What's changed?
Update the Work Files API:
open()
->open_file()
save()
->save_file()
to match withopen_file
.This is updated for the implemented hosts, the Work Files tool
README
that describes the API and the work files tool itself of course.