Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

[Floris Bruynooghe]

On Wed, Jul 22, 2009 at 07:08:26PM -0400, Glenn Maynard wrote:
> On Wed, Jul 22, 2009 at 5:22 PM, M.-A. Lemburg wrote:
> > Maybe I've misunderstood some important detail, but how will
> > their "change" help with anything other than making their
> > distribution a non-standard Python installation ?
> 
> I think I'm a little confused, too, because Python supports the
> /usr|/usr/local separation just fine (setup.py install
> --prefix=/usr/local).
> 
> It seems like it's also using "dist-packages" instead of
> "site-packages".  That part, I don't understand at all--distribution
> packages should go in /usr/lib/pythonx.y/site-packages, and "site"
> packages go in /usr/local/pythonx.y/site-packages; /usr/local *itself*
> means "non-distribution site-installed stuff".  If that's what you're
> referring to, then at least on first impression I agree.

The way Debian does this isn't that stupid.  It solves the problem of
the sysadmin intalling Python distibutions for the system Python
without writing in the system locations, which is a very reasonable
thing to do.

Before Debian used dist-packages,
/usr/local/lib/pythonX.Y/site-packages was added to the sys.path of
the system Python and this was the location where a sysadmin should
add packages (although distutils did not default to that location, so
it wasn so it was still easy to mess up the system package
management).  But this caused trouble for people who installed their
own Python in /usr/local since now you have the same
/usr/local/lib/pythonX.Y/site-packages shared by 2 interpreters.

To solve this the system python moved to dist-packages instead, this
allows the local admin location to use
/usr/local/lib/pythonX.Y/dist-packages which does not conflict with
locally installed interpreters.  Together with this they changed
distutils to install to /usr/local/lib/pythonX.Y/dist-packages by
default, so that a sysadmin would have to go out of their way to mess
up the system package management.

This is a pretty neat solution to the problem.  But the weird thing
(IMHO) is that distutils-sig completely refuses to see this
requirement.  Generally it seems accepted that installing modules in
the system location (/usr/) is a bad thing, but last time it got
discussed there was a point blank refusal to accept that the local
admin needs a location in to install packages in.  I think it would be
great if Python instead provided a general guideline or best practice
for this situation which would be explained in the documentation.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

[Floris Bruynooghe]

On Thu, Jul 23, 2009 at 10:34:30AM +0200, M.-A. Lemburg wrote:
> Python 2.6 has two standard places for installing packages:
> 
> 1. In the stdlib site-packages/ subdir
> 
> 2. In the user home dir's .local/lib/python2.6/site-packages dir

And is missing a 3rd one.  The sysadmin who wants to install packages
globally has to use the first option here, but that conflicts with the
system package management on UNIXes.

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

[Floris Bruynooghe]

On Wed, Sep 23, 2009 at 09:49:16AM +0200, M.-A. Lemburg wrote:
> While it's a good idea to put up some form of meta-data
> into an index, I wonder why you are using setup.cfg
> for this.
> 
> setup.cfg has traditionally been used to configure distutils,
> not to define meta-data. As such you wouldn't want to
> put such a configuration file up on PyPI.
> 
> Wouldn't it be better use a new file for this (with the
> same syntax), e.g. metadata.cfg ?! This would then just
> contain the meta data that needs to be published.

IIRC the goal was to make minimal changes and setup.cfg is known
already.  It's use is similar too: it configures the setup.py script
with static data.

PyPI could only extract the [setup:*] sections if you'r worried about
it having random configuration from developers.  I don't think this is
enough of a argument in favour or not of a metadata file separate from
setup.cfg.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Floris Bruynooghe]

On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
> -1 for deprecating getopt. getopt is super-simple and especially useful for
> c programmers learning python.
> 
> +1 for argparse.+1 for eventual deprecation of optparse - optparse and
> argparse have a very similar syntax and having both is just
> confusing. tsboapooowtdi

+1 on all of this :-)

It would be a shame to see getopt go but optparse -> argparse seems
logical.


Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Floris Bruynooghe]

On Mon, Sep 28, 2009 at 07:28:39AM -0700, Steven Bethard wrote:
> Ok, sounds like there are a number of supporters for keeping getopt
> around and just deprecating optparse. For those who'd like to keep
> getopt around, I have a few questions:
> 
> * Would you be opposed to a note in the getopt documentation
> suggesting argparse as an alternative?

No, I'd encourage such a note.

> * Would you like argparse to grow an add_getopt_arguments method (as
> in my other post)?

That looks nice indeed.

> * If argparse grew an add_getopt_arguments, would you still want to
> keep getopt around? And if so, why?

If clearly documented as "Hey, getopt users, check this out!" then I'd
be indifferent to the proposed deprecation of getopt.

Regards
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OT: detatching from terminal (was: Re: PEP 389: argparse - new command line parsing module)

[Floris Bruynooghe]

On Thu, Oct 01, 2009 at 09:58:59AM +0100, Paul Moore wrote:
> (Question - is it *ever* possible for a Unix program to have invalid
> file descriptors 0,1 and 2? At startup - I'm assuming anyone who does
> os.close(1) knows what they are doing!)

Normally you don't close fd 0, 1 & 2 but rather redirect them to
/dev/null (a black hole).  That saves you from nastiness when a
library or something misbahaves and tries to use one of those.  It
would have been nice if windows GUI-mode programs as you describe them
would do something similar.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

[Floris Bruynooghe]

On Wed, Nov 04, 2009 at 03:54:44PM -0700, Zooko O'Whielacronx wrote:
> It occurred to me to wonder why I haven't investigated how hard it
> would be to make my Python packages Python-3-compatible.  That's right
> -- I haven't even looked closely.  I couldn't even tell you off the
> top of my head what is in Python 3 that I would have to think about
> except for the new unicode regime.  I think the answer is that the
> payoff is just *so* low to me at this point that it doesn't even
> justify me taking 15 minutes to read "What's New In Python 3" or to
> execute 2to3 on my smallest package and see what it does.



You have time to read this thread but no time to read "What's New In
Python 3"?



Personally I found porting to Python 3 a rather pleasant experience
(include C extension module).  I can't wait until I can drop support
for Python 2.2-2.X.

Regards
Floris

PS: I have to admit that the commerial code base I work on is still at
Python 2.5, but that doesn't make me worry in any way.  It'll get to
Python 3 in time (it's running on 2.6 already in development).

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Floris Bruynooghe]

On Fri, Nov 13, 2009 at 06:10:16PM -0600, Robert Kern wrote:
> If you want one idea that would make my use of PyPI much more
> pleasant and informative, it would be to add a "Repository-URL"
> entry to the recommended PyPI metadata so that I could always start
> looking at the code in one click.

+1

Having a "Repository-URL", "Repository-Browse-URL" and a
"Bug-Tracker-URL" field in PyPI would be a lot more usefule then
comments and ratings.


Regards
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] buildtime vs runtime in Distutils

[Floris Bruynooghe]

On Sun, Nov 15, 2009 at 11:27:29PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tarek Ziadé wrote:
> > On Sun, Nov 15, 2009 at 3:35 AM, Christian Heimes  wrote:
> > [..]
> >> Do we really want to change distutils to solve a problem of a third
> >> party packaging system when the problem was created by the very same
> >> third party in the first place? In other words: Should you spend your
> >> precious development time with fixing a problem that isn't our fault?
> >> The decision to split the header files into a separate package, that
> >> isn't installed by default, has already created tons of bad user
> >> experience in the past. Do you want to endorse the split even further?
> > 
> > I didn't know the split story went like this. I took it like the
> > "natural" split everyone
> > agreed on, and I saw this distutils <-> Makefile link like something to fix.
> > 
> > So, it sounds like a bad idea now :)
> 
> Parsing the Makefile at runtime seems like an insane choice anyway to
> me:  +1 for your new module having constants generated at ./configure time.

+1

There have been bugs in the past about
distutils.sysconfig.parse_makefile() not knowing the full make syntax
and there will no doubt still be bugs like this.  Substituting these
variables at ./configure time into a .py.in file would be much safer.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing PEP 386 for addition

[Floris Bruynooghe]

On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> Technical question:
> 
> I don't know what notation this versioning schema was trying for, especially 
> in regards to what the +'s mean:
> N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> Am I missing something here? You could maybe explain what the pluses mean in 
> the PEP, and why some are inside the [] and others are outside.
> 
> Or a regular expression version like this might be more specific. 
> N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)?

The full regex (stripped from named groups) is the rather unreadable:

\d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?

(And hopfully I didn't make a mistake here)

So the '+' in the pseudo notation above roughly means "one or more"
with the brackets meaning "zero or one" so plus and brackets combined
result into "zero or more".  But even then it's might be missing
square brackets around the whole of "[abc]N[.N]+".

Note that the meaning of the contents of the brackets changes too
("abc" is a choice, .postN+ is the recursive notation) so it'll
probably never work exactly.  So maybe the PEP should also include the
full regex for exactness.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing PEP 386 for addition

[Floris Bruynooghe]

On Thu, Dec 10, 2009 at 05:41:01AM +, Michael Mysinger wrote:
> Floris Bruynooghe  gmail.com> writes:
> 
> > On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> > > I don't know what notation this versioning schema was trying for, 
> > > especially
> in regards to what the +'s mean:
> > > N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> > > 
> > The full regex (stripped from named groups) is the rather unreadable:
> > \d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?
> 
> The ()? around the combination of post and dev is not needed. I also think
> [abc]? should just be [abc], as one letter is required to proceed the digit in
> that case, and the full regular expression does help to distinguish exactly
> which of those two is required by the PEP. 

You are right

> If your regular expression with my modifications above is right,
> then using the substitions 'N for \d+', '{} for []', '[] for ()?'
> and '+ for *' leaves:
> 
> N.N[.N]+[{abc}N[.N]+][.postN][.devN]
> 
> Notice that the last two +'s are gone, and overall I think this is more
> consistent psuedo-code.

That's quite readable and more consistent then the original
pseudo-code, I like it.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] First draft of "sysconfig"

[Floris Bruynooghe]

On Mon, Dec 14, 2009 at 11:39:02PM -0500, David Lyon wrote:
> On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
> 
> wrote:
>  But under windows, an application developer might (as in probably
>  would) like to install an application in \Program Files\someapp
>  rather than hidden in the bowels of the python interpretor.
> > ...
> > I'm missing your point 
> 
> The point is that if somebody writes an application in C, they
> will generally speaking not want (under say linux) for that
> application to live in the C compiler directory.
> 
> Same goes for many other languages.
> 
> The point is not controversial in other languages. And it
> shouldn't be here either.

If I write a shared library under C I am expected to install it under
one of the default locations if I don't want to require people to have
to tweak things before they can use it.  I see no difference with
python modules or packages.  Any private modules or packages used by
an application built using python don't have to be on the sys.path by
default (in fact I would encourage them not to be).


> >> Distutils is stopping them.

Distutils isn't perfect but solves the need of installing public
modules and packages quite well.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] --enabled-shared broken on freebsd5?

[Floris Bruynooghe]

On Fri, Jan 08, 2010 at 10:11:51AM +0100, "Martin v. Löwis" wrote:
> Nicholas Bastin wrote:
> > I think this problem probably needs to move over to distutils-sig, as
> > it doesn't seem to be specific to the way that Python itself uses
> > distutils.
> 
> I'm fairly skeptical that anybody on distutils SIG is interested in
> details of the Python build process...

Uh, hum.  Unfounded skepticism.  ;-)
But as said filing a bug sounds better in this case.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Floris Bruynooghe]

On Wed, Jan 20, 2010 at 02:27:05PM -0800, Collin Winter wrote:
> Platform Support
> 
[...]
> In order to support hardware and software platforms where LLVM's JIT
> does not work, Unladen Swallow provides a ``./configure
> --without-llvm`` option. This flag carves out any part of Unladen
> Swallow that depends on LLVM, yielding a Python binary that works
> and passes its tests, but has no performance advantages. This
> configuration is recommended for hardware unsupported by LLVM, or
> systems that care more about memory usage than performance.

I just compiled with the --without-llvm option and see that the
binary, while only an acceptable 4.1M, still links with libstdc++.  Is
it possible to completely get rid of the C++ dependency if this option
is used?  Introducing a C++ dependency on all platforms for no
additional benefit (with --without-llvm) seems like a bad tradeoff to
me.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Floris Bruynooghe]

On Sat, Jan 23, 2010 at 10:09:14PM +0100, Cesare Di Mauro wrote:
> Introducing C++ is a big step, also. Aside the problems it can bring on some
> platforms, it means that C++ can now be used by CPython developers. It
> doesn't make sense to force people use C for everything but the JIT part. In
> the end, CPython could become a mix of C and C++ code, so a bit more
> difficult to understand and manage.

Introducing C++ is a big step, but I disagree that it means C++ should
be allowed in the other CPython code.  C++ can be problematic on more
obscure platforms (certainly when static initialisers are used) and
being able to build a python without C++ (no JIT/LLVM) would be a huge
benefit, effectively having the option to build an old-style CPython
at compile time.  (This is why I ased about --without-llvm being able
not to link with libstdc++).

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Floris Bruynooghe]

On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
> I'm working on a patch to completely remove all traces of C++ with
> configured with --without-llvm. It's a straightforward change, and
> should present no difficulties.

Great to hear that, thanks for caring.

> For reference, what are these "obscure platforms" where static
> initializers cause problems?

I've had serious trouble on AIX 5.3 TL 04 with a GCC toolchain
(apparently the IBM xlc toolchain is better for that instance).  The
problem seems to be that gcc stores the initialisation code in a
section (_GLOBAL__DI IIRC) which the system loader does not execute.
Altough this was involving dlopen() from a C main() which U-S would
not need AFAIK, having a C++ main() might make the loader do the right
thing.  I must also note that on more recent versions (TL 07) this was
no problem at all.  But you don't always have the luxury of being able
to use recent OSes.


Regards
Floris

PS: For completeness sake this was trying to use the omniorbpy module
with Python 2.5.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Floris Bruynooghe]

On Mon, Jan 25, 2010 at 11:48:56AM -0800, Jeffrey Yasskin wrote:
> On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver  wrote:
> > Collin Winter wrote:
> >
> >> For reference, what are these "obscure platforms" where static
> >> initializers cause problems?
> >
> > It's been a long while since I had to deal with it, but the "usual
> > suspets" back in the day were HP-UX, AIX, and Solaris with non-GCC
> > compilers, as well as Windows when different VC RT libraries got into
> > the mix.
> 
> So then the question is, will this cause any problems we care about?
> Do the problems still exist, or were they eliminated in the time
> between "back in the day" and now? In what circumstances do static
> initializers have problems? What problems do they have? Can the
> obscure platforms work around the problems by configuring with
> --without-llvm? If we eliminate static initializers in LLVM, are there
> any other problems?

When Collin's patch is finished everything will be lovely since if
there's no C++ then there's no problem.  Since I was under the
impression that the JIT/LLVM can't emit machine code for the platforms
where these C++ problems would likely occur nothing would be lost.  So
trying to change the LLVM to avoid static initialisers would not seem
like a good use of someones time.

> We really do need precise descriptions of the problems so we can avoid them.

Sometimes these "precise descriptions" are hard to come by.  :-)


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Floris Bruynooghe]

Hello Collin

On Mon, Jan 25, 2010 at 05:27:38PM -0800, Collin Winter wrote:
> On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe
>  wrote:
> > On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
> >> I'm working on a patch to completely remove all traces of C++ with
> >> configured with --without-llvm. It's a straightforward change, and
> >> should present no difficulties.
> >
> > Great to hear that, thanks for caring.
> 
> This has now been resolved. As of
> http://code.google.com/p/unladen-swallow/source/detail?r=1036,
> ./configure --without-llvm has no dependency on libstdc++:

Great, thanks for the work.

Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Help wanted on a code generator project

[Floris Bruynooghe]

On Tue, Jan 26, 2010 at 04:40:29AM -0800, Yingjie Lan wrote:
> I googled c.l.py but found 
> few pages (one link said it is a dead list, but anyway), 
> would you care give the information
> where to join it?

comp.lang.python newsgroup, see: http://python.org/community/lists/

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3147: PYC Repository Directories

[Floris Bruynooghe]

On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote:
> Barry Warsaw  writes:
> 
> > I suppose this is going to be very subjective, but in skimming the
> > thread it seems like most people like putting the byte code cache
> > artifacts in subdirectories (be they siblings or folder-per-folder).
> 
> I don't understand the distinction you're making between those two
> options. Can you explain what you mean by each of “siblings” and
> “folder-per-folder”?

sibilings: the original proposal, i.e.:

foo.py
foo.pyr/
MAGIC1.pyc
MAGIC1.pyo
...
bar.py
bar.pyr/
MAGIC1.pyc
MAGIC1.pyo
...

folder-per-folder:

foo.py
bar.py
__pyr__/
foo.MAGIC1.pyc
foo.MAGIC1.pyo
foo.MAGIC2.pyc
bar.MAGIC1.pyc
...

IIUC

Personally I'm +1 on the folder-per-folder option.


Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__ is not always an absolute path

[Floris Bruynooghe]

On Mon, Feb 08, 2010 at 12:51:22PM +, Antoine Pitrou wrote:
> Do some people actually rely on the fact that changing the current directory
> will also change the import path?

On the interactive prompt, yes.  But I guess that's a habit that could
be easily un-learnt.

Regards
Floris



-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

[Floris Bruynooghe]

On Sat, Feb 27, 2010 at 10:56:13AM -0500, Barry Warsaw wrote:
> On Feb 26, 2010, at 10:59 PM, Michael Foord wrote:
> 
> >There are several companies who currently ship bytecode only. (There was 
> >someone on the IronPython mailing list only last week asking if 
> >IronPython could support pyc files for this reason). For many 
> >pointy-haired-bosses 'some' protection is enough and having Python not 
> >support this (out of the box) would be a black mark against Python for them.
> 
> Would it not be better to ship a zip file with an obfuscated name?  Doesn't
> that satisfy the use case nicely?

Sure, we combine that with putting .pyo files inside the zipfile tough
(for assert statements and if __debug__ blocks).  I'm rather confused
about everything proposed by now but would that keep working?

Also somewhere else in the thread it seemed like both you and Guido
suggested that simply creating a directory with some .pyc (or .pyo I
guess) files in would keep working, just by default they won't be
written there by python.  Or is it that functionality some want to cut
because of the doubling of the stat calls?  (But even then I'm not
convinced that would double the stat calls for normal users, only for
those who only ship .pyc files)

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

[Floris Bruynooghe]

On Sun, Feb 28, 2010 at 02:51:16PM +1300, Greg Ewing wrote:
> Floris Bruynooghe wrote:
> >(But even then I'm not
> >convinced that would double the stat calls for normal users, only for
> >those who only ship .pyc files)
> 
> It would increase the number of stat calls for normal
> users by 50%. You would need to look for a .pyc in the
> source directory, then .py in the source directory and
> .pyc in the cache directory. That's compared to two
> stat calls currently, for .py and .pyc.

Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for .pyc in the
source directory (2nd stat + read for magic number check).  Or am I
missing a subtlety?


> A solution might be to look for the presence of the
> cache directory, and only look for a .pyc in the source
> directory if there is no cache directory. Testing for
> the cache directory would only have to be done once
> per package and the result remembered, so it would
> add very little overhead.

That would work too, but I don't understand yet why the .pyc check in
the source directory can't be done last.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

[Floris Bruynooghe]

On Sun, Feb 28, 2010 at 11:07:27PM +1000, Nick Coghlan wrote:
> Michael Foord wrote:
> >> Can't it look for a .py file in the source directory first (1st stat)?
> >> When it's there check for the .pyc in the cache directory (2nd stat,
> >> magic number encoded in filename), if it's not check for .pyc in the
> >> source directory (2nd stat + read for magic number check).  Or am I
> >> missing a subtlety?
> > 
> > The problem is doing this little dance for every path on sys.path.
> 
> To unpack this a little bit for those not quite as familiar with the
> import system (and to make it clear for my own benefit!): for a
> top-level module/package, each path on sys.path needs to be eliminated
> as a possible location before the interpreter can move on to check the
> next path in the list.

Aha, that was the clue I was missing.  Thanks!

Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

[Floris Bruynooghe]

On Sun, Feb 28, 2010 at 09:45:56PM +0100, Baptiste Carvello wrote:
> However, making a difference between zipimport and the filesystem
> importer means the application will stop working if I unzip the
> library zip file, which is surprising. Unzipping the zip file can be
> handy when debugging a bug caused by a forgotten module.

That difference exists already, the zipimporter will happily run .pyo
files inside the zipfile even when you're not running with -O or
PYTHONOPTIMIZE.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

[Floris Bruynooghe]

On Thu, May 20, 2010 at 11:55:02AM +0900, Stephen J. Turnbull wrote:
> Giampaolo Rodolà writes:
>  > >>> class A:
>  > ... def echo(self, x):
>  > ... return x
>  > ...
>  > >>> a = A()
>  > >>> a.echo()
>  > Traceback (most recent call last):
>  >   File "", line 1, in 
>  > TypeError: echo() takes exactly 2 arguments (1 given)
>  > >>>
>  > 
>  > I bet my last 2 cents this has already been raised in past but I want
>  > to give it a try and revamp the subject anyway.
>  > Is there a reason why the error shouldn't be adjusted to state that
>  > *1* argument is actually required instead of 2?
> 
> As a function, it does take two arguments, and can be called
> explicitly that way, no?  Adjustment is not enough, the message needs
> to be substantially rewritten.  Something like
> 
> TypeError: invoked as a method, echo() takes exactly 1 argument (0 given)
> 
> captures the semantics, but is perhaps too verbose.

How about:

TypeError: bound method echo() takes exactly 1 argument (0 given)

That way you can also have: "unbound method echo() ...".  And it's as
semantically correct as the short "echo() takes ..."

Not having looked at the code I don't know how hard it is for the code
that raises this traceback to notice if it's a bound or unbound method
tough.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3148 ready for pronouncement

[Floris Bruynooghe]

Hi

On Sun, May 23, 2010 at 10:47:08AM +1000, Brian Quinlan wrote:
> Jesse, the designated pronouncer for this PEP, has decided to keep
> discussion open for a few more days.
> 
> So fire away!

In thread.py the module automatically registers a handler with atexit.
I don't think I'm alone in thinking libraries should not be doing this
sort of thing unconditionally behind a user's back.  I'm also not so
sure how comfortable I am with the module-level globals.

Would it not be possible to have an exit handler on each thread pool
which the documentation reccomends you register with atexit if it
suits your application?  I think that would get rid of the global
singletons and hidden atexit in a fairly elegant way.

Lastly _base.py creates a LOGGER (connected to sys.stderr if I
understand correctly) and only logs a critical message to it at the
same time as a RuntimeError is raised.  While I don't necessarily
dislike that it uses a logger, I don't like that it's wired up to
sys.stderr I rather think it's the application's duty to create a
handler if it wants one.  But given that it's only used at the same
time as a RuntimeError it does seem redundant.

Regards
Floris

PS: I've only looked at the threading part of the implementation.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3148 ready for pronouncement

[Floris Bruynooghe]

On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
> On 27/05/10 00:31, Brian Quinlan wrote:
> 
> >You have two semantic choices here:
> >1. let the interpreter exit with the future still running
> >2. wait until the future finishes and then exit
> 
> I'd go for (1). I don't think it's unreasonable to
> expect a program that wants all its tasks to finish
> to explicitly wait for that to happen.

I'd got for (1) as well, it's no more then reasonable that if you want
a result you wait for it.  And I dislike libraries doing magic you
can't see, I'd prefer if I explicitly had to shut a pool down.  And
yes, if you shut the interpreter down while threads are running they
sometimes wake up at the wrong time to find the world around them
destroyed.  But that's part of programming with threads so it's not
like the futures lib suddenly makes things behave differently.

I'm glad I'm not alone in preferring (1) tough.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[Floris Bruynooghe]

On 29 September 2010 22:25, Nick Coghlan  wrote:
> On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw  wrote:
>> I don't think it should be in the gc module, but I would prefer it be enabled
>> and controlled through a separate module, rather than something Python does
>> automatically for your convenience.
>
> The os module would seem to be the place to enable/disable tracking of
> OS level resource leaks (i.e. file descriptors and possible HANDLES on
> Windows).

Heh, I was expecting the sys module to be the natural choice because
this would be changing interpreter behaviour.  It's just random
bikeshedding at this point however.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Floris Bruynooghe]

Hi

Sorry for the late response

On 8 October 2010 13:02, Fred Drake  wrote:
> I'm in favor of add a top-level setup module that can be invoked using
> "python -m setup ...".

I'd say +1 for this option.  It has the advantage that it's very clear
which python environment you're installing (or whatever other valid
action) the package into.  For a stand-alone script this might not
always be as clear.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Floris Bruynooghe]

On 10 November 2010 04:12, Stephen J. Turnbull  wrote:
> Nick Coghlan writes:
>
>  > > Module writers who compound the error by expecting to be imported
>  > > this way, thereby bogarting the global namespace for their own
>  > > purposes, should be fish-slapped. ;)
>  >
>  > Be prepared to fish-slap all of python-dev then - we use precisely
>  > this technique to support optional acceleration modules. The pure
>  > Python versions of pairs like profile/_profile and heapq/_heapq
>  > include a try/except block at the end that does the equivalent of:
>  >
>  >   try:
>  >     from _accelerated import * # Allow accelerated overrides
>  >   except ImportError:
>  >     pass # Use pure Python versions
>
> But these identifiers will appear at the module level, not global, no?
> Otherwise this technique couldn't be used.  I don't really understand
> what Tres is talking about when he writes "modules that expect to be
> imported this way".  The *imported* module shouldn't care, no?  This
> is an issue for the *importing* code to deal with.

I can't think of stdlib examples, but for 3rd party packages I'd say
storm.locals and fabric.api are examples of packages designed with
"from foo import * " in mind.  So this does happen.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 11: Dropping support for ten year old systems

[Floris Bruynooghe]

