473,721 Members | 2,262 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

itertools to iter transition (WAS: Pre-PEP: Dictionary accumulatormeth ods)

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 instance could
be a wrapper that figures out whether to call .next or __getitem__
depending on it's argument.
for item in iter(mylist).im ap:
print item
or
for item in iter.imap(mylis t):
print item


Very cool idea. I think the transition from
itertools.XXX(i terable, *args, **kwargs)
to
iter.XXX(iterab le, *args, **kwargs)
ought to be pretty easy. The transition from here to
iter(iterable). XXX(*args, **kwargs)
seems like it might be more complicated though -- iter would have to
return a proxy object instead of the object returned by __iter__[1]. I
guess it already does that for objects that support only the __getitem__
protocol though, so maybe it's not so bad...

STeVe

[1] And you'd probably also want to special-case this so that if iter()
was called on an object that's already an instance of iter, that the
object itself was returned, not a proxy.
Jul 18 '05 #1
21 2179
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. iter could also
become a type wrapper instead of a function, so an iter instance could
be a wrapper that figures out whether to call .next or __getitem__
depending on it's argument.
for item in iter(mylist).im ap:
print item
or
for item in iter.imap(mylis t):
print item
Very cool idea. I think the transition from
itertools.XXX(i terable, *args, **kwargs)
to
iter.XXX(iterab le, *args, **kwargs)
ought to be pretty easy. The transition from here to
iter(iterable). XXX(*args, **kwargs)
seems like it might be more complicated though -- iter would have to
return a proxy object instead of the object returned by __iter__[1]. I
guess it already does that for objects that support only the __getitem__
protocol though, so maybe it's not so bad...


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.
[1] And you'd probably also want to special-case this so that if iter()
was called on an object that's already an instance of iter, that the
object itself was returned, not a proxy.

Jul 18 '05 #2
In article <ma************ *************** **********@pyth on.org>,
Jack Diederich <ja**@performan cedrivers.com> 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.


iter having the attributes currently residing as methods in itertools
sounds just fine to me.

I really don't like iter as a type instead of a function, though. It
sounds like a cool idea at first glance, but then you think about it and
realize that (unlike what happens with any class name) iter(x) is almost
never going to return an object of that type.

--
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/
Jul 18 '05 #3
[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 iter instance could
> be a wrapper that figures out whether to call .next or __getitem__
> depending on it's argument.
> for item in iter(mylist).im ap:
> print item
> or
> for item in iter.imap(mylis t):
> print item

[Steven Bethard] Very cool idea. I think the transition from
itertools.XXX(i terable, *args, **kwargs)
to
iter.XXX(iterab le, *args, **kwargs)
ought to be pretty easy.


Just to make sure you guys can live with your proposed syntax, trying using it
for a month or so and report back on whether the experience was pleasant. Try
dropping the following into your setup.py

def wrapiter():
import __builtin__, itertools
orig = __builtin__.ite r
def iter(*args):
return orig(*args)
for name in ('__doc__', '__name__'):
setattr(iter, name, getattr(orig, name))
vars(iter).upda te(vars(itertoo ls))
__builtin__.ite r = iter
wrapiter()

If the experience works out, then all you're left with is the trivial matter of
convincing Guido that function attributes are a sure cure for the burden of
typing import statements.
Raymond Hettinger
Jul 18 '05 #4
>>>>> "Raymond" == Raymond Hettinger <vz******@veriz on.net> 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.

For one thing, it would make it harder to find the functions from the
docs. It's easy to find the doc for 'itertools', but iter object
methods would require browsing that infamous Chapter 2 of the
documentation.. .

Apart from that, I don't really see the advantage in moving away from
itertools.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #5
Ville Vainio wrote:
>>"Raymon d" == Raymond Hettinger <vz******@veriz on.net> 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.

For one thing, it would make it harder to find the functions from the
docs. It's easy to find the doc for 'itertools', but iter object
methods would require browsing that infamous Chapter 2 of the
documentation.. .


Well, it would only make them as hard to find as, say, dict.fromkeys,
which is probably the best parallel here. Of course iter would have to
be documented as a builtin type. I don't find the argument "builtin
type methods are hard to find" convincing -- the solution here is to fix
the documentation, not refuse to add builtin types.
Apart from that, I don't really see the advantage in moving away from
itertools.


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). 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 little weaker here because calling iter doesn't always
produce objects of type iter:

