Create a successful Python project

Create a successful Python project

• Front-end development tool Tips Introduction-sublime
• The application of SEO in Web page making
• Observer pattern
• Making a chart using D3

English Original: Create successful Python projects, compile: Elaine.ye

Creating a successful open-source Python project involves not just writing useful code, but also the involvement of the community, increasing opportunities for collaboration, skill, and support. Exploring the best practices helps you to create your own successful projects.

The ecosystem of open source Python projects is rich and diverse, allowing you to stand on the shoulders of giants to develop the next open source project. In addition, this means that there is a range of community norms and best practices that you can use to gain a wider adoption of your software by complying with these conventions and applying them to projects.

This article covers a number of practices that have worked well in building large and small projects that have won a wide range of user groups. The advice given here is reasonable and meaningful, but because the results may be different, it is not necessary to follow them as strict dogma.

Let's start with a discussion of how the decoupling process can lead to a more robust community, with greater productivity in writing, maintaining, and supporting open source software.

Comparison of cooperation (collaboration) and mutual Assistance (cooperation)

During the DjangoCon 2011 Congress, David Eaves made a keynote statement, eloquently expressing the idea that although cooperation (collaboration) and mutual Assistance (cooperation) have similar definitions, there are subtle differences:

"I think the collaboration is different from mutual assistance (cooperation), and it requires the parties involved in the project to come up with a solution to the problem." ”

Eaves then gave an entire article on how GitHub became the driving force behind how to innovate the way open source works-especially in the way community management works. In the "How GitHub Saved opensource" article (see Resources), Eaves says:

"I believe that the open source project works best when donors are able to participate in a mutually supportive way with low transaction costs and with high transaction costs as little as possible." The genius of open source is that it does not require a working group to discuss each issue and solve the problem, but rather the opposite. ”

He went on to talk about the value of branching (forking) and how it could reduce the high cost of collaboration by enabling low-cost mutual assistance among participants, who were able to advance the project without approval. This branch shelved the required collaboration until the solution was ready for consolidation, so as to support faster, more dynamic experiments.

You can build your own projects in a similar way, with the same goals: increase low-cost mutual assistance throughout the period of writing, managing, and supporting projects while minimizing costly collaboration.

Write

Start with a piece of paper, create something new, make something creative--or just something slightly different from what's available, and nothing is better than starting a new project and sharing your efforts with the world.

Unlike maintenance, when you write code, you are creating something new rather than modifying or correcting what you already have. Writing and conceiving a project in addition to being a science or an art form, others will see the implementation of the situation and will judge the quality of the code, and your name will always be linked with it.

So. It is important to understand the mindset of the craftsman and how to write the software accordingly. Writing a new project is not just about generating code: the creation and conception of a project involves writing beautifully styled code that is readable, creating test code for the functionality in the validation project at the appropriate time, and making detailed and helpful documentation.

Skills

Process (craft) generally refers to the art industry or occupation needs special skills to hand-make something, usually small-scale production of physical devices. In the sense that software craftsmen are more concerned with quality than quantity, you can extend this definition and apply it to software.

It is important for a craftsman to have an attractive product rather than a function. Specifically, in software, craftsmen strive to ensure that the code is clean and beautiful, that the application programming interface (API) is pleasing to the eye, and that the documentation and test cases give the user the feeling of working with a solid product.

Working in this mindset is a reward for the mind and a lot of enjoyment when creating open source software: You are no longer trapped in response to deadlines, customers, and other external needs, but rather enjoy making some good things at your own time.

Code style and Specification check

Python's enhanced recommendations (Python enhancement Proposal,pep) 8 (see Resources) is a detailed Python style guide that you should build on your own Python project (or at least based on your project's style guide). It's not a dogma to use Pep 8, but the closer you work to THE PEP 8 specification, the easier it is for other Python developers to submit neat patch packs in the standard Python community style.

In addition to style consistency, the concept of code specification (linting) is useful in capturing errors such as missing imports and undefined variables. In addition to the style checker that will help you check out the code that violates the default rules or custom rules, there are also some linter or tools, some of which are most commonly used:

1. Pyflakes
2. Pylint
3. Pep8

See Resources for links to these tools.

Whatever convention you choose to follow, if these conventions deviate from Pep 8, I recommend documenting them so that those who want to contribute to your project understand the coding style you are using, and explicit explanations are better than implicit ones.

The

Pyflakes is a particularly useful specification that balances useful functionality, capturing and marking errors, and does not unduly cling to small, eccentric practices. Here is an example session that uses Pyflakes on a python project:

1234	$ pyflakes kaleo kaleo / forms.py: 1 : ' form ' imported but unused kaleo / forms.py: 4 : undefined name ' forms ' kaleo / forms.py: 6 : undefined name ' forms '

Immediately, the tool tells me that I have an import error to view the file kaleo/forms.py, which I found:

1234	1: fromdjango import form2:3: class InviteForm(forms.Form):4: email_address =forms.EmailField()

