At 12:38 PM 9/9/2008 -0700, Brett Cannon wrote:
On Tue, Sep 9, 2008 at 10:06 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:28 PM 9/6/2008 -0700, Brett Cannon wrote:
>>
>> On Sat, Sep 6, 2008 at 2:06 PM, <[EMAIL PROTECTED]> wrote:
>> > I'm
At 03:28 PM 9/6/2008 -0700, Brett Cannon wrote:
On Sat, Sep 6, 2008 at 2:06 PM, <[EMAIL PROTECTED]> wrote:
> I'm trying to figure out how to install this dbm.sqlite module I have
> without overwriting the basic install. My thought was to create a dbm
> package in site-packages then copy sqlite.
At 02:49 PM 3/16/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 1:31 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Btw, would you mind pronouncing (or at least commenting) on PEP 365,
> > so that I can proceed with the work -- or not.
>
>Can you p
At 12:55 PM 3/16/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 12:48 PM, Phillip J. Eby
><[EMAIL PROTECTED]> wrote:
> > At 10:00 AM 3/16/2008 -0500, Guido van Rossum wrote:
> > >(a) *if* we're going to do this, it should also be done for func
At 10:00 AM 3/16/2008 -0500, Guido van Rossum wrote:
>(a) *if* we're going to do this, it should also be done for function
>calls (though not for function defs). I'd like all of these to be
>legal (and their interpretation is obvious):
>
> f(a, b, *x, k=val)
> f(a, *x, b, k=val)
> f(*x, a, b,
At 06:51 PM 3/15/2008 -0700, Talin wrote:
>Now, one final comment: PEP 342 promises that the new yield semantics
>can be used to implement true coroutines. But I don't see how to
>actually make that work. Has anyone actually done this?
http://peak.telecommunity.com/DevCenter/TrellisActivity#co-ope
At 06:33 PM 3/15/2008 -0500, Michael Urman wrote:
> > > I'm not sure how to solve this except by adopting a different syntax
> > > for the multiple-yield. Perhaps
> > >
> > > *yield x
> >
> > If there really were an inconsistency here, I would certainly not suggest
> > fixing it that way, yuuueghh.
At 08:59 PM 3/6/2008 -0800, Guido van Rossum wrote:
>Would you mind giving an "executive summary" of your argument that
>doesn't require scanning 40 lines of code?
He's writing a variant of 'partial' that inserts an argument *after*
the 'self', if there is one, but doesn't rely on 'self' being ca
At 03:23 PM 2/17/2008 +0100, Christian Heimes wrote:
>Giovanni Bajo wrote:
> > Python's debug mode under Windows mandates an ABI change: the debug
> > version of dynamic libraries (_d) are linked against the CRT debug
> > runtime, which is not ABI-compatible to the release runtime. So you
> > eithe
At 09:29 AM 2/17/2008 +, Nick Craig-Wood wrote:
>On Fri, Feb 15, 2008 at 01:20:03PM -0800, Guido van Rossum wrote:
> > But maybe given how rare the use case is, it would be easier to just
> > create a custom class in weakref.py that does what Nick requested.
>
>I still don't like the silent fai
At 05:06 PM 2/16/2008 +, Giovanni Bajo wrote:
>BTW: is there a long-time plan to make the Python core *not* link
>against msvcrt dll anymore but only rely on Windows APIs (or maybe
>also the static C runtime, I don't really care)?
How would this affect using MinGW to build Python extensions?
At 11:41 AM 2/15/2008 -0800, Guido van Rossum wrote:
>On Fri, Feb 15, 2008 at 10:26 AM, Phillip J. Eby
><[EMAIL PROTECTED]> wrote:
> > I've never actually encountered a usecase for keeping a standard
> > weakref to a standard bound method, though. It's
At 09:35 AM 2/15/2008 -0800, Guido van Rossum wrote:
>On Fri, Feb 15, 2008 at 2:12 AM, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> > I've just been bitten yet again by the fact you can't have a weakref
> > to a bound method! I find myself wanting to do this whenever I have a
> > registry of cal
At 02:18 PM 2/15/2008 +0200, Niki Spahiev wrote:
>Phillip J. Eby wrote:
> > That's actually a separate problem from the one Paul and I are
> > talking about, one that I'm not even going to *try* to solve. (Being
> > as I already have, and failed miserably.) Hell
At 05:23 PM 2/11/2008 +1300, Greg Ewing wrote:
>Aahz wrote:
> > On Mon, Feb 11, 2008, Greg Ewing wrote:
> >
> >>There are bound to be things that you *don't* want to copy from
> >>the original order, e.g. the order ID, the date...
> >
> > Certainly -- that's why __copy__() exists, right?
>
>Yes, bu
At 11:46 PM 2/10/2008 +, Paul Moore wrote:
>If I want a copy of an arbitrary mapping (or any object) and I want to
>preserve type, I would use copy.copy(). This is just as polymorphic as
>a copy method (interesting that it is Phillip arguing for methods
>being the polymorphic choice, when copy.
At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote:
>I recommend dropping the dict.copy() method from Py3.0.
>
>* We can already write: newd = copy.copy(d).
>* We can also write: newd = dict(d)
>* Both of those approaches also work for most other containers.
I'm not fond of this idea. dict.
At 03:59 PM 2/8/2008 +1300, Greg Ewing wrote:
>Paul Moore wrote:
> > As Phillip says. Windows console and GUI executables are completely
> > different in behaviour. Don't try to fight it. You need two distinct
> > EXEs.
>
>Hmmm. So maybe what's needed is a *third* kind of exe that
>gets launched wh
At 09:52 AM 2/8/2008 +1300, Greg Ewing wrote:
>Would it be feasible for it to always start up as a gui
>app, and then create its own console window (a fake one
>if necessary) if it decides it needs one?
No, because that would make it impossible to write a sane
command-line app. Imagine if runnin
At 07:38 PM 2/6/2008 +0100, Christian Heimes wrote:
>The first line of the file is read and parsed. The line must start with
>a shebang (#!). Contrary to your script it doesn't look for a complete
>path but searches for pythonX.Y. "#!python2.5" or "#!/usr/bin/python2.5"
>both work.
>
>Then the laun
At 10:43 AM 2/5/2008 -0700, Adam Olsen wrote:
>So why don't we add a windows equivalent of the shebang? Files could
>then start like this:
>
>#!/usr/bin/python2.3
>#¡C:/python23/python
FYI, setuptools uses and supports #! lines on Windows, with the
executable path in quotes if it contains spaces
At 12:35 PM 1/13/2008 -0800, Charles Merriam wrote:
>Sigh.. Yes mix-ins are about mixing classes. No I didn't miss it.
Yes, you did miss it, and are still missing it.
Otherwise you'd know why your original proposal was never viable in
the first place, and why mixins have nothing to do with it.
At 10:55 AM 1/13/2008 -0800, Charles Merriam wrote:
>You have a legitimate counter-argument that grouping the
>implementations of __add__ in the metaclass is cleaner than having
>them stand alone and be referenced in.
You've misunderstood Michele's example code. __add__ in the
metaclass lets you
At 09:37 AM 1/13/2008 -0800, Charles Merriam wrote:
>Well, I'm explicitly dropping this. So far no one has pointed out
>any use cases that are not equivalent to intercepting an array of the
>namespace in the __init__() of a subclass of type, then calling
>type's __init__() on the modified namesp
At 06:50 PM 1/5/2008 -0500, Alexandre Vassalotti wrote:
>I currently trying to clean up the interface of the pickle module for
>Python 3K. So far, I haven't done much, except documenting parts the
>pickle stream format.
>
>There's still one thing I still don't understand about pickle,
>persistent_i
At 08:04 PM 12/22/2007 -0800, Charles Merriam wrote:
> >
> > Yes, several. You haven't been reading the previous discussion
> > threads, in which I've repeatedly posted other use cases for PEP
> > 3115, every time someone else who hasn't read the previous posting of
> > those use cases, and tries
At 10:30 PM 12/21/2007 -0800, Charles Merriam wrote:
>Are there any other use cases?
Yes, several. You haven't been reading the previous discussion
threads, in which I've repeatedly posted other use cases for PEP
3115, every time someone else who hasn't read the previous posting of
those use c
At 12:46 PM 12/15/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > Er, no, its functionality *isn't* replaced by subclassable dict,
> > since subclassable dict does stuff you can't override (e.g. copy()
> > doesn't return a subclass instance).
>
>
At 08:51 AM 12/14/2007 +0100, Christian Heimes wrote:
>UserDict is a relict from the
>past and scheduled for removal.
Really? Why?
>It's functionality is replaced by the
>subclass-able dict type and ABCs.
Er, no, its functionality *isn't* replaced by subclassable dict,
since subclassable dict
At 11:41 AM 12/10/2007 -0500, Jim Jewett wrote:
>Is there an example where you would use post-import hooks even though
>the system didn't support lazy import? The best I can come up with is
>"Don't import module X just for me, but *if* someone else imports it,
>then I want to do these things to/wi
At 12:37 PM 12/9/2007 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Lazy importing is putting a module object into sys.modules, but not
> > loading its contents until you attempt to get or set a module attribute.
>
>How is that expected to be useful? If you
At 10:49 PM 12/8/2007 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > Note that in my implementation, an entry is added to sys.modules
> > immediately, so this scenario can't happen without *replacing* the
> > sys.modules entry.
>
>I like to separate the i
At 10:32 PM 12/8/2007 +0100, Christian Heimes wrote:
>The pre import hook can probably be implemented in pure Python with a
>meta path hook as described in http://www.python.org/dev/peps/pep-0302/.
>I see the pre import hook as a lightweight meta path hook with an easy
>to use interface.
Which mea
At 09:55 PM 12/8/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > I'm far from convinced that a from-scratch rewrite (particularly in C)
> > is a great idea myself - that's why I suggested a PEP to look at some of
> > the issues.
>
>Yesterday I wrote down a quick survey of codes with so
At 03:56 PM 12/8/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> >> > Does anyone else think this is an issue worth pursuing?
> >
> > A qualified yes: the Importing package took a long time to get correct
> > under all the crazy little twists
At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote:
>I couldn't help myself. Such a beautiful thing had to be spread, and it
>was *easy* to put it in 3.0 because types are simpler. A patch is here:
>
> http://bugs.python.org/issue1568
>
>If users are going to be encouraged to subclass from the AB
At 12:33 PM 12/7/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > For example, to handle the commented out case above:
> >
> >@imp.imported('decimal')
> >def register(decimal):
> >Inexact.register(decimal.Decimal)
>
>I like the syntax assuming that imp.imported(name) exp
At 03:48 PM 12/3/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > Aren't the metaclass changes in PEP 3115 partially aimed at eliminating
> > the need for stack frame hackery to implement these kinds of things?
> > (e.g. the metaclass could stuff a closure into the class namespace under
At 10:18 PM 12/3/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > Well, for what class-level frame hacking is typically used for, it
> > would suffice to have a convenient way to refer to the local
> > namespace, e.g. if you could do something like:
> >
>
At 04:52 PM 11/30/2007 +, Paul Moore wrote:
>On 30/11/2007, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > >> class Example:
> > >>implements(IExample)
> >
> > This frame hacking is also a pretty common feature of other types of
> > systems, such as ORMs. It can make certain Python code much
At 12:04 PM 9/29/2007 -0700, Gregory P. Smith wrote:
>On 9/29/07, Jeffrey Yasskin
><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
>On 9/29/07, Phillip J. Eby
><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
> > At 07:33 AM 9/29/2007 -070
At 10:26 AM 9/29/2007 -0500, Michael Urman wrote:
>[Sending direct because this is just a thanks and some idea fodder,
>but feel free to return this to the list]
>
>On 9/29/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > can both be constants, a simple list.index(
At 07:33 AM 9/29/2007 -0700, Guido van Rossum wrote:
>Until just before 3.0a1, they were unequal. We decided to raise
>TypeError because we noticed many bugs in code that was doing things
>like
>
> data = f.read(4096)
> if data == "": break
Thought experiment: what if read() always returned st
At 08:08 PM 9/28/2007 -0700, Guido van Rossum wrote:
>Likely, programmers will attempt to look up keys
>that they know are in the dict -- and if they use the wrong type,
>because of the identical hash values, they will get the TypeError as
>soon as they compare it to the first object at the hashed
At 09:25 AM 9/19/2007 +1200, Greg Ewing wrote:
>Talin wrote:
> > the ultimate solution to Python concurrency won't be via patching
> > CPython, but to compile the meta-Python language to a back-end
> > representation that is inherently concurrent.
>
>You can't get something for nothing, though --
At 07:46 AM 8/2/2007 -0700, Guido van Rossum wrote:
>On 8/1/07, Talin <[EMAIL PROTECTED]> wrote:
> > I think that in order to 'mix' metaclasses, each metaclass needs to get
> > a crack at the members as they are defined. The 'dict' object really
> > isn't important - what's important is to be able
At 07:40 PM 7/31/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>In other words, a class' metaclass has to be a derivative of all
>>its bases' metaclasses; ISTM that a __prepare__ namespace needs to
>>be a derivative in some sense of all its bases' __
At 12:20 PM 7/27/2007 -0400, Phillip J. Eby wrote:
>At 08:25 AM 7/27/2007 -0700, Guido van Rossum wrote:
> >Basic GFs, great. Before/after/around, good. Other method
> >combinations, fine. But GFs in classes and subclassing? Not until we
> >have a much better design.
>
At 02:20 PM 7/30/2007 -0400, Jim Jewett wrote:
>On 7/21/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> >... If you have to use @somegeneric.before and
> > @somegeneric.after, you can't decide on your own to add
> > @somegeneric.debug.
>
> > However, i
At 08:25 AM 7/27/2007 -0700, Guido van Rossum wrote:
>Basic GFs, great. Before/after/around, good. Other method
>combinations, fine. But GFs in classes and subclassing? Not until we
>have a much better design.
Sounds reasonable to me. The only time I actually use them in
classes myself is to ove
y of overloads
>can be found adjacent to..." sounds like it isn't a big loss to
>require explicit decoration.
Perhaps these two bits should have been closer together, then:
>On 7/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>The principal reasons to exten
Taking the recent threads here, and Guido's comments off-list, I've
attempted to put together a coherent response as a new section for
the PEP, which I've checked in and included a copy of here. If I
have misrepresented anyone's argument, or if you spot something where
you have a question or n
At 07:57 PM 7/23/2007 -0700, Guido van Rossum wrote:
>On 7/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 11:58 AM 7/24/2007 +1200, Greg Ewing wrote:
> > >A class is defined in just one place, or a limited number
> > >of places if it has base classes.
&g
At 12:54 PM 7/24/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > And that is in fact the *normal* case, even in GF use. You seem to be
> > arguing that possible == probable, when it simply ain't so.
>
>No, I'm saying that it's hard to convince myself
At 11:58 AM 7/24/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > In order to follow things through with normal method calls, you have to
> > know where a class is in the program, implying that you either search
> > for it, or have read enough of the program to figure
At 11:09 PM 7/23/2007 +1000, Nick Coghlan wrote:
>And the big benefit here is that whatever techniques you come up with
>for searching for those overloads will work for *any* GF implemented
>using the same tools,
By the way, this is one of the reasons why it would be good to have a
relatively uni
At 12:07 AM 7/23/2007 -0700, Talin wrote:
>Phillip J. Eby wrote:
> > If anything, generic functions give you *better* tools to work with,
> > as there is no trivial way to fire up a program and say, "show me all
> > the classes that have a foo() method." (You could
At 11:48 AM 7/23/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > You seem to be saying that the ability to put things in different places
> > encourages disorganization.
>
>No. What I'm saying is that there are conflicting organisational
>requirements here.
At 11:47 AM 7/23/2007 +1200, Greg Ewing wrote:
>With a normal method call, you can take an assumed
>run-time type, start at one end and follow things
>through step by step. That's not so easy with
>generic functions, for two reasons: (1) all of the
>arguments can potentially influence where the
>co
At 01:09 PM 7/22/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > I.e., customers usually don't give you a step-by-step, "well, first I
> > check if the customer has an outstanding balance before I ship them
> > anything." They say, "Don'
At 01:28 PM 7/22/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > Well, I've worked with people who dislike OO for exactly the same
> > reason, since they feel they can never know whether a method might
> > have been overridden in a subclass.
>
>I think ther
At 10:55 PM 7/20/2007 -0700, Talin wrote:
>You mentioned earlier that there was a design reason for preferring
>@overload and @when vs. the earlier RuleDispatch syntax, but the
>explanation you gave wasn't very clear (to me anyway).
>
>(I personally prefer the @somegeneric.overload, but that's pure
At 08:16 AM 7/21/2007 -0700, Guido van Rossum wrote:
>On 7/21/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> > One of the nice features of Eby's proposal is that more complicated
> > dispatching systems can be added. Perhaps some application needs a
> > dispatching engine that can dispatch based on the
At 07:49 AM 7/20/2007 -0700, Guido van Rossum wrote:
>On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> > So the state of the PEP? From the rest of the posts so far,
> > it sounds like there is no real objection to the basic end user API as
> > described in the PEP,
>
>Actually I want to reserve j
FYI... another TurboGears developer speaks up re: their generic function use.
>Date: Thu, 19 Jul 2007 20:17:23 -0400
>From: "Mark Ramm"
>To: "Phillip J. Eby"
>Subject: Re: [Python-3000] pep 3124 plans
>
>>FYI, Jonathan, the version of PEAK-Rules tha
At 04:00 PM 7/19/2007 -0400, Jonathan LaCour wrote:
>I for one, as a committer on TurboGears, would absolutely love to see
>a good, solid generic function capability integrated into the standard
>library, and find PEP 3124 to completely cover my needs. There are
>certainly things in the PEP that I
At 11:58 AM 7/19/2007 +0100, Paul Moore wrote:
>1. The "Advanced" API - some people (including Guido?) do not see the
>need for the advanced features of the PEP such as method combinations.
>On the other hand, no-one has offered to write up of implement a
>reduced version.
Actually, two people hav
At 07:22 AM 7/19/2007 -0700, Guido van Rossum wrote:
>On 7/19/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
> > I would have liked to have input on this from other people using
> > RuleDispatch features also (doesn't one of Django/Turbogears project
> > use them extensively ?). Just so the BDFL &
At 09:47 AM 7/18/2007 -0700, Guido van Rossum wrote:
>Sorry, but I'm still totally uncomfortable with this. While I admit
>the feature exists, I really, really, really don't want it to be used
>on a regular basis. As long as Phillip calls a counterproposal
>"fingernails on a chalkboard", I call thi
At 01:37 PM 7/18/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > It allows the framework to bootstrap via successive
> > approximation. Initially, the 'implies()' function is just a plain
> > function, and then it later becomes a generic function. (And
At 09:04 PM 7/17/2007 -0400, Jim Jewett wrote:
>On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> > >I have one remaining question for Phillip: why is your design
> > >"absolutely dependent on b
At 03:53 PM 7/17/2007 -0700, Guido van Rossum wrote:
>On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> > >I have one remaining question for Phillip: why is your design
> > >"absolutely dependen
At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
>I have one remaining question for Phillip: why is your design
>"absolutely dependent on being able to modify functions in-place"?
>That dependency would appear to make it harder to port the design to
>other Python implementations whose function
At 09:13 PM 7/13/2007 +0200, Thomas Heller wrote:
>playing a little with py3k...
>
>pep3115 mentions that "__prepare__ returns a dictionary-like object
>which is used to store the class member definitions during evaluation
>of the class body."
>
>It does not mention whether this dict-like object is
At 07:39 AM 7/13/2007 +0200, Michele Simionato wrote:
>But I want to ask your opinion first, in order to understand if you
>are willing to scale down your proposal or not. At EuroPython Guido
>said that in private mail you made some strong argument explaining
>why the PEP could not be simplified
At 07:40 PM 7/9/2007 -0500, Ron Adam wrote:
>Guido van Rossum wrote:
>
>>We could easily change this to return a
>>writable mapping that's not a dict at all but a "view" on the locals
>>just as dict.keys() returns a view on a dict. I don't see why locals()
>>couldn't return the object used to repr
At 12:04 AM 7/10/2007 +0300, Guido van Rossum wrote:
>On 7/9/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>Phillip, I support any initiative to keep .setdefault() or similar
>>functionality. When this thread came up before, I wasn't against
>>defaultdict, I just didn't think it covered enough of t
At 11:56 PM 7/9/2007 +0300, Guido van Rossum wrote:
> The use of the word "mapping"
>might easily be construed as implementing abc.Mapping, and then
>iteration and reading the contents would be well-defined.
I'm not sure which use of the word "mapping" you're talking
about. PEP 3115 is explicit
At 07:59 PM 7/9/2007 +0100, tav wrote:
>>PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
>>it is in principle no longer necessary (due to the new defaultdict type).
>>
>>However, there is another class of use cases which use setdefault for
>>its limited atomic properties - the
PEP 3100 suggests dict.setdefault() may be removed in Python 3, since
it is in principle no longer necessary (due to the new defaultdict type).
However, there is another class of use cases which use setdefault for
its limited atomic properties - the initialization of non-mutated
data structures
At 06:13 PM 7/9/2007 +0300, Guido van Rossum wrote:
>On 7/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
> > >However, I will point out that setting class attributes via locals() is
> > >formally undefined (it ha
At 09:03 PM 7/9/2007 +1000, Nick Coghlan wrote:
>However, I will point out that setting class attributes via locals() is
>formally undefined (it happens to work in current versions of CPython,
>but there's no guarantee that will always be the case).
As of PEP 3115, it's no longer undefined for cla
At 11:55 AM 7/8/2007 +0300, Collin Winter wrote:
>On 7/7/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>Collin, where did you find this code in setuptools, btw? I've been
>>looking around at other packages of mine where static class
>>initialization uses data str
At 12:32 AM 7/7/2007 +0200, Guido van Rossum wrote:
>On 7/6/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 05:00 PM 7/6/2007 +0200, Georg Brandl wrote:
> > >Collin Winter schrieb:
> > > > While experimenting with porting setuptools to py3k (as of r56155
At 05:00 PM 7/6/2007 +0200, Georg Brandl wrote:
>Collin Winter schrieb:
> > While experimenting with porting setuptools to py3k (as of r56155), I
> > ran into this situation:
> >
> > class C:
> > a = (4, 5)
> > b = [c for c in range(2) if a]
> >
> > results in a "NameError: global name 'a' is n
At 01:40 AM 6/29/2007 -0400, Chris McDonough wrote:
>When coverage gets good, "documentation-ness" of tests suffers.
The question is more one of, "documentation for whom?". You can
write separate documents for library users than for library
extenders/developers. I don't put doctests in docstri
At 04:04 PM 6/28/2007 -0400, Chris McDonough wrote:
>a) If one of your fixture calls or an assertion fails for some
>reason, the rest of the test
> trips over itself trying to complete, usually without success
>because an invariant
> hasn't been met, and you need to scroll through a bunch o
At 04:59 PM 6/28/2007 +0100, tav wrote:
>* Abandoning of unit tests and replacing with full doctest coverage in
>the style perfected by Jim Fulton and PJE. Integration with py.test.
I believe that the origination credit for this rightly falls to Tim
Peters. (I just copied Jim, myself.) Meanwhil
At 07:18 PM 6/11/2007 -0400, Phillip J. Eby wrote:
>The subclass might look something like this:
>
> import imp, os, sys
> from pkgutil import ImpImporter
>
> suffixes = set(ext for ext,mode,typ in imp.get_suffixes())
>
> class CachedImporter(ImpI
At 12:46 AM 6/12/2007 +0200, Giovanni Bajo wrote:
>Hi Philip,
>
>I'm going to submit a PEP for Python 3000 (and possibly backported
>as an option off by default in Python 2). It's related to imports
>and how to make them faster. Given your expertise on the subject,
>I'd appreciate if you could r
At 02:31 PM 6/6/2007 -0700, Guido van Rossum wrote:
>I wonder if this may meet the needs for your PEP 3124? In
>particularly, earlier on, you wrote:
>
>>Btw, PEP 3124 needs a way to receive the same class object at more or
>>less the same moment, although in the form of a callback rather than
>>a c
At 07:48 PM 5/31/2007 +0800, Guido van Rossum wrote:
>I've updated the patch; the latest version now contains the grammar
>and compiler changes needed to make super a keyword and to
>automatically add a required parameter 'super' when super is used.
>This requires the latest p3yk branch (r55692 or
At 11:25 AM 5/25/2007 +0200, Neville Grech Neville Grech wrote:
> >From a user's POV, I'm +1 on having overloadable boolean
> functions. In many cases I had to resort to overload add or neg
> instead of and & not, I foresee a lot of cases where the and
> overload could be used to join objects wh
At 06:20 PM 5/20/2007 +1000, Tim Delaney wrote:
>Nick Coghlan wrote:
> > Tim Delaney wrote:
> >> So the question is, should the method store the class, or the name?
> >> Looking up by name could pick up a totally unrelated class, but
> >> storing the undecorated class could miss something important
At 04:25 PM 5/20/2007 +1000, Tim Delaney wrote:
>I'm not sure what you're getting at here - are you referring to the
>decorators for classes PEP? In that case, the decorator is applied
>after the class is constructed, so it would be the undecorated class.
>
>Are class decorators going to update t
At 06:34 PM 5/15/2007 -0700, Guido van Rossum wrote:
> > Have I missed something? It would seem that when dealing with ABCs
> > that provide concrete methods, "isinstance(x, SomeABC) == True" is
> > useless.
>
>The intention is that you shouldn't register such cases. This falls
>under the consentin
At 12:19 PM 5/16/2007 +1200, Greg Ewing wrote:
>Christian Tanzer wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> > > Phillip J. Eby wrote:
> > >
> > > > Imagine what would happen if the results of
> > > > calling supe
At 09:40 AM 5/15/2007 -0700, Guido van Rossum wrote:
>It looks like you're focused ion an implementation that is both highly
>optimized and (technically) pure Python (using every trick in the
>book). Personally I would rather go for a a slower but simpler pure
>Python implementation
Actually, the
At 08:32 AM 5/15/2007 -0700, Guido van Rossum wrote:
>Not so good; I expect the overloads could be written by different
>authors or at least at different times. Why can't you dynamically
>update the dispatcher when an overloading with more arguments comes
>along?
You mean by changing its __code__?
At 09:43 PM 5/14/2007 -0700, Guido van Rossum wrote:
>On 5/14/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Or perhaps we could just say that if the main function is defined
> > with *args, we treat those arguments as positional? i.e.:
> >
> > @
1 - 100 of 412 matches
Mail list logo
