pony
pony copied to clipboard
ponyorm
The code is not maintained based on PEP-8
A brilliant piece of work, but it has too ugly codes.
Contributing on this project is so painful.
Could you please accept the pull requests about PEP-8 coding style optimizations? it may make huge changes on the code, but not on logic.
Wow, thanks a lot. We can use some tools. like PyCharm. it has code re-formatting based on pep8 feature.
I have a question to you guys in this regard. How important for you following this convention:
"Always use self for the first argument to instance methods."
We often find useful using the name which gives a hint on what class you are in. E.g. using attr instead of self here:
class Attribute(object):
def __init__(attr, py_type, *args, **kwargs):
attr.is_implicit = False
And what is your opinion?
Not at all. Even if python is completely dynamic and naive.
The similarity and integrity of all python codes, makes the understanding of the other's source code simpler.
Reading source code is often better than documentation for me. most of developers are agree with me.
After all, you can put your project's plan on github's new feature called: project. So I can contribute to this project based on your plan.
Currently I need to write an asset manager for pony, like this.
So after that. I can use pony in my next project.
I just took a pass with autopep8 without the most destructive changes such as breaking the API. I suggest we merge it ASAP.
The pull request looks good. The problem is, at this moment we have several unfinished branches in a private repository which was not pushed to the GitHub public repository yet. The branches are:
- Migrations (in progress)
- Testing framework for launch standard test suite not only with SQLite, but with all supported databases
- PonyJS - a JavaScript library for working with PonyORM entities at the frontend
- Microsoft SQL Server support
We need to merge these branches before reformatting the code, otherwise we will get massive merge conflicts.
So it will be our priority to finish these branches ASAP and merge them into public repository, and after that we can reformat code according to PEP8.
Thank you for your help with this! autopep8 looks like a good tool for this task.
Why was this closed? There is still widespread use of badly readable bla. instead of self. all over the code :(
The issue is closed probably by mistake. I still have a plan to reformat code to make it much closer to PEP8 after we merge all current internal branches.
But I'm against replacing "unreadable bla" to self. With the current notation the code is order of magnitude easier to maintain to me. The names are not random, and follow strict principles, similar to Hungarian notation. Attribute descripton instance is always attr. Entity class is always entity. Entity instance is always obj, etc. It allows me to perform complex global refactorings easily.
When during the refactoring I make a global search and see a line like
return [normalize(attr.name)]
I can understand its meaning and relevance to current refactoring without jumping to source. The attr is guaranteed to be an attribute descriptor disregarding of in which file or inside which class I see that line. whereas looking at abstract
return [normalize(self.name)]
it is impossible to understand the meaning of the line without close looking at the source.
But I'm against replacing "unreadable bla" to self. With the current notation the code is order of magnitude easier to maintain to me. The names are not random, and follow strict principles, similar to Hungarian notation. Attribute descripton instance is always attr. Entity class is always entity. Entity instance is always obj, etc. It allows me to perform complex global refactorings easily.
I'm really sorry, but I have to respectfully disagree here. Let's start with the root of the problem. I guess one of the main readability problems is the really condensed style of writing, which reduces the overview drastically. I suppose it stems from the sheer size of core.py, which is really large for a single module with about 6k condensed lines, mb 8k PEP8 lines with proper spacing. Doing a simple refactor, splitting this into several files, forming a core package instead of a single module, will make life already easier for everyone, and make "vertical real estate" way less precious, so that adding extra empty lines between methods etc. as suggested in PEP8 will improve readability further.
When this has happened, there is another thing to consider. Some of the classes are rather big, grown monsters, with some tendency to the anti-pattern "god class", e.g. the Query class, having 500 lines on its own. Splitting this up into smaller classes, using mixins, or carving out isolated functionality into separate classes, and you'll have small nice classes, fitting into just several screens.
So, after all this suggested refactoring, I guess the point that you had for having bla instead of self, will dissolve itself. It might have been a helpful crutch with the codebase as it is right now, but after some thorough refactoring for readability and maintainability, it won't be necessary anymore. And with that, the crutch will be useless and to further improve readability for all the programmers out there in the world, it will be better to have self instead of bla.
Is there some ETA for merging the branches mentioned on 31.10.2016? This code cleanup is pending for ages now, and imho absolutely overdue. I'd be fine to volunteer for a proper refactoring, if there is some interest by the pony founders.
Common guys.
I can't read, understand and modify the code.
Please provide a plan to do this. I'm ready to free up some time.