I just checked in Misc/TextMate/Python-Dev.tmbundle for those of you
use TextMate. I have been using this bundle for a while and I figured
others could use it.
Usage tends to expect that you have opened a project from the
top-level directory of a Python checkout. There is support to run the
Makefile, build the docs, open the documentation index file (which can
be set to an environment variable when you are not in a checkout),
open an issue in the browser, and open a PEP in a browser.
There is even a command to generate the boilerplate for marking a file
to be removed in 3.0, complete with automatic fill-in of the module
name in the message string and set up to be triggered as a tab
I am hoping to continue to tweak the bundle as time goes on (and
permits) with more stuff that is useful. This is not meant to replace
the Python bundle, though! This is merely to add stuff specific to
hack on Python itself.
Steve Holden wrote:
> If you want it visible, make a visible symbolic link!
I have to know it's there first. The idea of an installer
deliberately hiding stuff from me in a very unconventional
and non-obvious way makes me uncomfortable.
Dear fellow Pythonistas!
Guido has accepted my user site directory PEP today.
I'm about the merge the code. But first I like to let you know some
things and get your opinion.
The location of the user site-package directory stays as written in my
PEP. The master himself said "The location will be somewhere under
~/.local for Unix/Linux/OS X, and %APPDATA%/Python for Windows (per the
original proposal in the PEP)." Please do NOT take my check-in message
as an opportunity to start yet the third bike shed discussion. Thank you
very much! :)
The PEP adds two environment vars to adjust the location of the user
site directory to your liking or to disable the feature entirely. If you
are still not convinced you are better off by adding a single line to
your .profile file.
For now the unit tests are creating the user site directory tree. I'm
going to chance that in a few days unless everybody is fine with it.
The docs aren't finished yet. Unless somebody is faster than me (*wink*)
I'm going to work on the docs after I've finished the rework of the json
module. As Brett suggested I'm going to module its input and return
values after the pickle module before I merge it into the py3k branch.
It's currently mixing unicode and str in a way which is not compatible
I've added some additional code to the site module. It should become in
handy for scripters, debugging and unit tests:
$ ./python -m site
sys.path = [
USER_BASE: '/home/heimes/.local' (exists)
USER_SITE: '/home/heimes/.local/lib/python2.6/site-packages' (exists)
$ ./python -m site --help
/home/heimes/dev/python/trunk/Lib/site.py [--user-base] [--user-site]
Without arguments print some useful information
With arguments print the value of USER_BASE and/or USER_SITE separated
Exit codes with --user-base or --user-site:
0 - user site directory is enabled
1 - user site diretory is disabled by user
2 - uses site directory is disabled by super user
or for security reasons
>2 - unknown error
$ ./python -m site --user-base --user-site
$ echo $?
$ ./python -s -m site --user-base --user-site
$ echo $?
My name is Heiko N. Weinen and I was accepted as GSoC Student, too. Hoorray!
The project i chose is about Filesystem Virtualisation for Python's Standard Library,
hopefully something which will prove quite useful. :)
Christian Heimes is my Mentor and I'd like to thank him right now for his help.
Feel free to contact me, if you have any further questions or related ideas!
I will set up a project site at http://heiko.weinen.org/gsoc08 in a few days.
Lubarsky's Law of Cybernetic Entomology: prov.
"There is always one more bug."
On Tue, May 6, 2008 at 11:43 AM, Bill Janssen <janssen(a)parc.com> wrote:
> I just made another attempt to use ctypes to wrap a library, and am
> facing the same problem I had the last time: the documentation doesn't
> really work. I'm wondering if we have any projects underway to
> re-write it?
So what exactly is eating you about it?
On Tue, May 6, 2008 at 7:37 AM, Steve Holden <steve(a)holdenweb.com> wrote:
> If you want it visible, make a visible symbolic link!
Note that the point is moot, since I'm going to accept Christian's
PEP, i.e. ~/.local, but this argument "you can make it visible
yourself" is bogus. The point of visibility (when it's brought up)
isn't that you *can* make it visible -- you can always do that with ls
-a or whatever Finder option. The point is that (in some people's
view) the results of an action should be left *in plain sight* so that
the user has clear evidence of what happened.
I'm fine in this case with the counterarguments though, so I'll be
accepting the PEP in a minute.
--Guido van Rossum (home page: http://www.python.org/~guido/)
The next problem that cropped up during the implementation of the AST
code optimizer is related to branch elimination and the elimination of
any code after a return.
Within a FunctionDef node, we would (ideally) like to blow away If nodes
with a constant - but false - test expression. e.g.:
# ... stuff ...
For most functions, this will cause no problems and the code will behave
as expected. However, if the eliminated branch contains a "yield"
expression, the function is actually a generator function - even if the
yield expression can never be reached:
In addition to this, the following should also be treated as a generator
even though we'd like to be able to get rid of all the code following
the "return" statement:
Again, blowing away the yield results in a normal function instead of a
generator. Not what we want: we need to preserve the generator semantics.
Upon revisiting this, it's actually made me reconsider the use of a
Const node for the earlier problem relating to arbitrary constants. We
may be better off with annotations after all ... then we could mark
FunctionDef nodes as being generators at the AST level to force the
compiler to produce code for a generator, but eliminate the branches
The other alternative I can think of is injecting a yield node somewhere
unreachable and ensuring it doesn't get optimized away, but this seems
pretty hacky in comparison.
Any other ideas?
Some people write
somename = lambda args: expression
instead of the more obvious (to most people) and, dare I say, standard
def somename(args): return expression
The difference in the result (the only one I know of) is that the code and
function objects get the generic name '<lambda>' instead of the more
informative (in repr() output or tracebacks) 'somename'. I consider this a
In the absence of any compensating advantages (other than the trivial
saving of 3 chars), I consider the def form to be the proper Python style
to the point I think it should be at least recommended for the stdlib in
the Programming Recommendations section of PEP 8.
There are currently uses of named lambdas at least in urllib2. This to me
is a bad example for new Python programmers.
What do our style mavens think?
Terry Jan Reedy
I would like to propose a new module for the stdlib for Python 2.6
and higher: "ast". The motivation for this module is the pending
deprecation for compiler.ast which is widely used (debugging,
template engines, code coverage etc.). _ast is a very solid module
and is without a doubt easier to maintain then compiler.ast which
was written in Python, it's lacking some features such as pretty
printing the AST or traversing it.
The idea of "ast" would be adding high level functionality for
easier working with the AST. It currently provides these features:
- pretty printing AST objects
- a parse function as easier alias for compile() + flag
- operator-node -> operator symbol mappings (eg: _ast.Add -> '+')
- methods to modify lineno / col_offset (incrementing or copying
the data over from existing nodes)
- getting the fields of nodes as dicts
- iterating over all child nodes
- a function to get the docstring or an AST node
- a node walker that yields all child-nodes recursively
- a `NodeVistor` and `NodeTransformer`
Additionally there is a `literate_eval` function in that module that
can safely evaluate python literals in a string.
Module and unittests are located in the Pocoo Sandbox HG repository:
A slightly modified version of the ast.py module for Python 2.5
compatibility is currently in use for the Mako template engine to
achieve support for Google's AppEngine.
An example module for the NodeVisitor is in the repository which
converts a Python AST back into Python source code:
Our next PyPy sprint will take place in
Berlin, 17-22nd May 2008.
More precisely, the sprint will be in the crashed c-base space station,
Berlin, Germany, Earth, Solar System. This is a fully public sprint:
newcomers (from all planets) and topics other than those proposed in the
announcement are welcome.
For more information: