At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's "Deferred" API has nothing to do with I/O.
___
Python-Dev mailing list
Python-Dev@pyth
At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote:
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby wrote:
> I'm somewhat concerned that, as described, the proposed API ...
[creates] yet another alternative (and
> mutually incompatible) event loop system in the stdlib ...
Futures are
At 01:03 AM 3/5/2010, Brian Quinlan wrote:
Hi all,
I recently submitted a daft PEP for a package designed to make it
easier to execute Python functions asynchronously using threads and
processes. It lets the user focus on their computational problem
without having to build explicit thread/proces
At 08:57 PM 12/30/2008 -0600, s...@pobox.com wrote:
Phillip> At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote:
>> More trouble with the "just take the dirname":
>>
>> paths = ['/a/b/c', '/a/b/d', '/a/b']
>> os.path.dirname(os.path.commonprefix([
>> os.path.normpath
At 09:30 PM 12/30/2008 -0500, rdmur...@bitdance.com wrote:
On Tue, 30 Dec 2008 at 17:51, Phillip J. Eby wrote:
At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote:
More trouble with the "just take the dirname":
paths = ['/a/b/c', '/a/b/d'
At 02:32 PM 12/30/2008 -0800, Scott David Daniels wrote:
More trouble with the "just take the dirname":
paths = ['/a/b/c', '/a/b/d', '/a/b']
os.path.dirname(os.path.commonprefix([
os.path.normpath(p) for p in paths]))
give '/a', not '/a/b'.
...because that's th
At 06:14 AM 12/30/2008 -0600, s...@pobox.com wrote:
Paul demonstrates the shortcoming of commonprefix:
>>> os.path.commonprefix(["foo\\bar\\baz", "foo/bar/boink"])
'foo'
With the patch in issue4755:
>>> import ntpath
>>> ntpath.commonpathprefix(["foo\\bar\\baz", "foo/bar/boink
You know, all this path separator and list complication isn't really
necessary, when you can just take the os.path.dirname() of the return
from commonprefix().
Perhaps we could just add that recommendation to the docs?
At 04:46 PM 12/29/2008 -0600, s...@pobox.com wrote:
Jeff> For those
At 04:00 PM 12/23/2008 +, Paul Moore wrote:
PPS Seriously, setuptools and the adoptions of eggs has pushed a lot
of code to be much more careful about unwarranted assumptions that
code lives in the filesystem. That's an incredibly good thing, and
very hard to do right (witness the setuptools
At 06:55 AM 12/23/2008 -0500, Rocky Bernstein wrote:
Now that there is a package mechanism (are package mechanisms?) like
zipimporter that bundle source code into a single file, should the
notion of a "file" location should be adjusted to include the package
and/or importer?
Is there a standard
At 07:50 AM 10/25/2008 -0400, A.M. Kuchling wrote:
On Sat, Oct 25, 2008 at 04:33:23PM +1300, Greg Ewing wrote:
> Maybe not, but at least you can follow what it's doing
> just by knowing C. Introducing vmgen would introduce another
> layer for the reader to learn about.
A stray thought: does usin
At 10:47 AM 10/24/2008 +0200, J. Sievers wrote:
- Right now, CPython's bytecode is translated to direct threaded code
lazily (when a code object is first evaluated). This would have to
be merged into compile.c in some way plus some assorted minor changes.
Don't you mean codeobject.c? I don'
At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote:
On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I created a "universal metaclass" in
> DecoratorTools whose sole function is to delegate metaclass __new__,
> __init__, and __call__ to
At 05:50 PM 8/28/2008 +0200, Michele Simionato wrote:
On Aug 28, 5:30 pm, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> How is that making things easier for application programmers?
We have different definitions of "application programmer". For me a typical
appli
At 06:35 AM 8/28/2008 +0200, Michele Simionato wrote:
Multiple inheritance of metaclasses is perhaps
the strongest use case for multiple inheritance, but is it strong
enough? I mean, in real code how many times did I need that?
I would not mind make life harder for gurus and simpler for
applicati
At 03:16 AM 8/27/2008 +0200, Michele Simionato wrote:
It is just a matter of how rare the use cases really are. Cooperative
methods has been introduced 6+ years ago. In all this time surely
they must have been used. How many compelling uses of cooperation
we can find in real life code? For instan
At 12:56 AM 7/25/2008 +1000, Thomas Lee wrote:
I'm making some good progress with the AST optimizer, and now the
main thing standing in my way is lnotab. Currently lnotab expects
bytecode sequencing to be roughly in-sync with the order of the
source file and a few things that the optimizer does
At 11:27 AM 7/17/2008 -0700, Brett Cannon wrote:
On Thu, Jul 17, 2008 at 10:54 AM, ranjith kannikara
<[EMAIL PROTECTED]> wrote:
> I have taken the gsoc 08 project of porting zope2 to python2.5.
> Through my way to the successful completion of the project I have to
> implement Restricted python i
At 04:54 AM 6/19/2008 -0700, C. Titus Brown wrote:
More generally, I've never understood why some people insist that
certain features make Ruby better for DSLs -- are code blocks really
that important to DSLs? Or is it just the lack of parens??
Comparison to JavaScript suggests that it's the b
At 02:34 PM 6/15/2008 +, Antoine Pitrou wrote:
Phillip J. Eby telecommunity.com> writes:
>
> As for the other uses for ordered dictionaries, I find it simplest to
> just use a list of key,value pairs, and only transform it to a
> dictionary or dictionary-like structure a
At 02:19 PM 6/15/2008 +, Antoine Pitrou wrote:
> Ordered dicts, dicts that remember the chronological order of their
> insertion, don't sound generally useful.
They are generally useful in any case where you want to handle key-value
pairs while not confusing a human operator by messing up th
At 08:19 AM 6/14/2008 +0200, Cesare Di Mauro wrote:
Assignament must work on the object's namespace, of course:
def foo(a):
on a:
x += 1
print x
will be equivalent to:
def foo(a):
a.x += 1
print a.x
Er, you need a syntactic disambiguation here to distinguish
attributes fr
At 12:46 PM 6/12/2008 -0700, Guido van Rossum wrote:
The intention was for these dicts to be used as namespaces.
By "these" do you mean type object __dict__ attributes, or *all*
__dict__ attributes?
___
Python-Dev mailing list
Python-Dev@python.org
At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote:
Phillip J. Eby wrote:
> As it happens, most objects' __dict__ slots are settable by default, and
> *require* that you set it to a dict or subclass thereof.
This is wrong for types:
Which is why I said "most" -
At 02:59 AM 6/12/2008 +0200, Maciej Fijalkowski wrote:
It's about abusing locals, which are not even given that they'll
modify this dict.
Note that class bodies are a special case: as of PEP 3115, it's
possible for a class body's locals to be a non-dictionary object, so
it makes no sense to m
At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
The Data Model chapter of the Reference Manual lists .__dict__ as a special
attribute of callables, modules, classes, and instances. It describes
__dict__ as a "namespace dictionary" or "implementation of the namespace"
thereof. Since namespaces m
At 03:37 AM 6/11/2008 +0200, Maciej Fijalkowski wrote:
On Wed, Jun 11, 2008 at 3:36 AM, Scott Dial
<[EMAIL PROTECTED]> wrote:
> Maciej Fijalkowski wrote:
>>
>> What do you think about this code:
>>
>> class A:
>> locals()[42] = 98
>>
>> Seems people rely on it working.
>
> I apologize for my ig
At 12:19 PM 5/15/2008 +1200, Greg Ewing wrote:
Andrew McNabb wrote:
If it made people feel better, maybe it should be called threading2
instead of multiprocessing.
I think that errs in the other direction, making it sound
like just another way of doing single-process threading,
which it's not
At 04:38 PM 5/1/2008 -0300, Facundo Batista wrote:
Has super() proved more useful than harmful?
For me, yes. I use it all the time. The only time I use
explicit-target upcalls is in __init__ methods, and there usually
only to skip a subclass' init or to explicitly manage a tricky bit of
mu
At 06:48 AM 4/23/2008 -0400, Neal Becker wrote:
Neal Becker wrote:
> pydoc blew up when I tried to view doc for pytools module, which is an
> egg:
>
> pydoc -p 8082
> pydoc server ready at http://localhost:8082/
>
...
>
I see that installing the egg unzip
At 12:12 AM 4/10/2008 -0700, Stephen Hansen wrote:
>I think PJE's idea here is very good. Just include certain files and
>such in the RPM/DEB that will satisfy the
>"python-package-management" system. For RPM/DEB users and their OS's
>database of packages, its irrelevant largely-- they'll still
At 12:51 AM 4/10/2008 +0200, Gael Varoquaux wrote:
>On Wed, Apr 09, 2008 at 11:46:19PM +0100, Paul Moore wrote:
> > I find this whole discussion hugely confusing, because a lot of people
> > are stating opinions about environments which it seems they don't use,
> > or know much about. I don't know
At 11:48 PM 4/9/2008 +0100, Paul Moore wrote:
>On 09/04/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > It would be, if .eggs were a packaging format, rather than a binary
> > distribution/runtime format.
> >
> > Remember "eggs are to Python as jars ar
At 03:20 PM 4/9/2008 -0700, zooko wrote:
>I've opened a ticket on my setuptools trac about this proposal:
>
>http://allmydata.org/trac/setuptools/ticket/5 # binary eggs should
>come with .py files by default, rather than .pyc files
Filling your tracker with already-rejected proposals isn't likely
At 04:43 PM 4/9/2008 -0400, Stanley A. Klein wrote:
>I don't understand what you mean by "shared environments and development
> environments".
I mean that in a shared or development environment, a system packager
isn't useful, since it expects things to live in *one* place, and
usually to have
At 12:30 PM 4/9/2008 -0700, zooko wrote:
>On Apr 8, 2008, at 4:36 PM, Greg Ewing wrote:
> >
> > I discovered another annoyance with eggs the other day -- it
> > seems that tracebacks referring to egg-resident files contain the
> > pathname of some temporary directory that existed when the egg
> >
At 10:30 AM 4/9/2008 -0700, zooko wrote:
>PEP 262 sounds like a non-starter to me because
>
>1. It appears to be backwards-incompatible with setuptools/
>easy_install/eggs, thus losing all the recently gained cooperation
>that I mentioned in the previous paragraph, and
No. It provides a forward
At 11:52 AM 4/9/2008 -0400, Stanley A. Klein wrote:
>However, are you implying that the installation information for Python egg
>packages accesses and coordinates with the rpm database?
Yes, when the information isn't stripped out. Try a more recent Fedora.
>IMHO, the main system without a pack
At 10:00 AM 4/9/2008 +0200, Gael Varoquaux wrote:
>On Wed, Apr 09, 2008 at 12:41:32AM -0400, Phillip J. Eby wrote:
> > >The way to achieve a database for Python would be to provide tools for
> > >conversion of eggs to rpms and debs,
>
> > Such tools already exist,
At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote:
>On Tue, April 8, 2008 9:37 pm, Ben Finney
><[EMAIL PROTECTED]> wrote:
> > Date: Wed, 09 Apr 2008 11:37:07 +1000
> > From: Ben Finney <[EMAIL PROTECTED]>
> > Subject: Re: [Distutils] how to easily consume just the parts of eggs
> > thata
At 10:01 AM 4/8/2008 -0700, zooko wrote:
>On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
> > zooko wrote:
>
>http://mail.python.org/pipermail/python-dev/2008-March/078243.html
>
> >> Here is a simple proposal: make the standard Python "import"
> >> mechanism notice eggs on the PYTHONPATH and
At 10:43 PM 3/22/2008 +, Antoine Pitrou wrote:
>- Why are there both relative and absolute jump instructions? The traditional
>rationale for relative jumps (apart from position-independent code)
>is to allow
>for shorter operand sizes; but Python opcodes all have the same operand size
Actuall
At 04:29 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>>For those without the read-only flag, the specification should
>>>explicitly say what manipulation is allowed.
>>Since a distribution isn't really "mutable", I would think that
>>uninstallation and reinstallation would be the only manipulation
At 11:19 AM 3/22/2008 -0400, Phillip J. Eby wrote:
>Not exactly. More like, "package management tool X claims exclusive
>rights to this package". Python tools would always defer this right
>to the system packager, i.e. a system packager is not obliged to
>respect a Python
At 02:14 PM 3/22/2008 +, Paul Moore wrote:
>For the system Python, I need:
>- a single way to list what's installed (including version)
>- a single way to uninstall items as needed
>- a way (or more than one) to install 3rd party software *which ties
>into the above*
Right, and the PEP effort
At 12:33 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>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
At 11:00 AM 3/22/2008 +, Floris Bruynooghe wrote:
>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).
.egg-info/PKG-INFO don't lis
At 09:44 PM 3/21/2008 -0400, A.M. Kuchling wrote:
>On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
> > I'm making the assumption that the author(s) of PEP 262 had good
> > reason for including what they did, rather than assuming that we
> > should start th
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
>>I'm making the assumption that the author(s) of PEP 262 had good
>>reason for including what they did, rather than assuming that we
>>should start the entire process over from scratch.
>
>The objections to the PEP remain the same as they were
At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>On 2008-03-21 22:21, Phillip J. Eby wrote:
> > At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
> >> I guess the only way to support all of these variants is
> >> to use a filesystem based approach, e.g. by placing
At 05:59 PM 3/21/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby schrieb:
> > Questions, comments... volunteers? :)
>
>I've yet to read the monster package utils thread so I can't comment on
>it. However I like to draw some attention to my PEP 370
>http://pyth
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>I guess the only way to support all of these variants is
>to use a filesystem based approach, e.g. by placing a file
>with a special extension into some dir on sys.path.
>The "database" logic could then scan sys.path for these
>files, read the data
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
> Joachim> files (and 'rmdir' directories, but not recursively) that it
> Joachim> created, and that have not been modified in the meantime (after
> Joachi
At 09:53 AM 3/21/2008 -0600, zooko wrote:
>Um, isn't this tool called "unzip"? I have done this -- accessed the
>source code -- many times, and unzip suffices.
>
>I don't know what else would be required in order to make an egg into
>"a standard distutils-style installation".
You also have to ren
So, after having some time to absorb the Python-Dev threads about
setuptools, bootstrap, and all the rest, I think I see an opportunity
to let people route around the "damage" of eggs, while still making
it possible for the people who want to use easy_install or to put
dependencies in their set
At 12:33 PM 3/21/2008 +, Paul Moore wrote:
>On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > The standard (and to me, preferable) way of dealing with such
> things is to
> > have an 'installation manager' that can reinstall as well as delete and
> > that has a check box for variou
At 10:08 PM 3/20/2008 +, [EMAIL PROTECTED] wrote (off-list):
>No, but in no situation, except one (where I was extremely pressed
>for time) was I actually attempting to use setuptools to use any of
>its features. My experience of it is: "If a project uses distutils
>or apt, installation pro
At 08:34 PM 3/20/2008 +, Paul Moore wrote:
>I then went on to say that putting dependency information in setup.exe
>and expecting users to use automatic dependency resolution encourages
>developers to omit dependency details from documentation (to an extent
>I can't quantify, but I believe is n
At 05:55 PM 3/20/2008 +, Paul Moore wrote:
>It's not that I object to the existence of automatic dependency
>management, I object to being given no choice, as if my preference for
>handling things manually is unacceptable.
Note that easy_install has a --no-deps option, and you can make it
the
I just wanted to throw in a quick note that this package:
http://pypi.python.org/pypi/autoinstall
which was just uploaded by Daniel Krech, is a lot closer in spirit to
what I was trying to accomplish with PEP 365 than Guido's bootstrap
proposal. Perhaps there's room for both in the stdlib? (A
At 09:44 AM 3/20/2008 -0400, Tres Seaver wrote:
>I don't know how to make this requirement compatible with using shared
>dependencies, except to make it easier for folks to download *all* the
>requirements, and later install from the local "distribution cache" (a
>directory full of .zip / .egg / .t
At 09:33 AM 3/20/2008 +, Paul Moore wrote:
>1. No integration with the system packager (Windows, in my case). If I
>do easy_install nose, then nose does not show up in add/remove
>programs. That significantly affects the way I manage my PC.
The long-term fix here is probably to have a platform
At 10:18 PM 3/19/2008 -0600, zooko wrote:
>The fact that easy_install creates a site.py that changes the
>semantics of PYTHONPATH is probably the most widely and deservedly
>hated example of this kind of thing [2].
Yep, this was an unfortunate side effect of eggs growing outside
their original ec
At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote:
>A lot of setuptools warts are driven by related design problems in the
>distutils, such as the choice to use imperative / procedural code for
>everything: a declarative approach, with hooks for cases which actually
>need them (likely 5% of existing
At 05:15 PM 3/19/2008 -0500, Jeff Rush wrote:
>Phillip J. Eby wrote:
> > At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
> >> Are you open to giving certain others patch view/commit privileges to
> >> setuptools?
> >
> > Jim Fulton has such already. I'm o
At 10:48 AM 3/19/2008 -0700, Guido van Rossum wrote:
>I don't understand PyPI all that well; it seems poor design that the
>browsing via keywords is emphasized but there is no easy way to
>*search* for a keyword (the list of all packages is not emphasized
>enough on the main page -- it occurs in th
At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
>Are you open to giving certain others patch view/commit privileges
>to setuptools?
Jim Fulton has such already. I'm open to extending that to others
who have a good grasp of the subtleties involved.
Truthfully, if we can just get 0.6 put to bed, I
We should probably move this off of Python-Dev, as we're getting into
deep details now...
At 07:27 PM 3/18/2008 -0500, Dave Peterson wrote:
>If you really wanted to do a full-tree intersection, it seems to me
>that the problem is detecting all the dependencies without having to
>spend significa
At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote:
>Only very few people would care about writing a setup
>script that works with this bootstrap module; basically only package
>manager implementers.
That's true today, sure, but as soon as it is widely available,
others are sure to want to use i
At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote:
>I am hoping that someone will create a simpler bootstrap module that
>is able to download a file of pure Python code and install it, perhaps
>by running its setup.py, assuming that it only depends on distutils
>(or other things previously instal
At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote:
>I was in a Packaging BoF yesterday and, although not very relevant to the
>packager bootstrap thread, Guido has asked me to post some of the concerns.
>
>The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu
>and such. Everyone
At 02:44 PM 3/17/2008 -0500, Jeff Rush wrote:
>Guido van Rossum wrote:
> > On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> >>
> >> I'm +lots on someone giving a clear explanation of the meaning and
> >> interrelationship of the various terms involved in this discussion
>
At 01:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>I have certainly personally encountered plenty of situations where I
>wasn't able to complete an egg-based install because some dependency
>was broken (e.g. not available for the Python version I was using).
That's odd -- setuptools-based insta
At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby
><[EMAIL PROTECTED]> wrote:
> > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> > >There will be no egg support in the standard library.
> >
> >
At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
>There will be no egg support in the standard library.
Are there any qualifications on that statement, or is this in the
same category as "from __future__ import braces"?
___
Python-Dev mailing list
At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>I don't think this should play games with scripts being overridden or
>whatever. If a bootstrap script is to be installed it should have a
>separate name. I'm not sure what the advantage is of a bootstrap
>script over "python -m bootstrap_module
At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote:
> > Well, it might be replaced by a protracted discussion of how the
> > module should work and what its API should be, but perhaps that would
> > be a better one to have. :)
>
>Indeed, that's likely to happen :-)
>
> > So, the original proposal
At 08:48 AM 3/17/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > So, if the consensus is that it would be better to have a module that
> > only does bootstrap installs of pure-Python eggs from PyPI, I
Quick summary of the below: I'm definitely fine with doing a simpler,
pure-bootstrap module, if there's some consensus on what should go in
it. I just wish we could've had this discussion last year, when OSAF
was still able to fund the work... ;-)
At 06:13 PM 3/16/2008 -0500, Guido van Rossu
At 12:26 PM 3/10/2008 +0100, Armin Rigo wrote:
>Hi Phillip,
>
>On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> > I did not, however, need the equality of bound methods to be based on
> > object value equality, just value identity.
> >
> > ...at le
At 01:59 PM 3/9/2008 -0800, Guido van Rossum wrote:
>Do we have much of a use case for this?
I've often had APIs that take a callback that promise to only invoke
the callback once, even if it's added more than once. And I've used
dicts, lists, and sets for same.
I did not, however, need the eq
At 05:40 PM 3/4/2008 +0300, Oleg Broytmann wrote:
>On Wed, Mar 05, 2008 at 12:14:04AM +1000, Nick Coghlan wrote:
> > As a more helpful answer, the ZIP spec allows additional data to be
> > included in the file before the ZIP header. A more common way of using
> > this is to add a zip file on to the
At 05:05 PM 1/26/2008 -0800, Neal Norwitz wrote:
>Around Jan 13, the refleak hunting test that is reported on
>python-checkins started to report refleaks on virtually every run. I
>suspect this is due to r59944 (at 2008-01-13 16:29:41) which was from
>patch #1700288 to cache methods. With this pa
At 04:42 PM 1/22/2008 +0100, M.-A. Lemburg wrote:
>I don't really understand what all this has to do with per user
>site-packages.
>
>Note that the motivation for having per user site-packages
>was to:
>
> * address a common request by Python extension package users,
>
> * get rid off the hackery
At 10:48 AM 1/21/2008 -0500, Steve Holden wrote:
>Phillip J. Eby wrote:
> > (Heck, if what you really want is to have easy_install support in
> > 2.6, we could just as easily bundle an easy_install.py that asks for
> > an install of setuptools if it's not already presen
At 01:06 AM 1/22/2008 +1000, Nick Coghlan wrote:
>Steve Holden wrote:
> > Christian Heimes wrote:
> >> Steve Holden wrote:
> >>> Maybe once we get easy_install as a part of the core (so there's no need
> >>> to find and run ez_setup.py to start with) things will start to improve.
> >>> This is an i
At 04:40 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > I guess it's not right then. ;-) Though I shouldn't make fun, since it
> > turns out that my code sketch was not a correct translation of
> > peak.util.imports. (See below.)
>
&
At 02:28 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
> >> My code queues up new hooks while a sequence of hooks is processed. It
> >> makes sure that hooks for a parent aren't called
At 02:19 PM 1/15/2008 -0800, Guido van Rossum wrote:
>While I have you, I've come across a need that I don't know how to do
>with GFs. Suppose I have a GF that implements some recursive function
>over container types, e.g. serialization or flattening. Now suppose
>I'd like to create *another* GF th
At 01:51 PM 1/15/2008 -0800, Guido van Rossum wrote:
>On Jan 15, 2008 1:27 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Second, a "metaclass" to add a number of methods (or other attributes)
> > > to an existing class, using a convenient class notation:
> >
> > I think this is similar to
At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
>My code queues up new hooks while a sequence of hooks is processed. It
>makes sure that hooks for a parent aren't called in the middle of a
>child's hook chain.
Notice that that's not necessary with the notification algorithm I
gave, since the
At 10:10 PM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > *sigh*. We seem to be getting further and further off course,
> > here. The more different you make the semantics of the system, the
> > harder it will be to verify that it's doing the righ
At 12:08 AM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > Yes, that's the general idea. But what happens if you are in the middle
> > of firing hooks for 'a', and a new hook for 'a.b.c' is added? What
> > about a new hook for &
At 01:47 AM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote:
> >> In my version a hook is immediately called when the the registry value
> >> is set to None. When a hook is registered for a module d
At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote:
>In my version a hook is immediately called when the the registry value
>is set to None. When a hook is registered for a module during the
>execution of the callback then the hook is fired directly and not after
>the existing hooks are called. Is
At 09:40 PM 1/10/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
>[...]
>
> > There's also one twist that I haven't sorted out yet: "Importing"
> > guarantees that a parent module 'foo' will have a 'bar' attribute for
>
At 10:47 AM 1/10/2008 +, Paul Moore wrote:
>On 09/01/2008, Steve Holden <[EMAIL PROTECTED]> wrote:
> > The idea that users would /program their own computers/ was totally
> > alien to the Windows mindset.
>
>Actually, the alien idea is that more than one person would use the
>same (Windows) com
At 07:22 PM 1/10/2008 +1000, Nick Coghlan wrote:
>Christian Heimes wrote:
> > A module is successfully loaded
> > '''
> >
> > The import machinery checks if sys.post_import_hooks contains post import
> > hooks for the newly loaded module. If hooks are found then the hook
At 03:20 AM 1/10/2008 +0100, Christian Heimes wrote:
>PyObject* PyImport_NotifyModuleLoaded(PyObject *module)
>Notify the post import system that a module was requested. Returns the
>module or NULL if an error has occured.
The big problem here is that the interaction with laziness is
actu
At 09:20 PM 1/9/2008 +0100, Christian Heimes wrote:
>Brett Cannon wrote:
> > I agree with Nick and Nick. This should really be two separate PEPs.
>
>I'm fine with the proposal and I'm going to chop the PEP in two parts
>tonight.
>
>Somehow I suspect that the lazy import PEP will be postponed or re
1 - 100 of 1027 matches
Mail list logo
