I'm in the process of writing C code for the purposes of traversing AST
nodes in the AST optimization branch.
This seems to be an ideal case for code generation based on the ASDL
representation of the AST as we're currently doing for Python-ast.[ch].
I'm already considering this approach for s
I forgot -- you need to link or copy the 'django' directory from
Django 0.97.pre into the app directory. Otherwise you'll be using the
Django 0.96.1 that's included with the AppEngine runtime, and the code
is not compatible with that version.
On Sun, May 4, 2008 at 8:38 PM, Guido van Rossum <[EMAI
This code is now open source! Browse it here:
http://code.google.com/p/rietveld/source/browse
--Guido
On Thu, May 1, 2008 at 9:41 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Some of you may have seen a video recorded in November 2006 where I
> showed off Mondrian, a code review tool tha
Armin Rigo wrote:
More precisely, the sprint will be in the crashed c-base space station,
Berlin, Germany, Earth, Solar System.
You have a crashed space station in Berlin? Wow! I hope
it didn't come down on anything important...
--
Greg
___
Python-De
Raymond Hettinger wrote:
lastname_firstname = lambda r: (r[0].lower(), r[5].lower())
for k, g in groupby(iterable, key=lastname_firstname): ...
That transformation adds clarity. Going further and creating a separate
def-statement outside the current function would just move the relevant
co
On 2008-05-04 21:57, Christian Heimes wrote:
M.-A. Lemburg schrieb:
PYTHONPATH is lacking one feature which is important for lots of
packages and setuptools. The directories in PYTHONPATH are just added to
sys.path. But setuptools require a site package directory. Maybe a new
env var PYTHONSITEP
Nick Coghlan schrieb:
> This is what I see as the goal of PEP 370 as well. Perhaps the PEP could
> be more explicit in spelling that out?
>
> """The primary goal of this PEP is to provide a standard mechanism
> allowing Python users to install distutils packages for their own use
> without affecti
M.-A. Lemburg schrieb:
>> PYTHONPATH is lacking one feature which is important for lots of
>> packages and setuptools. The directories in PYTHONPATH are just added to
>> sys.path. But setuptools require a site package directory. Maybe a new
>> env var PYTHONSITEPATH could solve the problem.
>
> We
On Sun, May 4, 2008 at 11:24 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> Rather than svn authentication i suggest just piggybacking on top of the bug
> trackers authentication. that is an integration i think we should aim for
> anyways and it should keep the no-google-account fear mongers ha
On Sun, May 4, 2008 at 9:36 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> > Personally, I would consider the following sufficient:
> >
> > 1) people who have authenticated themselves against the underlying VCS
> (i.e.
On Mon, Mar 31, 2008 at 12:11 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 30, 2008 at 7:44 PM, Josiah Carlson
>
> <[EMAIL PROTECTED]> wrote:
> >
>
> > I haven't really had time to update the tests/documentation, but
> > again, I wasn't experiencing any strange test failures with
>
On Sun, May 4, 2008 at 3:31 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
...
> for k,g in groupby(iterable, key=lambda r: (r[0].lower(), r[5].lower())):
> ...
> lastname_firstname = lambda r: (r[0].lower(), r[5].lower())
> for k, g in groupby(iterable, key=lastname_firstname): ...
>
[Stefan, can you please keep python-dev in the CC list?]
On Sun, May 4, 2008 at 9:52 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> >> 2) anonymous users can post comments that won't become p
Guido van Rossum wrote:
> On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Personally, I would consider the following sufficient:
>>
>> 1) people who have authenticated themselves against the underlying VCS (i.e.
>> project members) may post public comments and comment
On Sun, May 4, 2008 at 5:52 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
> >> It would be really nice to see support for some other backends, such as Hg
> >> or bzr (which are both written in py
On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Personally, I would consider the following sufficient:
>
> 1) people who have authenticated themselves against the underlying VCS (i.e.
> project members) may post public comments and comment on other comments
Tell me ho
On 2008-05-04 18:14, Christian Heimes wrote:
First, Skip, I *only* care about the default behavior. There's already
a way to do it differently: PYTHONPATH. So, Fred, I think what you're
arguing for is to drop this feature entirely. Or is there some other
use for a new way to allow users to exp
Jesse Noller schrieb:
> One thing that could be done is pick a default name for the parent,
> ala ~/Python - but let users override it with an environment variable
> if they so desire (PYTHON_USER_DIR?) so that those who want it hidden
> can have it hidden, and those of us who don't, don't.
Has a
Nick Coghlan schrieb:
> - for experienced users (Barry, skip, etc) that want ~/.local to be more
> easily accessible, creating a visible ~/local symlink is an utterly
> trivial exercise.
Our you can set the environment variable PYTHONUSERBASE to $HOME.
PYTHONUSERBASE is the root directory for user
> First, Skip, I *only* care about the default behavior. There's already
> a way to do it differently: PYTHONPATH. So, Fred, I think what you're
> arguing for is to drop this feature entirely. Or is there some other
> use for a new way to allow users to explicitly add something to
> sys.path, as
Hi all,
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
ann
[EMAIL PROTECTED] wrote:
As I've said a dozen times in this thread already, the feature I'd like
to get from a per-user installation location is that 'setup.py install',
or at least some completely canonical distutils incantation, should
work, by default, for non-root users; ideally non-adminis
On Sun, May 4, 2008 at 9:58 AM, <[EMAIL PROTECTED]> wrote:
...snip...
> As I've said a dozen times in this thread already, the feature I'd like to
> get from a per-user installation location is that 'setup.py install', or at
> least some completely canonical distutils incantation, should work, by
glyph> As I've said a dozen times in this thread already, the feature
glyph> I'd like to get from a per-user installation location is that
glyph> 'setup.py install', or at least some completely canonical
glyph> distutils incantation, should work, by default, for non-root
glyph>
On 3 May, 11:34 pm, [EMAIL PROTECTED] wrote:
On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote:
Fred asked for a --prefix flag (which is what I was voting on). I
don't
really care what you do by default as long as you give me a way to do
it
differently.
What's most interesting (to me) i
Guido van Rossum wrote:
> On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
>> It would be really nice to see support for some other backends, such as Hg
>> or bzr (which are both written in python), in addition to svn.
>
> Once it's open source feel free to add those!
trac
Steven D'Aprano pearwood.info> writes:
>
> I think you're exaggerating a tad here. Why would you be "very confused"
> when you see TITLEPATTERN() or foo(callback=TITLEPATTERN)? What else
> would TITLEPATTERN be but a callable when it's being used as a
> callable?
The real problem is this exam
Terry Reedy wrote:
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
Visually I find the second form very ugly.
The colon indicates to me that a new line is expected, and
[Terry Reedy]
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
Though def-statements are usually the best way to go,
there are some reasonable cases where the first form reads
Hi,
Guido van Rossum wrote:
> On Sat, May 3, 2008 at 11:46 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> and IF someone adapts it to work on a different
>> platform (Django with regular DB backend) and then hosts it elsewhere.
>
> No, that won't be necessary. If someone contributes an alternate
On Sun, 4 May 2008 01:24:54 am Alex Martelli wrote:
> On Fri, May 2, 2008 at 11:32 PM, Mike Klaas <[EMAIL PROTECTED]>
> wrote: ...
>
> > Sorry, that was a bad example. It is obviously silly if the
> > return value of the function is callable.
>
> ...and yet it's *exactly* what keeps happening to
On Sat, 3 May 2008 08:27:27 pm Nick Coghlan wrote:
> Samuele Pedroni wrote:
> > I found only an example in my personal recent code:
> >
> > START = ""
> > END = ""
> > TITLEPATTERN = lambda s: "%s" % s
> >
> > this three are later used in a very few .find() and .replace()
> > expressions in the sam
On Fri, May 02, 2008, Barry Warsaw wrote:
> On May 2, 2008, at 1:48 AM, [EMAIL PROTECTED] wrote:
>>
>>In the long term, if everyone followed suit on
>>~/.local, that would be great. But I don't want a ~/Python, ~/Java,
>>~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as
>>m
33 matches
Mail list logo