On 6 December 2010 09:18, "Martin v. Löwis"  wrote:
>> Also, it is not clear what to do about distributions/OSs
>> without any official EOL or life cycles.
>
> Here my proposal stands: 10 years, by default.

How about max(EOL, 10years)?  That sounds like it could be a useful guideline.

(Personally I'd be sad to see Solaris 8 go in the next few years)

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 11: Dropping support for ten year old systems

[Floris Bruynooghe]

On 6 December 2010 18:55, "Martin v. Löwis"  wrote:
> Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
>> On 6 December 2010 09:18, "Martin v. Löwis"  wrote:
>>>> Also, it is not clear what to do about distributions/OSs
>>>> without any official EOL or life cycles.
>>>
>>> Here my proposal stands: 10 years, by default.
>>
>> How about max(EOL, 10years)?  That sounds like it could be a useful 
>> guideline.
>>
>> (Personally I'd be sad to see Solaris 8 go in the next few years)
>
> I guess we'll be sorry, then: under that policy, max(EOL, 10years) comes
> out as "not supported" (not sure whether you were aware of that).

I was :-)
Which is why I said "sad" and not "panic" or something.  I do realise
I'm probably in the minority and that it doesn't justify the burden on
everyone in the Python community.

> We are not going to take the sources of old releases offline.

exactly

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python merge module

[Floris Bruynooghe]

On 3 February 2011 15:38, Michael Urman  wrote:
> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.

At work we keep the required stable UUIDs in an ConfigParser-format
file checked in to the VCS for that purpose.

FWIW our build system uses WiX (v2) currently and if I where to redo
it, I'd change to msilib and not WiX v3.  But never change working
systems.

Python.org supplied merge modules would be nice though, if the
upgrade/security issue can be resolved.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] dependency injection for testing [was Python 3.3 release schedule posted]

[Floris Bruynooghe]

On 24 March 2011 02:16, Michael Foord  wrote:
> On 24/03/2011 02:06, Jesus Cea wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 23/03/11 20:56, Georg Brandl wrote:
>>>
>>> For 3.3, I'd like to revive the tradition of listing planned large-scale
>>> changes in the PEP.
>>
>> I want to integrate dependence injection in the stdlib, specially in
>> libs creating sockets. This would be an optional feature.
>>
>> The idea would be, for instance, that smtplib could call an optional
>> constructor to create a socket-like object, if some is provided.
>>
>> That would break the implicit dependency with sockets, reduce
>> monkey-patching need, and ease testing the libs.
>
> In general I dislike dependency injection if it's only done for testability.
> With monkey patching (if done right) you can safely test Python code without
> messing with your public interfaces just to make code testable.

Though in this case this sounds interesting to me as it would allow
using stdlib modules with e.g. "green" sockets from eventlet or gevent
without having to revert to monkey patching (which I don't mind for
testing but dislike for production).  In a way I'm always a little
disappointed when a library uses sockets out of my reach, ideally
you'd be able to use a library abstracted away from this so you can
plug in into async frameworks and other things the author didn't
foresee.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Policy for making changes to the AST

[Floris Bruynooghe]

On 4 April 2011 19:07, Glyph Lefkowitz  wrote:
>
> On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
>
>> On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
>>  wrote:
>>> As a re-implementor of ast.py that tries to be node for node
>>> compatible, I'm fine with #1 but would really like to have tests that
>>> will fail in test_ast.py to alert me!
>>
>> [and]
>>
>> On Mon, Apr 4, 2011 at 10:38 AM, Michael Foord
>>  wrote:
>>> A lot of tools that work with Python source code use ast - so even though
>>> other implementations may not use the same ast "under the hood" they will
>>> probably at least *want* to provide a compatible implementation. IronPython
>>> is in that boat too (although I don't know if we *have* a compatible
>>> implementation yet - we certainly feel like we *should* have one).
>>
>> Ok, so it sounds like ast is *not* limited to CPython?
>
> Oh, definitely not.  I would be pretty dismayed if tools like 
> 
>  would not run on Jython & PyPy.

Add py.test as an application that uses the AST to support Jython,
PyPy and CPython in a portable way.  I always assumed AST was created
*because* bytecode was too CPython specific (but then I've never
implemented a language).

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] the role of assert in the standard library ?

[Floris Bruynooghe]

On 28 April 2011 23:07, Guido van Rossum  wrote:
> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
>  wrote:
>>
>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>
>>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum  wrote:
 On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé  
 wrote:
> In my opinion assert should be avoided completely anywhere else than
> in the tests. If this is a wrong statement, please let me know why :)

 I would turn that around. The assert statement should not be used in
 unit tests; unit tests should use self.assertXyzzy() always.
>>>
>>> FWIW this is only true for the unittest module/pkg policy for writing and
>>> organising tests. There are other popular test frameworks like nose and 
>>> pytest
>>> which promote using plain asserts within writing unit tests and also allow 
>>> to
>>> write tests in functions.  And judging from my tutorials and others places 
>>> many
>>> people appreciate the ease of using asserts as compared to learning tons
>>> of new methods. YMMV.
>>
>> I've also observed that people appreciate using asserts with nose.py and 
>> py.test.
>
> They must not appreciate -O. :-)

Personaly I'd love to get rid of all of -O's meanings apart from
setting __debug__ to False.  Then you can write a strip tool which
could strip all docstrings, just unused docstrings (an improvement
over -O), and any "dead" code resulting from setting __debug__ to
either True or False.  The last thing to do is place assert statements
inside a if __debug__ block.

That way you could use the strip tool on the modules under test but
not on the test modules.

Regards
Floris

PS: I actually wrote some prototype code for such a strip tool last
year but never finished it off, so I'm pretty sure most of this is
possible.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Floris Bruynooghe]

On Fri, Mar 21, 2008 at 10:04:45PM -0400, Phillip J. Eby wrote:
> At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
> >However, I'm extremely skeptical that this can ever succeed
> >to the degree that whoever provides RPMs, .debs, or MSI
> >files will actually use such data, as they will find that
> >the data are incomplete, and they have to redo all of it,
> >anyway.
> 
> The data isn't for them to use to meet their use cases, it's for them 
> to *provide* so that Python tools don't stomp on, uninstall, or 
> otherwise interfere with files installed by the system.  In other 
> words, for system packagers, it's a communication from the system to 
> Python, rather than the other way around.  Even though the distutils 
> will build the file in the bdist, the system packaging tools would be 
> free to generate their own file listing and signatures and such.

As long as systems (dpkg, rpm, ...) install the .egg-info files they
do communicate which modules/distributions are installed.  The
installdb would just duplicate this information (according to the
current PEP).