As you can see from the content, change the 1th line to the From Django import forms.

Test

It is always a good thing to have a test in your project that validates the validity of your code to prevent regression from being overlooked and, in some cases, as a document, by reading the test code to let others know how your library API works.

That being said, I will not judge the completeness or viability of a project based on whether the project includes test cases or how they are completed. The existence of test cases does not guarantee the quality of the code, which may be a controversial point of view, but I believe it is better to have no testing at all than to measure something wrong. When writing test code, it is important to consider giving various inputs for each test unit.

Document

However, unlike testing, you can judge the quality and skill level of a project based on the quality and breadth of the project document. Creating and maintaining stability in the same way as authoring and maintaining code, well-written and in-depth documentation encourages donors to emulate your approach and make your project easier for users to accept.

With tools such as Sphinx and read the docs (see Resources), you can publish timely, well-looking documents. The use of these tools is a simple matter, that is, write some text content and push the submission. It is appropriate to be accustomed to using commit as much as possible to commit changes to a document.

Maintenance

With the first version published on the Python package Index (PyPI) and the release of the message through various tweet messages and blog posts, you will need to incorporate maintenance considerations into any subsequent authoring activity as you begin to have some users. Users report errors, ask for functionality, mention some of the documents that are not clearly related to the problem, and so on.

Some things you choose not to deal with, give some contingency measures, but other problems, you will be to amend the document or fix the code. Using distributed versioning systems such as GIT (Distributed version control System,dvcs) and often publishing developer packages can greatly simplify maintenance and make it a no-no-no-hassle.

Source Control

There are many dvcs available, including git and mercurial (see resources), regardless of which control system you choose, make sure it provides the source control functionality that gives you the ability to branch your project and then resolve the errors yourself.

The rate at which changes are made depends on many factors, and a key factor is the target audience (for example, other developers, non-technical end-users). If your project is written for developers, encouraging the use of pull requests to report errors or request functionality can really reduce the burden on maintainers. It also promotes a sense of belonging in the community, as everyone merges their donations into future versions.

Development and construction

You will want to release the development version as soon as possible and regularly, and release it every time a set of additional patches comes out, so many times. This will make it easier for other developers working on your project to run on the latest changes in the project. The more people use the code in different situations, the higher the quality of the version will be once the new stable version is released.

Support

Support IS and is maintained, and participation in and building a community of users and contributors is critical. Empowering others to help you through support, you are enhancing the overall collaboration of the project, providing better scalability in terms of the size of the project, and naturally increasing the solution to user problems.

To do this, make sure that you provide multiple channels to increase the opportunity for engagement, making it easier for users to engage with you and participate in the project. Optional communication channels include IRC, mailing lists, and social media aggregation points such as Twitter.

Irc

It is a good idea to set up a communication channel on an IRC platform such as freenode, and I set one for my project: NashVegas; There is only one user except me, although this is rare, my IRC client is running silently in the background. When there are occasional users asking questions, I can only spend a very small amount of transaction costs in a way that is much more dynamic than through the mail to respond.

Mailing list

For most open source projects, it is a standard practice to have a mailing list for support and to discuss the development process among donors. My advice is to put support on a mailing list and divide it into "user" lists and "development" lists only when the content has become too much and affects each group's discussions.

Twitter

Open a Twitter account for the project, where you can quickly discuss your work with you. The Twitter account is also a great place to post project messages.

Conclusion

Writing and donating code to open source software in the Python community is an interesting and rewarding experience. While increasing low-cost mutual assistance opportunities, while focusing on reducing high-cost cooperation, this approach helps the project grow with active donors. In the open source area, for your project, you have a lot of freedom to become a skilled craftsman, take advantage of it and enjoy it. Focus on consistent code style, solid testing, and well-written documentation to increase the chances that your project will be used by users and other developers. In addition, to take advantage of Dvcs, focus on pull requests and publish the development version frequently. Finally, you can provide a variety of support channels and allow the community to assist you in providing this support through these practices to further increase the adoption rate of your projects and to facilitate project growth.

Resources

1. Read Mark Pilgrim's Dive into Python for an introduction to the language.

2. For more information on packaging Python projects, read the article "A Guide to Python packaging (Patrick altman,developerworks,2011 October)".

3. Read more about David Eaves's blog post: Wikis and Open source:collaborative or cooperative? And how GitHub Saved opensource.

4. Before concentrating on the next Python project, make sure you understand this "official" style guide for THE PEP 8,python Code.

5. Take a look at the GitHub page of my project NashVegas as an example of a Python project using Dvcs.

6. Take a look at PyPI.

7. Learn more about the Distributed Python module.

8. The Developerworks Open source area provides a wealth of information about open source tools and the use of open source technologies.

9. Focus on Developerworks on Twitter.

10. Learn more about deza,developerworks,2011 in the easy and beautiful documentation with Sphinx (Alfredo Sphinx year November) article.

Create a successful Python project