On 5/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:35 PM 5/10/2007 -0400, Jim Jewett wrote:
> >Adding whenImported would be useful, even outside of ABCs and
> >generic functions.
> >But please don't go overboard with the "and its friends" part.
> If you mean importObject, importSequen
At 09:35 PM 5/10/2007 -0400, Jim Jewett wrote:
>On 5/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>>Using the "Importing" package from the Cheeseshop:
>...
>>from peak.util.imports import whenImported
>>whenImported('pydoc', register_pydoc)
>
>>I certainly wouldn't object to making 'whenImpor
On 5/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Using the "Importing" package from the Cheeseshop:
...
> from peak.util.imports import whenImported
> whenImported('pydoc', register_pydoc)
> I certainly wouldn't object to making 'whenImported' and its friends
> a part of the stdlib.
Addin
Phillip J. Eby wrote:
> That's because @around methods haven't been introduced at that point in
> the PEP; the following section introduces @around and explains that
> @arounds are called before the befores, etc.
Hmm, so it's not the case that @before methods are
called "before" all other metho
At 07:27 PM 5/10/2007 -0400, Raymond Hettinger wrote:
>The PEP for eliminating __del__ seemed straight-forward at the
>outset, but the use case you presented doesn't seem to have a clean
>substitute (as it requires the object to be alive to finalize
>it). Other use cases do have a clean solutio
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I did not see octal literals on your list. FWIW, I'm -1 on the proposal.
> The current situation is only a minor nuisance. While I prefer to see octal
> literal support dropped entirely, I would rather live with the 0123 form than
> a
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The PEP for eliminating __del__ seemed straight-forward
> at the outset, but the use case you presented doesn't
> seem to have a clean substitute (as it requires the object
> to be alive to finalize it). Other use cases do have a clean
> s
> and rejected some others:
> SR 3126 Remove Implicit String Concatenation Jewett
I had high hopes for this one. Cie le vie.
I did not see octal literals on your list. FWIW, I'm -1 on the proposal. The
current situation is only a minor nuisance. While I prefer to see octal
literal
At 09:59 AM 5/11/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>As I said above (and in the PEP), *all* before and after methods
>>are always called, unless an exception is raised somewhere along the way.
>
>> "Before" methods are invoked most-specific method first, with
>> ambiguous m
I've accepted some PEPs:
SA 3120 Using UTF-8 as the default source encoding von Löwis
SA 3121 Extension Module Initialization & Finalization von Löwis
SA 3123 Making PyObject_HEAD conform to standard C von Löwis
SA 3127 Integer Literal Support and Syntax Maupin
SA 3129 Cla
Phillip J. Eby wrote:
> As I said above (and in
> the PEP), *all* before and after methods are always called, unless an
> exception is raised somewhere along the way.
> "Before" methods are invoked most-specific method first, with
> ambiguous methods being executed in the order they were add
Phillip J. Eby wrote:
> However, because the hooks themselves are implemented using those
> default implementations, we can't separate out the implementations
> and just leave the hooks!
What this seems to mean is that the necessary hooks
are already there.
--
Greg
On 10/05/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> By the way, I have gotten off-list notes of encouragement from a
> number of people who've said they hope the PEP makes it, so evidently
> it's not overwhelming to everyone. Unfortunately, it seems to be
> suffering a bit from Usenet Nod Syn
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| At 08:43 PM 5/9/2007 -0600, Steven Bethard wrote:
| Yeah, and the dilemma is that if I go back and add in all the
| examples and clarifications that have come up in these threads, it's
| going to be even bigger. Ditto
> @before(do_stuff)
> def debug_it(ob: ClassC):
> import pdb
> pdb.set_trace()
This is probably far fetched, but I would much rather see:
before do_stuff(ob: ClassC):
import pbd
pdb.set_trace()
So the keyword 'before' and 'after' are just
At 02:56 PM 5/10/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Which is an excellent demonstration, by the way, of another reason
> > why before/after methods are useful. They're all *always* called
> > before and after the primary methods, regardless of how many of them
> > were regi
At 08:43 PM 5/9/2007 -0600, Steven Bethard wrote:
>>Meanwhile, leaving in the ability to have method combination later,
>>but removing the actual implementation of the @before/around/after
>>decorators in place would delete a total of less than 40 non-blank
>>lines of code.
>
>Sure, but it would al
At 02:40 PM 5/10/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > For
> > example, objects to be documented with pydoc currently have to
> > reverse engineer a bunch of inspection code, while in a GF-based
> > design they'd just add methods.
>
>There's a problem with this that I haven't see
At 12:40 PM 5/10/2007 +0200, BJörn Lindqvist wrote:
>I could use the debug_it @before-function, but I don't think I should
>have to just to see the control flow of a darn flatten function. The
>other approach would be to grep the whole source for "flatten." Then I
>should be able to figure out whic
At 09:06 AM 5/10/2007 -0400, Benji York wrote:
>I would let Jim speak for himself too, but I prefer to put words in his
>mouth. ;) While zope.interface has anemic facilities for "verifying"
>interfaces, few people use them, and even then rarely outside of very
>simple "does this object look right"
At 12:08 AM 5/11/2007 +1000, Nick Coghlan wrote:
>Benji York wrote:
> > If the PEP cooperates as well with zope.interface as you suggest, all
> > will be good in the world. Personally I'd prefer sufficient hooks be
> > added to the language and these types of things (interfaces, adaptation,
> > ge
Benji York wrote:
> If the PEP cooperates as well with zope.interface as you suggest, all
> will be good in the world. Personally I'd prefer sufficient hooks be
> added to the language and these types of things (interfaces, adaptation,
> generic functions, etc.) be left to third parties (like your
Phillip J. Eby wrote:
> At 06:11 PM 5/9/2007 -0400, Benji York wrote:
>> By way of clarification: Even in the large Zope 3 projects I work on
>> (which obviously use zope.interface), we virtually never use
>> interfaces for LBYL (just as Zope 3 itself rarely does).
>
> Yet, this is precisely wha
with the new class decorators of py3k, new use cases emerge.
for example, now it is easy to have real mixin classes or even
mixin modules, a la ruby.
unlike inheritance, this mixin mechanism simply merges the
namespace of the class or module into the namespace of the
decorated class. it does not a
On 5/10/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
>
> > >What if they have defined a do_stuff that dispatch on ClassC that is a
> > >subclass of ClassA? Good luck in figuring out what the c
On 09/05/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Maybe the tool has gotten smart enough to avoid constructions like:
>
> for k, v in list(dict.items()):
>
> for i in list(range(10)):
>
> but I can't help feeling there will always be a few cases where it
> makes the code longer and worse
26 matches
Mail list logo
