Just curious, how often is the Python guide updated on http://docs.python-guide.org ?

http://hynek.me/articles/python-deployment-anti-patterns/

Creative Commons Attribution-ShareAlike 3.0. Objections?

It would be nice to get chapter on best practices for measuring Python apps performance.

Hi, i just created launchpad project which goal is to translate this guide for as lot languages as it's possible. If kennethreiz have nothing against maybe this link should be put into readme file? Also I can give right people right permissions at this LP project. What do you think?

Link is: https://launchpad.net/python-guide-pl

First i thought to make this only for polish, but after few minutes i thought "Why not for all?" I will change branch name, but I'm not sure what can i do with the link :( Anyway, maybe kennhethreitz will make another project, more official :P I have made already .pot template for 10 sentences (I just started).

Attribution-ShareAlike 3.0. Objections?

Hi,

I heavily advice people to use the Python Guide but some of then just break their Python installation cause of confusion in OSX installation.

If you follow the guide, you'll install the osx-gcc-installer from kenneth, after that you install homebrew and it say to you, you must install the official command line tools.

And after that your Xcode installation will be broken.
If I well understand situation, osx-gcc-installer is know deprecated since we have official command line tools support from Apple ? For at least OSX "Lion" users ?

Before "Lion", people should choose between full Xcode installation or kenneth package ?

I think we must really removed osx-gcc-installer link on the guide and add the command line tools pkg instead or at least be more precise about this confusion.

Problem

• Installation tutorial suggests to use Distribute, but Distribute has been merged into Setuptools 0.7+.

Resources

• Quoting the latest Distribute stable release:

  This package is a simple compatibility layer that installs Setuptools 0.7+.

Proposed solution

1. Replace Distribute installation instructions with just simply these commands for Setuptools:

   1. Download and install Setuptools from https://pypi.python.org/pypi/setuptools via ez_setup.py:

       $ python ez_setup.py
      

As pillow is becoming standard in community than PIL, I think it's worth mentioning.

This should include a section on "What to do when your library gets popular" addressing backwards compatibility, alpha and beta releases, how to bring in more committers, managing community expectations, and other similar topics.

This would make the styleguide show up for each PR and issue. At the moment, it's easy to miss.

Just wondering, can we get some sort of priority list of what to add onto the guide? On a related note, it'd be nice to see some sort of roadmap for where it's going; are we here to be, for example, an all out comprehensive wiki for all things Python?

What content were you, roughly, imagining in this section?

For http://docs.python-guide.org/en/latest/writing/license/, I have yet to find a comprehensive and simple comparison of open source licenses to reference.

http://paulmillr.com/posts/simple-description-of-popular-software-licenses/ is the best that I've found in graphic form and I believe the the information is accurate, but I'm not an expert!

Is the idea for the page to provide a simple listing of available licenses or suggest a 2-3 main license types depending on your situation?

(Sidenote, know of any statistics on what license type is used most on PyPI or preferred? Or what % of projects lack a license/trove classifier for license type?)

http://www.stuartellis.eu/articles/python-development-windows/

Great stuff.

The Go button is styled and appears as a capsule, not a square.

http://nedbatchelder.com/blog/201007/installing_python_packages_from_windows_installers_into.html

While I'd agree list comprehensions are generally nice, and make one feel very clever when using them, are they necessarily more pythonic than their counterparts?

In your section "Short Ways to Manipulate Lists" you call the following code "Bad",

# Filter elements greater than 4
a = [3, 4, 5]
b = []
for i in a:
    if i > 4:
        b.append(i)

and the following list comprehensions "Good",

b = [i for i in a if i > 4]
b = filter(lambda x: x > 4, a)

The section goes on to include more examples.

I would argue that calling the simpler code "Bad" simply because it takes up more space and doesn't include lambdas/one liners gives the wrong message, especially to beginners. Following the Zen of Python, specifically "Explicit is better than implicit", "Simple is better than complex", and "Readability counts" the list comprehensions could be qualified as less pythonic than the more explicit nested conditional clauses. However, this could be refuted by "Flat is better than nested".

