Ville Vainio wrote:
The issue that really bothers me here is bloating the builtin
space. We already have an uncomfortable amount of builtin
functions.
Maybe what we're really after here is the notion of a
builtin module that's pre-imported into the builtin
namespace.
--
Greg Ewing, Computer Science
Steven Bethard wrote:
I'd argue that for the same reasons that
dict.fromkeys is a dict classmethod, the itertools methods could be iter
classmethods (or staticmethods). The basic idea being that it's nice to
place the methods associated with a type in that type's definiton. The
parallel's a l
Ville Vainio wrote:
A minimal set would not be that offensive, yes. But then we would have
two places to look for itertools functionality, which may not be
desirable.
True, though this is currently necessary with str objects if you want to
use, say string.maketrans, so it's not without some prece
> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:
Steven> Certainly a valid point. How would you feel about adding
Steven> just a select few itertools functions, perhaps just
Steven> islice, chain and tee?
A minimal set would not be that offensive, yes. But then we would h
Ville Vainio wrote:
The issue that really bothers me here is bloating the builtin
space. We already have an uncomfortable amount of builtin
functions. Of course the additions that have been suggested would not
pollute the builtin namespace, but they would still be there, taking
space. I'd rather se
> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:
Steven> to be documented as a builtin type. I don't find the
Steven> argument "builtin type methods are hard to find"
Steven> convincing -- the solution here is to fix the
Steven> documentation, not refuse to add builtin
Terry Reedy wrote:
But if classmethods are intended to provide alternate constructors
But I do not remember that being given as a reason for classmethod(). But
I am not sure what was.
Well I haven't searched thoroughly, but I know one place that it's
referenced is in descrintro[1]:
"Factoid: __
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Steven Bethard" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>>True it's not a huge win. But I'd argue that for the same reasons that
>>>dict.fromkeys is a dict classmeth
Terry Reedy wrote:
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
True it's not a huge win. But I'd argue that for the same reasons that
dict.fromkeys is a dict classmethod, the itertools methods could be iter
classmethods (or staticmethods).
As near as I could te
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> True it's not a huge win. But I'd argue that for the same reasons that
> dict.fromkeys is a dict classmethod, the itertools methods could be iter
> classmethods (or staticmethods).
As near as I could tell from the
On Tue, 29 Mar 2005 11:32:33 -0800, Michael Spencer <[EMAIL PROTECTED]> wrote:
[...]
>While we're on the topic, what do you think of having unary, non-summary
>builtins automatically map themselves when called with an iterable that would
>otherwise be an illegal argument:
That last "otherwise" is
On Tue, Mar 29, 2005 at 12:38:42PM +0300, Ville Vainio wrote:
> > "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
>
> Raymond> If the experience works out, then all you're left with is
> Raymond> the trivial matter of convincing Guido that function
> Raymond> attributes
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> I guess the real questions are[1]:
> * How much does iter feel like a type?
> * How closely are the itertools functions associated with iter?
>
> STeVe
>
> [1] There's also the question of how much you believe in OO tenets like
> "functions
Steven Bethard wrote:
Ville Vainio wrote:
"Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of ty
Ville Vainio wrote:
"Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of typing
Raymond> impo
> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes:
Raymond> If the experience works out, then all you're left with is
Raymond> the trivial matter of convincing Guido that function
Raymond> attributes are a sure cure for the burden of typing
Raymond> import statements.
[Jack Diederich]
> > itertools to iter transition, huh? I slipped that one in, I mentioned
> > it to Raymond at PyCon and he didn't flinch. It would be nice not to
> > have to sprinkle 'import itertools as it' in code. iter could also
> > become a type wrapper instead of a function, so an it
In article <[EMAIL PROTECTED]>,
Jack Diederich <[EMAIL PROTECTED]> wrote:
> I only included making iter a type to make it more symmetric with str
> being a type. iter is currently a function, as a practical matter I wouldn't
> mind if it doubled as a namespace but that might make others flinch.
On Mon, Mar 28, 2005 at 10:28:29AM -0700, Steven Bethard wrote:
> Jack Diederich wrote:
> >
> > itertools to iter transition, huh? I slipped that one in, I mentioned
> > it to Raymond at PyCon and he didn't flinch. It would be nice not to
> > have to sprinkle 'import itertools as it' in code. it
Jack Diederich wrote:
>
> itertools to iter transition, huh? I slipped that one in, I mentioned
> it to Raymond at PyCon and he didn't flinch. It would be nice not to
> have to sprinkle 'import itertools as it' in code. iter could also
> become a type wrapper instead of a function, so an iter in
20 matches
Mail list logo