> >>And as I said, I'll be happy if all we do is get the distutils to 
> >>abide by the spec for 2.6, even if it means we don't get an 
> >>uninstall tool.  That can always be installed later using Guido's 
> >>bootstrap tool.  :)
> >
> >I'm even more skeptical here. If the assumption is that the package
> >database allows for uninstallation, I'm -1. IOW, RPM, deb, MSI
> >should then *not* write to that package database, as they also write
> >to a different database, out of the scope of the PEP, and this is
> >what uninstallation should use.
> 
> I probably should have brought this up, in fact, I think I mentioned 
> it in a previous thread, but I would like to see PEP 262 add a way to 
> say "this is a system-installed package, *don't touch*".  The idea 
> again is not to do the job of the native packaging system, but rather 
> to ensure that Python-specific tools (e.g. easy_install and friends) 
> do not interfere or conflict with it.
> 
> A big problem in the early development of easy_install, even using 
> eggs, was that there was no way to tell whether it was safe to delete 
> or overwrite an existing file or directory that was already installed 
> on the system.  A mechanism like this would allow tools like 
> easy_install to say, "oh, your system packager has a conflicting 
> package here, you need to use that tool to sort this out if you 
> really want to do something here.  I'm not going to touch 
> that."  Without something like this, there is no way to tell the 
> difference on many systems between a system package and something the 
> user has put there with "sudo python setup.py install".

There is a way of telling if you have to keep you hands off a package
(sorry to bring this up again): installation paths.  /usr/lib is the
system path, the local admin (and hence setuptools) should keep their
hands off it at all times (unless requested with a --prefix or so for
building the debs or rpms but an uninstall in those cases won't be
required from setuptools).

What an installdb could help with is tell setuptools to keep it's
hands off a distribution manually installed (or by another tool) in
the local admin directory (/usr/local) or user directory (~/).  Your
proposal of an installdb for each directory on sys.path would solve
this, but the installdb in /usr/lib will be completely usused.

But frankly, for that just an extra field in the .egg-info
"Installed-By: setuptools" would do no?  Possibly followed by a
"X-Setuptools-Installed-Files:" section if you need that.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Floris Bruynooghe]

On Sat, Mar 22, 2008 at 12:33:49PM +0100, "Martin v. Löwis" wrote:
> > The data isn't for them to use to meet their use cases, it's for them to 
> > *provide* so that Python tools don't stomp on, uninstall, or otherwise 
> > interfere with files installed by the system.  In other words, for 
> > system packagers, it's a communication from the system to Python, rather 
> > than the other way around.  Even though the distutils will build the 
> > file in the bdist, the system packaging tools would be free to generate 
> > their own file listing and signatures and such.
> 
> Ok, that's a reasonable requirement. It will be difficult to implement,
> though, as it will require Linux distributors (in particular) to include
> the database snippets in their packages.
> 
> Essentially, one would have to contribute patches to all the 
> distributions (we care about, at least), and then nag the respective
> maintainers to include these patches.

Not true.  You just need to make sure that "setup.py install" creates
that database.  With the proposed format of the database this is just
a file in the correct location - exactly for this reason.  Next time
the distribution will build the package that database file will be in
place.

I still maintain that an installdb for the system packages doesn't
bring anything to the party as it would be in a system-only directory.
But I've argued that in my other emails...


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Floris Bruynooghe]

On Sat, Mar 22, 2008 at 03:14:05PM +0100, "Martin v. Löwis" wrote:
>>> Essentially, one would have to contribute patches to all the  
>>> distributions (we care about, at least), and then nag the respective
>>> maintainers to include these patches.
>>
>> Not true.  You just need to make sure that "setup.py install" creates
>> that database.  With the proposed format of the database this is just
>> a file in the correct location - exactly for this reason.  Next time
>> the distribution will build the package that database file will be in
>> place.
>
> How so? Are you /sure/ the packaging process even *runs* setup.py?
> And if they do, why do you think they will pick up the database
> file?

I speak for Debian, so for Debian: yes.  The setup.py would have to be
pretty bad for a packager to not use it.  There is no reason to
re-write upstream's installation procedure as you would have to figure
out which files need to be installed where and this would create many
bugs.

The canonical way is something like this:

  $ pythonX.Y setup.py --root=$(pwd)/debian/tmp
  $ # Fixup anything done wrong/badly (for debian) by setup.py
  $ # Make a tarball of $(pwd)/debian/tmp

In reality it's slightly more complicated of course.  At [1] there are
many packages, paste and parallelpython are good examples if you're
interested (look in the debian/rules file).


Regards
Floris

[1] http://svn.debian.org/wsvn/python-modules/packages/?rev=0&sc=0

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Floris Bruynooghe]

On Sat, Mar 22, 2008 at 04:42:36PM +0100, "Martin v. Löwis" wrote:
>> I speak for Debian, so for Debian: yes.  The setup.py would have to be
>> pretty bad for a packager to not use it.  There is no reason to
>> re-write upstream's installation procedure as you would have to figure
>> out which files need to be installed where and this would create many
>> bugs.
>>
>> The canonical way is something like this:
>>
>>   $ pythonX.Y setup.py --root=$(pwd)/debian/tmp
>>   $ # Fixup anything done wrong/badly (for debian) by setup.py
>>   $ # Make a tarball of $(pwd)/debian/tmp
>>
>> In reality it's slightly more complicated of course.
>
> More than slightly so, with pycentral, pysupport, and all that.
>
> I still doubt that the database would show up in a directory on
> sys.path.

If not it would be a bug in pycentral/pysupport.  Only two bugs to
file, not that bad I think!

>> At [1] there are
>> many packages, paste and parallelpython are good examples if you're
>> interested (look in the debian/rules file).
>
> I started with nevow. It uses cdbs, so its debian/rules is nearly
> empty, and does not include a call to setup.py at all.
>
> Instead, the distutils support is in
>
> /usr/share/cdbs/1/class/python-distutils.mk
[...]

Again, that would be a bug in CDBS.

For the specific snippet you showed, yes that does essentially
"pythonX.Y setup.py --root=$some_alternate_root" as I said above.  As
an aside I also happen to be in the camp that dislikes CDBS...


The specifics and complications don't matter for this discussion I
think.  If setup.py installs the correct file into the installdb then
it will work in almost all cases, Neal Becker confirmed this is true
for Fedora as well.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

[Floris Bruynooghe]

On 17 April 2012 16:36, Barry Warsaw  wrote:
> On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>
>>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl  wrote:
>>> On 16.4.2012 18:10, Nam Nguyen wrote:
>>> > a_list[pos + 1 : -1]
>>>
>>> or other way around
>>>
>>> a_list[pos+1:-1]
>>
>>
>>That's what I always use.  No spaces inside the brackets for me :)
>>
>>If the expression gets unreadable that way, factor it out.

