Re: [Python-3000] map() Returns Iterator

2007-08-05 Thread Calvin Spealman
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

Re: [Python-3000] [Python-Dev] Pre-pre PEP for 'super' keyword

2007-04-30 Thread Calvin Spealman
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

Re: [Python-3000] [Python-Dev] Pre-pre PEP for 'super' keyword

2007-04-30 Thread Calvin Spealman
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

Re: [Python-3000] [Python-Dev] Pre-pre PEP for 'super' keyword

2007-04-29 Thread Calvin Spealman
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

Re: [Python-3000] Pre-pre PEP for 'super' keyword

2007-04-29 Thread Calvin Spealman
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.

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

2007-04-28 Thread Calvin Spealman
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

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

2007-04-28 Thread Calvin Spealman
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

Re: [Python-3000] Generic function PEP won't make it in time

2007-04-25 Thread Calvin Spealman
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

Re: [Python-3000] Fixing super anyone?

2007-04-25 Thread Calvin Spealman
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

Re: [Python-3000] adding @abstractmethods after class creation

2007-04-24 Thread Calvin Spealman
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

Re: [Python-3000] Fixing super anyone?

2007-04-24 Thread Calvin Spealman
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

Re: [Python-3000] Fixing super anyone?

2007-04-23 Thread Calvin Spealman
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

Re: [Python-3000] Pre-PEP: Simple input built-in in Python 3000

2006-12-23 Thread Calvin Spealman
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: > > &

Re: [Python-3000] Pre-PEP: Simple input built-in in Python 3000

2006-12-23 Thread Calvin Spealman
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

Re: [Python-3000] Pre-PEP: Simple input built-in in Python 3000

2006-12-23 Thread Calvin Spealman
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 > > >

Re: [Python-3000] Metaclasses in Py3K

2006-12-09 Thread Calvin Spealman
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): >

Re: [Python-3000] Assignment decorators

2006-12-08 Thread Calvin Spealman
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 > >

Re: [Python-3000] Fwd: defop ?

2006-11-26 Thread Calvin Spealman
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

Re: [Python-3000] Fwd: defop ?

2006-11-25 Thread Calvin Spealman
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

Re: [Python-3000] Fwd: defop ?

2006-11-24 Thread Calvin Spealman
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 >

[Python-3000] Fwd: defop ?

2006-11-22 Thread Calvin Spealman
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

Re: [Python-3000] defop ?

2006-11-22 Thread Calvin Spealman
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

[Python-3000] Nested Iteration?

2006-10-04 Thread Calvin Spealman
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 (

Re: [Python-3000] Kill GIL?

2006-09-19 Thread Calvin Spealman
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

Re: [Python-3000] Kill GIL?

2006-09-18 Thread Calvin Spealman
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,

Re: [Python-3000] Kill GIL?

2006-09-17 Thread Calvin Spealman
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 > >

Re: [Python-3000] The future of exceptions

2006-09-02 Thread Calvin Spealman
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

Re: [Python-3000] Exception Expressions

2006-08-31 Thread Calvin Spealman
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

Re: [Python-3000] Exception Expressions

2006-08-31 Thread Calvin Spealman
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

[Python-3000] Exception Expressions

2006-08-31 Thread Calvin Spealman
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

Re: [Python-3000] Bound and unbound methods

2006-08-15 Thread Calvin Spealman
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. > >

Re: [Python-3000] Conventions for annotation consumers

2006-08-15 Thread Calvin Spealman
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 >

Re: [Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

2006-08-15 Thread Calvin Spealman
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

[Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)

2006-08-15 Thread Calvin Spealman
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

Re: [Python-3000] Draft pre-PEP: function annotations

2006-08-14 Thread Calvin Spealman
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,

Re: [Python-3000] Draft pre-PEP: function annotations

2006-08-12 Thread Calvin Spealman
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

Re: [Python-3000] Draft pre-PEP: function annotations

2006-08-12 Thread Calvin Spealman
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

Re: [Python-3000] callable()

2006-07-17 Thread Calvin Spealman
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

Re: [Python-3000] callable()

2006-07-17 Thread Calvin Spealman
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

Re: [Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

Re: [Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

Re: [Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

Re: [Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

Re: [Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

[Python-3000] No Container Literals

2006-07-08 Thread Calvin Spealman
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

Re: [Python-3000] Type Coersion Syntax

2006-07-08 Thread Calvin Spealman
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

[Python-3000] Type Coersion Syntax

2006-07-06 Thread Calvin Spealman
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