I could be wrong, just thought I would bring it up.

Would it be beneficial to elaborate on choosing between those two?

A year ago I started on writing a draft with title "Open source software for successful project" and never got to finish. Steal any words that seems apropriate!

http://static.domenkozar.com/oss-for-successful-project/

# The name for this set of Sphinx documents.  If None, it defaults to
# "<project> v<release> documentation".
#html_title = None

<title>The Hitchhiker’s Guide to Python! &mdash; pythonguide 0.0.1 documentation</title>

That isn’t very informative.

Since version 1.7 --no-site-packages is the default behavior. Sections covering virtualenv and virtualenvwrapper should be updated to reflect this.

Best practices of python programming regards security. It can cover both for web and desktop programming.

hg-git

I saw "Blueprint" was listed as a systems administration tool. I'm just curious, do you have any link to this tool? I've never heard of it...

Hey, has anyone been working on the Vendorizing Dependencies section?

I've been waiting for it for quite a while, I basically got the hang of it by looking at ken's repos, but maybe there are some best practices I'm unaware of.

Would a pull request be accepted here? I could at least try to start writing something.

Hi,

I always recommend my students on Windows to use ActiveState ActivePython, as it comes with distutils, pip, virtualenv and pywin32 and automatically adds Python to the PATH.

If you approve of the idea, I can submit a pull request, which would be mainly deleting 3/4 of the page and explaining the choice.

http://docs.activestate.com/activepython/2.7/whatsincluded.html

Both dev/env.rst and dev/virtualenvs.rst contain sections about virtualenv and virtualenvwrapper. Is that on purpose?

I was surprised to see there's nothing on JSON here, considering the existence of several good json libraries out there for python.

For example: I want to know why I should use simplejson vs the json module that ships with python.

.. code_style:

need change to

.. _code_style:

The best example in the Mutable and Immutable Types section of the Structuring Your Project page is:

# create a concatenated string from 0 to 19 (e.g. "012..1819")
nums = [str(n) for n in range(20)]
print "".join(nums)

It is considered the best example for being both more efficient and succinct.

Would this be a better example to use?

''.join(map(str, range(20)))

It's more succinct and is faster:

$ python -m timeit "nums = [str(n) for n in range(20)]; ''.join(nums)"
100000 loops, best of 3: 6.84 usec per loop

$ python -m timeit "''.join(map(str, range(20)))"
100000 loops, best of 3: 4.93 usec per loop

The section "Create a length-N list of lists" includes a discussion on the O(n) performance of looking up a performance versus O(1) for a searching the keys of a dictionary that has empty values for each key. Specifically, the following code is presented:

d = {'s': [], 'p': [], 'a': [], 'm': []}
l = ['s', 'p', 'a', 'm']

def lookup_dict(d):
    return 's' in d

def lookup_list(l):
    return 's' in l

The text proceeds to recommend the use of this kind of dict over a list when looking through a set of values, for performance reasons:

Even though both functions look identical, because lookup_dict is utilizing the fact that dictionaries in python are hashtables, the lookup performance between the two is very different. Python will have to go through each item in the list to find a matching case, which is time consuming. By analysing the hash of the dictionary finding keys in the dict can be done very quickly.

Here are my potential beefs with this recommendation:

1. It may be tempting to continue this as a discussion of lists of lists, but I don't believe this belongs under "Idioms." Perhaps it rather belongs in a section about data structures or performance.
2. If the developer intends to only use the values (but no keys), I'd suggest recommend suggesting sets, a structure that is a much more fitting alternative for this use case. To be honest, I don't how the performance of the two compare, but even if sets are an inferior alternative (I doubt this when I think it over, but I have an insufficient understanding and no data to back it), it's a lot clearer. Assuming sets aren't vastly inferior, is there really a need to introduce an idiom when we have a competent data structure for the same thing?
3. If you wish to suggest other structures than a list for performance, you might want to qualify that discussion with indicators as to when that would be appropriate. Without a caveat, this section looks like an endorsement of using lists for every case where you'll be searching the data structure. This is potentially justified (again, I lack an understanding about the underlying data structure), but my immediate hunch is that the overhead of hashing the values exceeds the time it takes to create a simpler element and search it sequentially. If you want to endorse a different data structure for performance reasons perhaps you'll want to say, "if you'll be looking this up multiple times, then you might want this."