Ditto here.

And since this is OT by now, one of the other pep8 annoyances I
have[0] is the blanket whitespace around arithmetic operators,
including **.  To me the first just looks ugly:

>>> 1024 ** 2
>>> 1024**2

Certainly when the expressions are larger.

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

[Floris Bruynooghe]

[resent since I accidentally dropped the list]

Hi,

On 19 April 2012 15:55, Barry Warsaw  wrote:
> I'll make this change to the PEP.  I'm not entirely sure the Yes/No examples
> are great illustrations of this change in wording though.  Here's the diff so
> far (uncommitted):
>
> diff -r 34076bfed420 pep-0008.txt
> --- a/pep-0008.txt      Thu Apr 19 10:32:50 2012 +0200
> +++ b/pep-0008.txt      Thu Apr 19 10:53:15 2012 -0400
> @@ -305,7 +305,11 @@
>   ``>=``, ``in``, ``not in``, ``is``, ``is not``), Booleans (``and``,
>   ``or``, ``not``).
>
> -- Use spaces around arithmetic operators:
> +- If operators with different priorities are used, consider adding
> +  whitespace around the operators with the lowest priority(ies). This
> +  is very much to taste; however, never use more than one space, and
> +  always have the same amount of whitespace on both sides of a binary
> +  operator.

While the text is certainly an improvement it seems to me that right
now some of the examples following under the "No:" should be moved to
"Yes:"

"""
No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
"""

In particular "x = x*2 -1" and "hypot2 = x*x + y*y" sound like they
should be under "Yes".

Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deprecating .pyo and -O

[Floris Bruynooghe]

On 14 June 2012 11:25, Antoine Pitrou  wrote:
> Honestly, I think the best option would be to deprecate .pyo files as
> well as the useless -O option. They only cause confusion without
> providing any significant benefits.

+1

But what happens to __debug__ and assert statements?  I think it
should be possible to always put assert statements inside a __debug__
block and then create -O a simple switch for setting __debug__ to
False.  If desired a simple strip tool could then easily remove
__debug__ blocks and (unused) docstrings.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Signed packages

[Floris Bruynooghe]

On 22 June 2012 17:56, Donald Stufft  wrote:
> On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
>
> Key distribution is the real issue though. If there isn't a key
> distribution infrastructure in place, we might as well not bother with
> signatures. PyPI could issue x509 certs to packagers. You wouldn't be
> able to verify that the name given is accurate, but you would be able
> to verify that all packages with the same listed author are actually
> by that author.
>
> I've been sketching out ideas for key distribution, but it's very much
> a chicken and egg problem, very few people sign their packages (because
> nothing uses it currently), and nobody is motivated to work on
> infrastructure
> or tooling because no one signs their packages.


I'm surprised gpg hasn't been mentioned here.  I think these are all
solved problems, most free software that is signed signs it with the
gpg key of the author.  In that case all that is needed is that the
cheeseshop allows the uploading of the signature.  As for key
distribution, the keyservers take care of that just fine and we'd
probably see more and better attended signing parties at python
conferences.

Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Signed packages

[Floris Bruynooghe]

Oh sorry, having read the thread this spawned from I see you're taking
about MS Windows singed binaries.  Something I know next to nothing
about, so ignore my babbling.

On 23 June 2012 11:52, Floris Bruynooghe  wrote:
> On 22 June 2012 17:56, Donald Stufft  wrote:
>> On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
>>
>> Key distribution is the real issue though. If there isn't a key
>> distribution infrastructure in place, we might as well not bother with
>> signatures. PyPI could issue x509 certs to packagers. You wouldn't be
>> able to verify that the name given is accurate, but you would be able
>> to verify that all packages with the same listed author are actually
>> by that author.
>>
>> I've been sketching out ideas for key distribution, but it's very much
>> a chicken and egg problem, very few people sign their packages (because
>> nothing uses it currently), and nobody is motivated to work on
>> infrastructure
>> or tooling because no one signs their packages.
>
>
> I'm surprised gpg hasn't been mentioned here.  I think these are all
> solved problems, most free software that is signed signs it with the
> gpg key of the author.  In that case all that is needed is that the
> cheeseshop allows the uploading of the signature.  As for key
> distribution, the keyservers take care of that just fine and we'd
> probably see more and better attended signing parties at python
> conferences.
>
> Regards,
> Floris



-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SPARC testers (and buildbot!) needed

[Floris Bruynooghe]

On 8 August 2012 18:56, Antoine Pitrou  wrote:
> Le 08/08/2012 15:25, "Martin v. Löwis" a écrit :
>
>>
>> Of course, when somebody has access to SPARC hardware, *and* they
>> have some interest that Python 3.3 works on it, they should test it.
>> But testing it as a favor to the community is IMO irrelevant now;
>> that particular community is shrinking rapidly.
>>
>> What I personally really never cared about is SparcLinux;
>> if sparc, then it ought to be Solaris.
>
>
> What Martin said; SPARC under Linux is probably a hobbyist platform.
> Enterprise users of Solaris SPARC systems can still volunteer to provide and
> maintain a buildslave.


Is http://wiki.python.org/moin/BuildBot the relevant documentation?
It still seems to refer to subversion, I presume that is no longer
needed and just mercurial will do?  I've set up a blank solaris 10
zone on a sparc T1000 with the OpenCSW toolchain (gcc 4.6.3) on our
server and installed buildslave.  According to the instructions this
is the point where I ask for a slave name and password.


Also, would it make sense to support OpenCSW more out of the box?
Currently we carry some patches for setup.py in order to pick up e.g.
sqlite from /opt/csw etc.  Would there be an interest in supporting
this?


Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SPARC testers (and buildbot!) needed

[Floris Bruynooghe]

On 9 August 2012 08:22, "Martin v. Löwis"  wrote:
> Am 09.08.12 01:26, schrieb Floris Bruynooghe:
>
>> According to the instructions this
>> is the point where I ask for a slave name and password.
>
>
> Sent in a private message.

Thanks, it seems to be working fine.  I triggered a build for 27 and
3.x.  I'm assuming other builds will just be triggered automatically
when needed from now on?

>> Also, would it make sense to support OpenCSW more out of the box?
>> Currently we carry some patches for setup.py in order to pick up e.g.
>> sqlite from /opt/csw etc.  Would there be an interest in supporting
>> this?
>
> If all that needs to be done is to add /opt/csw into search lists
> where a search list already exists, I see no problem doing so - except
> that this could be considered a new feature, so it might be only
> possible to do it for 3.4.

