I've had too many experiences like this googling man pages

Now to the pull request your student made. If I understand correctly, the student's main goal is to gain experiense on working with (and contributing to) an OSS project. In this case it may be easier to him to contribute to some project which already has established contributing guidelines and the projecrt maintainers have an experiense of accepting of external contribution. PonyORM was released under Apache license just recently, and our experience in dealing with external contributions is still limited at this point. I hope that PonyORM will gradually become more open to such contributions. The pull request in itself looks good. We have some internal disputes regarding should we accept it or not because of the following reason. Currently we maintan documentation in a separate repository. There ase some benefits in having documentation and code in the same repository and combining code change with corresponding documentation change. But this is convenient when code and documentation are writen by the same person. Currently in PonyORM there are separate persons who write code and documentation. Because of that it is more convenient to us to have two different repositories. This way the probility of merge conflicts are reduced, and unreleased code branches can be rebased more easily. The pool request of your student suggests to include documentation into code in form of docstrings. It may be convenient for a programmer who want to study the code. But after that change the documentation will be duplicated in a two different places - in a separate documentation repository and inside docstrings. It will increase the cost of writing documentation, because now it will be necessary not to forget to update the corresponding place inside some docstring when the main documentation is changed. It is possible to autogenerate documentation from the docstrings, but it will require to us to change the documentation building process, and currently we are not ready for that. Also, it is more convenient to work with documentation when it is contained in a one textual file and not scattered across a multiple docstrings. Because of that, at this moment we are more inclined to work with a documentation which a stored in a small number of a textual files in a separate repository. I think we are ready to accept the pull request and add docstring to the code if someone will maintain them in the future and check that they are correspond with the main documentation.

Cannot suggest anything specific right now, maybe I can tell tomorrow

It is in the making, as far as I know But @akozlovsky will probably tell you more

We are trying to do release before the end of this week which includes support or Python 3.6 and first version of migrations. Migrations are almost ready, but during implementing of migrations it was necessary to change a way many-to-many intermediate tables are named. Previously the name was entity1_entity2, and now it will be named entity1_collection1. This way of naming is better, and the change is necessary even if a developer dosn't plan to use migrations. We need to have a way to upgrade previously created databases. Regarding Python 3.6 support, today I was able to pass all tests except one on Python 3.6, so it is almost ready.

We are trying to do release before the end of this week which includes support or Python 3.6 and first version of migrations. Migrations are almost ready, but during implementing of migrations it was necessary to change a way many-to-many intermediate tables are named. Previously the name was entity1_entity2, and now it will be named entity1_collection1. This way of naming is better, and the change is necessary even if a developer dosn't plan to use migrations. We need to have a way to upgrade previously created databases. Regarding Python 3.6 support, today I was able to pass all tests except one on Python 3.6, so it is almost ready.

The changes are in decompiler, the bytecode was significantly changed

I've got a django project and a hug project going on, and I'd like to eventually run Pony with both.

I think the main difference between django and pony tables is inheritance. Django creates a different table for each subclass, and Pony keep all subclass columns inside the same table. In order to work with Django models we need to add Django-like inheritance to Pony, although it is less efficient than the way used in Pony. Before that Pony will treat Django subclass as a separate model related with a foreign key to a base model.

Kinda tempted to make one, not sure if it'd just be noise though

. Thank you for your wonderful project! 👏 Happy holidays!

Hello. I currently work with Django and PonyORM looks very superior to the Django ORM. The syntax looks much nicer, and on migrations, one frustration with Django is that you can't rename a class easily in their migrations. Would love to see a Pony for Django (to deal with existing projects), and Pony with Flask looks like it could be even better than Django. When will pony.js be released?

Hello. I currently work with Django and PonyORM looks very superior to the Django ORM. The syntax looks much nicer, and on migrations, one frustration with Django is that you can't rename a class easily in their migrations. Would love to see a Pony for Django (to deal with existing projects), and Pony with Flask looks like it could be even better than Django. When will pony.js be released?

I work on oldest java project with hibernate and old spring, and recently i try fast fix some bags in DB with python and pony, and i say u - java sux if u need fast development

I fell in love with python & ponyOrm

I recently used Pony and Flask on a project and they worked fantastically with each other

Have you ever used Django?