py> class C(object):
.... def __iter__(self):
.... yield 1
....
py> iter(C())
<generator object at 0x011805A8>

But note that iter does produce 'iterator' objects for the old
__getitem__ protocol:

py> class C(object):
.... def __getitem__(sel f, index):
.... if index > 5:
.... raise IndexError
.... return index
....
py> iter(C())
<iterator object at 0x01162EF0>

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 closely associated with a type should be members of that type"...
Jul 18 '05 #6
Steven Bethard wrote:
Ville Vainio wrote:
>>> "Raymond" == Raymond Hettinger <vz******@veriz on.net> 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.

For one thing, it would make it harder to find the functions from the
docs. It's easy to find the doc for 'itertools', but iter object
methods would require browsing that infamous Chapter 2 of the
documentation.. .

Well, it would only make them as hard to find as, say, dict.fromkeys,
which is probably the best parallel here. Of course iter would have to
be documented as a builtin type. I don't find the argument "builtin
type methods are hard to find" convincing -- the solution here is to fix
the documentation, not refuse to add builtin types.
Apart from that, I don't really see the advantage in moving away from
itertools.

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). 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 little weaker here because calling iter doesn't always
produce objects of type iter:

py> class C(object):
... def __iter__(self):
... yield 1
...
py> iter(C())
<generator object at 0x011805A8>

But note that iter does produce 'iterator' objects for the old
__getitem__ protocol:

py> class C(object):
... def __getitem__(sel f, index):
... if index > 5:
... raise IndexError
... return index
...
py> iter(C())
<iterator object at 0x01162EF0>

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 closely associated with a type should be members of that
type"...

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:

e.g.,
int(iterable) -> (int(i) for i in iterable)
ord(iterable) -> (ord(i) for i in iterable)
This would be unambiguous, I think, in the cases of bool, int, callable, chr,
float, hex, id, long, oct, ord, vars...

It would shorten the common cases of:
for char in somestring:
ordchar = ord(char)
# do something with ordchar, but not char
to
for ordchar in ord(somestring) :
...

It would not work for summarizing functions or those that can accept an iterable
today e.g., len, repr

Michael

Jul 18 '05 #7
"Steven Bethard" <st************ @gmail.com> 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 closely associated with a type should be members of that type"...


I would answer positively for both: iter does feel like a type conceptually and (most, if not all)
itertools would be suitable methods for such a type. Here I am referring to 'type' more as an
interface (or protocol; i'm not sure of the difference) rather than a concrete class, so whether the
result of iter is an iterator or a generator object is of little importance as long as it works as
expected (that it, whether it makes calls to next() or __getitem__() becomes a hidden implementation
detail).

If iter was a type, it would also be neat to replace some itertool callables with special methods,
as it has been mentioned in another thread (http://tinyurl.com/6mmmf), so that:
iter(x)[a:b:c] := itertools.islic e(iter(x),a,b,c )
iter(x) + iter(y) := itertools.chain (iter(x), iter(y))
iter(x) * 3 := itertools.chain (* itertools.tee(i ter(x), 3))

George
Jul 18 '05 #8
On Tue, Mar 29, 2005 at 12:38:42PM +0300, Ville Vainio wrote:
>> "Raymond" == Raymond Hettinger <vz******@veriz on.net> 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.

For one thing, it would make it harder to find the functions from the
docs. It's easy to find the doc for 'itertools', but iter object
methods would require browsing that infamous Chapter 2 of the
documentation.. .

Apart from that, I don't really see the advantage in moving away from
itertools.


I only use itertools when I have to currently, which isn't necessarily
bad (premature optimization etc) but I do use lists when I just need an
iterator - simply because 'list()' is easier to type than
'^<space><home> ^n^nimport itertools as it<CR>^x^x' (emacsen to mark HERE,
jump to the top, import itertools, and jump back). If itertools methods
were handier I'd use them when I just want to iterate. As an anecdote
I use generator comprehensions[1] more often than list comprehensions.

I'll give the builtin manipulations a try but since I have to deal with
many machines I can't promise to flex it much.

-jack

[1] aside, I didn't care too much about upgrading machines 2.2 => 2.3, but
when 2.4 came along with set as a builtin and generator comprehensions it
was compelling.
Jul 18 '05 #9
On Tue, 29 Mar 2005 11:32:33 -0800, Michael Spencer <ma**@telcopart ners.com> 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 pretty important for strings as in int('1234') ;-)
e.g.,
int(iterable ) -> (int(i) for i in iterable)
ord(iterable ) -> (ord(i) for i in iterable)
This would be unambiguous, I think, in the cases of bool, int, callable, chr,
float, hex, id, long, oct, ord, vars...
It would shorten the common cases of:
for char in somestring:
ordchar = ord(char)
# do something with ordchar, but not char
But wouldn't you really currently write the "->" form from above? I.e.,

for ordchar in (ord(c) for c in somestring):
...

to compare withto
for ordchar in ord(somestring) :
...
So it's not _that_ much shorter ;-)
It would not work for summarizing functions or those that can accept an iterable
today e.g., len, repr

I like concise expression, so I'm willing to try it. I guess it would be enough
to override __builtins__ to get a taste, e.g., (not thought through):
class itint(int): ... oldint = __builtins__.in t
... def __new__(cls, arg):
... try: return cls.oldint(arg)
... except (TypeError, ValueError):
... oi = cls.oldint
... return (oi(item) for item in arg)
... __builtins__.in t = itint
int('1234') 1234 for x in int('1 23 456'.split()): print x, ...
1 23 456 for x in int(range(1,8,2 )): print x, ...
1 3 5 7 for x in int('123x'): print x,

...
1 2 3
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 7, in <generator expression>
ValueError: invalid literal for int(): x

Hm, ... ;-)