Reading this over it all sounds far more critical than I mean it to be – I'm sort of cramming all the thoughts I have about this section into a single, almost exhaustive, discourse of retorts that I could imagine surfacing in a back-and-forth conversation about this. To compensate for my strident opposition, I should note that I think you're doing a great job.

http://inventwithpython.com/blog/2012/07/09/16-common-python-runtime-errors/

Maybe the make.bat that Sphinx creates should be kept so that Windows contributors can easily build the files.

http://docs.python-guide.org/en/latest/scenarios/scientific/ recommends PyQwt for plotting, but the project appears dead.

I have the plan to translate the guide to french, but there is not support for I18N, if you have no better recommendation, I will add the needed settings and adapt this Makefile https://gist.github.com/3742565 for this project.

What do you think ?

Hey, just started scanning through the guide!

In the testing section, http://docs.python-guide.org/en/latest/writing/tests/#unittest2 covers the backport of unittest2 for Python 2.6.

As this is an "opinionated" guide and I'm assuming focused on current Python 2.7, is it worth mentioning backwards compatibility at this point?

Alternatively, since I would think backwards compatibly is a more advanced topic, perhaps it's worth pulling into a new section, that tox can link to?

According to Homebrew's own installation instructions, in order to install Homebrew, you need to curl from "https://raw.github.com/gist/323731", and not "http://gist.github.com/raw/323731/install_homebrew.rb".

When I attempted to use your instructions, I got a 301-permanent redirect error back from github.

Take a look at http://shinken-monitoring.org/ for your Sysadmin section.

it's a Nagios replacement, but far better. and in python!

it's easy to write plugin and it scales very well.

Thank you for the great guide of Python.
May I translate this guidebook to japanese?

Autoenv should be added to "Virtual environments".

You suggest to install Python on Mac OS X via Homebrew. What’s wrong with the binary installers from python.org? Imho, they are easier to install and I didn’t experience any problems with them, yet.

I noticed that http://docs.python-guide.org/en/latest/writing/tests/ does not mention anything about test doubles (mocks, stubs etc.). While I am not a frequent user of mock libraries I do find them useful in some cases. What do you think about adding documentation about this?

References:

• mock seems to be a common test doubles library.
• Here's a StackOverflow question about different Python test doubles libraries.

The LICENSE file is the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) license. However, the link to the license points to the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.

http://www.rafekettler.com/magicmethods.html

You could probably adapt/link to the comprehensive Tk tutorial instead of the currently empty section (which includes guides for Tcl/Ruby/Perl/Python)
http://www.tkdocs.com/tutorial/install.html

Python's closures are late binding. This means that names within closures are looked up at the time the inner function is called.

I propose this wording be changed to

Python's closures are late binding. This means that the values of variables used in closures are looked up at the time the inner function is called.

The difference is illustrated by this code.

s = 'global'
def foo():
    s = 'nonlocal'
    def bar():
        print(s)
    del s
    bar()
foo()

Looking up the name at call time could be taken to mean that the variable to print is decided at call time. But in fact the variable (cell) is fixed at the time bar() is compiled, and it is just the value that is subject to change. In this case, the value is deleted and so NameError is raised.

(Yeah, I'm being a bit pedantic. I guess I'm really just testing out using github and the issue tracker. Nice guide. :) )

Great work with this Python guide!

My only issue is that the guide (http://docs.python-guide.org/en/latest/index.html) overrides my native UI with a different scrollbar. More so, I'd probably be able to live with the scrollbar if it wasn't for the fact that it is so narrow that I can barely grip it with my mouse cursor!