I can't remember specifics, but i had always expected map and filter
to be replaced by their itertools counter parts.
On 8/4/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> Although there has been quite a bit of discussion on dropping reduce()
> and retaining map(), filter(), and zip(), there has
On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> I've been working on improved super syntax for quite a while now - my
> original approach was 'self.super' which used _getframe() and mro crawling
> too. I hit on using bytecode hacking to instantiate a super object at the
> start of the method t
On 4/30/07, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> >> 1. When a method is defined, the class is bound to it via an
> attribute
> >> (which in my version is called func_class).
>
> > In Py3k all the func_XXX attrs are renamed __XXX__, so this would be
> > __c
ment a sys._getframe() and a
IronPython currently doesn't, but seems to plan on it (there is a
placeholder, at present). I am not sure if notes on this belongs in
the PEP or not.
Draft Three follows for all. I think I'm turning off e-mail for the
rest of this evening, so I'll ca
On 4/29/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> > I've been intending to write up a PEP for fixing super, but I haven't had
> > time to get to it.
>
> Calvin Spealman has the most recent draft.
On 4/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> > Aside from the way in which `x' can already lie:
> >
> > >>> class X(object):
> > ... __class__ = property(lambda self: int)
> > ...
> > >>> isinstance(X(), i
On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > The current ABC proposal is to use isinstance as the test; Jeffrey
> > Yaskin's numbers PEP highlighted the weakness there with a concrete
> > example.
> >
> > If you need to an abstracti
On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote:
> I disagree. I think that B&D-ish enforcement of ABCs is the most important
> feature of an ABC (with the option of being able to turn off enforcement on
> a per-class basis).
>
> Imagine you have a program that takes a long tim
On 4/25/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > > I must have miscopied then because it worked perfectly here. Yes, I
> > > me
On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/24/07, guido.van.rossum <[EMAIL PROTECTED]> wrote:
> > +We define a new built-in decorator, [EMAIL PROTECTED]
> [snip]
> > +**Implementation:** The [EMAIL PROTECTED] decorator sets the
> > +function attribute ``__isabstractmethod__`` to t
n 4/23/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > I will +1 on the self.__super__ suggestion. Hey, its very doable and I
> > even whipped it up with a simple metaclass, so it would be a tiny
> > change to 'type' in order to actually implement it as a st
On 4/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Michele Cella <[EMAIL PROTECTED]> wrote:
>
> > ... having a super keyword with methods attached ... doesn't feel right
>
> Agreed. The goal is to *fix* super, not to make it a keyword. Making
> it a keyword might -- or might not -- b
On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/23/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 12/23/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > &
On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/23/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > I was reading the thread and wanted to make a comment about the "input
> > from a GUI". It should be noted that whatever the names of
On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/23/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > > But they typically aren't used to entering EOF either; EOF is not
> > > exactly a typical input in an interactive program, and having to enter
> > >
On 12/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > At 08:53 AM 12/8/2006 -0600, Guido van Rossum wrote:
> >
> >>I've been thinking about this too, and I think it's reasonable to let
> >>the metaclass provide the dict to be used as locals.
> >
> > [snip]
> >
> >>class C(B1, B2, metaclass=Foo):
>
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
> One other minor brainstorm before I head off to work: I'd like function
> decorators to work with assignment statements as well as 'def' statements.
>
> Use case:
>
> class Foo:
>
>@private
>def myfunc():
> pass
>
>
On 11/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/25/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > I will make only one more comment and then ill drop my comments
> > without direct questions.
> >
> > On 11/25/06, Guido van Rossum <[EMA
I will make only one more comment and then ill drop my comments
without direct questions.
On 11/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hm. The double colon rubs me the wrong way (Perl and/or C++). But
> apart from that, if this is the solution, I'm not sure the problem
> you're tryin
On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Not sure I like this better. My spelling of "operator::XXX" is
>
I need to move away from the GMail client for lists or they need to
fix it. Sorry Guido, forwarding to the list as GMail should be doing
in the first place!
-- Forwarded message --
From: Calvin Spealman <[EMAIL PROTECTED]>
Date: Nov 23, 2006 2:10 AM
Subject: Re: [Pytho
This whole thing seems a bit off from start to finish. A seperate
definition syntax with a special name/expression weirdo thingy, etc.
Anyway, we need something that handles this but isnt specific to this.
There are other situations it may be useful. Essentially we want to
have names that are known
I'm sure this has been brought up before, either for Py3K or in
previous development, so just let me know if its already been
shotdown. Maybe even give it a second thought.
for i in some_list in some_list_of_lists:
do_something_with(i)
Currently, this is passed iterating over the results of (
On 9/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan schrieb:
> > I was thinking it would be easier to split out the Global Interpreter Lock
> > and
> > a per-interpreter Local Interpreter Lock, rather than trying to go to a full
> > free-threading model. Anyone sharing other ob
On 9/18/06, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> > What use case *requires* sharing?
>
> Strictly speaking, it's always avoidable. But in setup-heavy systems,
> avoiding SHM is a massive and costly pain. Consider web applications;
> ideally, you can preload one copy of all of your translations,
On 9/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > > It would be substantially easier if there were a distributed RPC
> > > mechanism that auto distributed to the "least-working" process in a
> >
On 9/2/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Right, which is why the original suggestion came up in the first place. It
> would be nice to compartmentalize exceptions entirely, but the worry of
> keeping a ont of memory alive for it needs to be addressed, especially if
> exceptions are to
On 8/31/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> One problem is that it doesn't seem to chain
> all that well. Suppose you had three files to
> try opening:
>
>open(name1) except (open(name2) except open(name3) if IOError) if IOError
>
> Maybe it would be better if the exception type
> and a
On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> So this feels like the Perl idiom of using die: ``open(file) or die`` (or
> something like that; I have never been a Perl guy so I could be off).
>
> > ...
>
> The problem I have with this whole proposal is that catching exceptions
> should be v
I thought I felt in the mood for some abuse today, so I'm proposing
something sure to give me plenty of crap, but maybe someone will enjoy
the idea, anyway. This is a step beyond the recently added conditional
expressions. I actually made this up as a joke, explaining at which
point we would have g
On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Talin wrote:
> > > the compiler would note the combination of the attribute access and the
> > > call, and combine them into an opcode that skips the whole method
> > > creation step.
> >
On 8/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Prescod wrote:
> > What if
> > two different groups start fighting over the keyword "type" or "doc" or
> > "lock"? Python already has a module system that allows you to use the
> > word "type" and me to use the word "type" without conflict
>
On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> >> 1) Static analysis tools (pychecker, optimising compilers, etc) must
> >> be
On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > How is
> > > this significantly better than my dict-based approach, which uses
> > > standardised dict keys to indicate the kind
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > "In order for processors of function annotations to work interoperably, they
> > must use a common interpretation of objects used as annotations on a
> > particular function. For example,
On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> I made a proposal that Phillip was mostly okay with. What do other
> participants in the thread think? Would it move towards resolving this
> thread?
>
> "In order for processors of function annotations to work interoperably, they
> must use a c
I am getting very tired of gmail's ingoring of the mailing-list
headers in context of replying! Anyway, here is what I accidentally
sent as personal messages related to this thread. Replying to Talin's
long story about MIDI devices:
WOW
I won't even pretend to reply with anything near a similar s
On 7/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
"Alex Martelli" <[EMAIL PROTECTED]> wrote:>> On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:> > I note in PEP 3000 the proposal to remove callable(), with the comment "just
> > call the object and catch the exception."> >> > I think that's
I second that removal of callable() would be a bad idea. There are too many cases where it is not feasable to "just call the object and catch the exception". In the cases where the call would not happen until later than the test for callability, it would require then that any state changes caused b
On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Jul 2006, Calvin Spealman wrote:
> > Just throwing this out there, but I would love to see a complete
> > dropping of container literals from Python. That is why I proposed the
> > coercion syntax (ex: list
On 7/8/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
> > Just throwing this out there, but I would love to see a complete
> > dropping of container literals from Python. That is why I proposed the
> > coercion syntax (ex: list from someth
On 7/8/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
> > On 7/8/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> Calvin Spealman wrote:
> >> > Just throwing this out there, but I would love to see a complete
> >> > dro
On 7/8/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
> > Just throwing this out there, but I would love to see a complete
> > dropping of container literals from Python. That is why I proposed the
> > coercion syntax (ex: list from someth
On 7/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 7/8/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > Just throwing this out there, but I would love to see a complete
> > dropping of container literals from Python. That is why I proposed the
> > coercio
Just throwing this out there, but I would love to see a complete
dropping of container literals from Python. That is why I proposed the
coercion syntax (ex: list from something) because it would allow
things like list(1, 2, 3) and we can already do dict(ten=10,
eleven=11), so what is the real need
t;[EMAIL PROTECTED]> wrote:
>
>
>
> On 7/6/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > I would like to propose a syntax that would explicitly be read as
> > "Create an object of Foo converted from object Bar". Being explicit,
> > as such
I would like to propose a syntax that would explicitly be read as
"Create an object of Foo converted from object Bar". Being explicit,
as such, could bring about some interesting optimizations in the
future or immediately, and reduce redundant signatures (such as the
type(foo) syntax). I understand
47 matches
Mail list logo