Regards,
Bengt Richter
Jul 18 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
1158
by: Rob Landley | last post by:
Ahem: <gripe> cgi.FieldStorage() doesn't give me a dictionary. Instead it gives me something that pretends to be a dictionary, badly. If it was a dictionary, I could print it and get a list the form entries sent back to me. When writing code to parse preprepared forms (such as a credit card verification service returns), this is actually rather nice to be able
15
2986
by: Stefan Behnel | last post by:
Hi! I'm trying to do this in Py2.4b1: ------------------------------- import logging values = {'test':'bla'} logging.log(logging.FATAL, 'Test is %(test)s', values) -------------------------------
125
7193
by: Raymond Hettinger | last post by:
I would like to get everyone's thoughts on two new dictionary methods: def count(self, value, qty=1): try: self += qty except KeyError: self = qty def appendlist(self, key, *values): try:
1
1303
by: Steven Bethard | last post by:
Michael Spencer 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: > > e.g., > int(iterable) -> (int(i) for i in iterable) > ord(iterable) -> (ord(i) for i in iterable) > >
3
5074
by: Richard A. DeVenezia | last post by:
I hope this is the end of my present 'discovery' phase. I've learned alot about JavaScript in a short time and my head hurts. The following is what came out of all my questions and all the excellent answers (thanks!). It will be the basis of a slightly more complicated function for rendering a two-level navigation bar ( Don't have time to get into design of a multi-styletype renderer for n-level hierarchies. ) This is a single function...
38
2100
by: Steven Bethard | last post by:
> >>> aList = > >>> it = iter(aList) > >>> zip(it, it) > > That behavior is currently an accident. >http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1121416
18
14976
by: Rune B | last post by:
Hi Group I was considering using a Generic Dictionary<> as a value container inside my business objects, for the reason of keeping track of fields changed or added and so on. - But how expensive is it to instantiate/use Generic Dictionaries in great numbers (let's just say 100000's ), in terms of memoryuse and performance? Any practical experiences out there?
23
1465
by: Mathias Panzenboeck | last post by:
I wrote a few functions which IMHO are missing in python(s itertools). You can download them here: http://sourceforge.net/project/showfiles.php?group_id=165721&package_id=212104 A short description to all the functions: icmp(iterable1, iterable2) -integer Return negative if iterable1 < iterable2, zero if iterable1 == iterable1,
4
1004
by: John Salerno | last post by:
Just curious if people put up any resistance to 2.0 like some people do for 3.0. Was it as big of a change in the language, or was the transition smoother? It seems silly for anyone to say they would prefer to stick with 1.x versions at this point, so perhaps we'll get there with 3.0 eventually too. Anyway, I'm just trying to figure out if the whole "I don't like 3.0" mentality (of some people, not all of course) is merely a result of it...
0
9376
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9230
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9148
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9085
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6678
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4499
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3207
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2596
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2146
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.