It is for 2.x, setup.py seems to have changed substantially in 3.x and
I haven't built that yet with OpenCSW but I presume I just need to
find the right place there too.  I'll open an issue for it instead of
discussing it here.


Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SPARC testers (and buildbot!) needed

[Floris Bruynooghe]

On 9 August 2012 08:11, Antoine Pitrou  wrote:
> Le 09/08/2012 01:26, Floris Bruynooghe a écrit :
>> Also, would it make sense to support OpenCSW more out of the box?
>> Currently we carry some patches for setup.py in order to pick up e.g.
>> sqlite from /opt/csw etc.  Would there be an interest in supporting
>> this?
>
> I don't know, what is OpenCSW?
> I think the answer also depends on the complexity of said patches.

OpenCSW is a community effort (CSW == Community SoftWare) to build a
repository of GNU/Linux userland binaries for Solaris.  It makes
package management as simple as on GNU/Linux, e.g.: "pkgutil --install
wget gcc4core libsqlite3_dev" which would otherwise be a very long and
laborious exercise.  It is very well maintained and I consider it a
must for any Solaris box which isn't tightly locked down.

As said in my other mail the patches are rather trivial but I will
open an issue to discuss there.

Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SPARC testers (and buildbot!) needed

[Floris Bruynooghe]

Hi,

On 8 August 2012 11:30, Stefan Krah  wrote:
> Could someone with access to a SPARC machine (perhaps with a modern version
> of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
> the test suite?

One more thing that might be interesting, the OpenCSW project provides
access to their build farm to upstream maintainers.  They say
various/all versions of solaris are available and compilers etc are
already setup, but I have never tried this out.  In case someone is
interested in this, see
http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/

Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SPARC testers (and buildbot!) needed

[Floris Bruynooghe]

On 10 August 2012 06:48, "Martin v. Löwis"  wrote:
> Actually, there appears to be a glitch in the network setup: it appears
> that connections to localhost are not possible in your zone. The tests
> fail with an assertion
>
> self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
> AssertionError: 128 != 146
>
> where 128 is ENETUNREACH. It would be good if localhost was reachable
> on a build slave.

The localhost network seems fine, which is shown by the test_socket
test just before.  I think the issue here is that
socket.create_connection iterates over the result of
socket.getaddrinfo('localhost', port, 0, SOCK_STREAM) which returns
[(2, 2, 0, '', ('127.0.0.1', 0)), (26, 2, 0, '', ('::1', 0, 0, 0))] on
this host.

The first result is tried and returns ECONNREFUSED but then the second
address is tried and this returns ENETUNREACH because this host has
not IPv6 network configured.  And create_connection() raises the last
exception it received.

If getaddrinfo() is called with the AI_ADDRCONFIG flag then it will
only return the IPv4 version of localhost.

I've created an issue to track this: http://bugs.python.org/issue15617


> Also, if you haven't done so, please make sure that the build slave
> restarts when the zone or the machine is restarted. Don't worry that
> restarting will abort builds in progress - that happens from time
> to time on any slave.

I'll check this, thanks for the reminder.


Regards,
Floris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] s/hotshot/lsprof

[Floris Bruynooghe]

Hello

On Mon, Nov 21, 2005 at 12:14:30PM +0100, Armin Rigo wrote:
> On Sun, Nov 20, 2005 at 08:55:49PM -0500, Tim Peters wrote:
> > We should note that hotshot didn't intend to reduce total time
> > overhead.  What it's aiming at here is to be less disruptive (than
> > profile.py) to the code being profiled _while_ that code is running. 
> 
> > hotshot tries to stick with tiny little C functions that pack away a
> > tiny amount of data each time, and avoid memory alloc/dealloc, to try
> > to minimize this disruption.  It looked like it was making real
> > progress on this at one time ;-)
> 
> I see the point.  I suppose that we can discuss if hotshot is really
> nicer on the D cache, as it produces a constant stream of data, whereas
> classical profilers like lsprof would in the common case only update a
> few counters in existing data structures.  I can tweak lsprof a bit
> more, though -- there is a malloc on each call, but it could be avoided.
> 
> Still, people generally agree that profile.py, while taking a longer
> time overall, gives more meaningful results than hotshot.

When I looked into this at the beginning of the summer I could find
none around on the net.  And since hotshot had been around a lot
longer then the new lsprof I just made a conservative choice.

> Now Brett's
> student, Floris, extended hotshot to allow custom timers.  This is
> essential, because it enables testing.  The timing parts of hotshot were
> not tested previously.

Don't be too enthousiastic here.  My aim was to replicate the profile
module and thus I needed to hack this into hotshot.  However I feel
like it is not entirely in hotshot's ideals to do this.  The problem
is that the call to the timing function is accounted to the code that
is being profiled afaik.  Since a generic timer interface was needed
this means that the call goes out from the C code back to Python and
back to whatever-the-timing-function-is-writtin-in.  Thus wrongly
accounting even more time to the profiled code (not sure how long
execing a python statement takes from a C module).  Just keep this in
mind.

> Given the high correlation between untestedness and brokenness, you bet
> that Floris' adapted test_profile for hotshot gives wrong numbers.  (My
> guess is that Floris overlooked that test_profile was an output test, so
> he didn't compare the resulting numbers with the expected ones.)

Iirc I did compare the output of test_profile between profile and my
wrapper.  This was one of my checks to make sure it was wrapped
correctly.  So could you tell me how they are different?

On a stdlib note, one recommended and good working profiler would
definitely be better then two or three all with their own quirks.


Greetings
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] s/hotshot/lsprof

[Floris Bruynooghe]

On Mon, Nov 21, 2005 at 12:14:26PM +0100, Armin Rigo wrote:
> Hi Brett, hi Floris,
> 
> On Sat, Nov 19, 2005 at 04:12:28PM -0800, Brett Cannon wrote:
> > Just  for everyone's FYI while we are talking about profilers, Floris
> > Bruynooghe (who I am cc'ing on this so he can contribute to the
> > conversation), for Google's Summer of Code, wrote a replacement for
> > 'profile' that uses Hotshot directly.  Thanks to his direct use of
> > Hotshot and rewrite of pstats it loads Hotshot data 30% faster and
> > also alleviates keeping 'profile' around and its slightly questionable
> > license.
> 
> Thanks for the note!  30% faster than an incredibly long time is still
> quite long, but that's an improvment, I suppose.

It is indeed still a long time.  But is was more of a secondary aim
really.

>  However, this code is
> not ready yet.  For example the new loader gives wrong results in the
> presence of recursive function calls.

Afaik I did test recursive calls etc.  I must admit that I don't think
anyone else appart form me tested it, which is far from ideal and thus
it is bound to still have bugs.

Could you provide a test case for this?

Cheers
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com