Is there any particular reason why `Zip` objects are iterable but not
indexable? Python allows that.
>From previous discussion on the topic (2014 topic
at https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems
that it has not been implemented yet.
Thanks,
Most "iterator" types are not indexable, AFAIK. The typical
recommendation/idiom is to just call `collect(itr)` if you need to
specifically index.
-Jacob
On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna
wrote:
> Is there any particular reason why `Zip` objects are iterable but not
> indexable? P
Sorry, to clarify a little:
The things you're zipping are not necessarily indexable (i.e. other
iterators), so it's not safe to assume you can always index a Zip.
On Thu, Jun 23, 2016 at 2:21 PM, Jacob Quinn wrote:
> Most "iterator" types are not indexable, AFAIK. The typical
> recommendation/i
Hi Jacob,
In my view, in principle, all "iterators" should be indexable, (at least
read-only), *unless *the underlying data is not indexable by nature, e.g.
with data that comes from a stream... Doing `zip([1, 2], [2, 3])[1]`
should probably just work.
I also think that for `Zip`s if the zip
My recollection is that part of the indexing interface in Julia (just by
convention) is that indexing should be of O(1) (or close to that)
complexity. Iterable things, in general, have O(n) complexity to access
the n-th element, because you have to traverse the data to get there
(the classic examp
> My recollection is that part of the indexing interface in Julia (just by
> convention) is that indexing should be of O(1) (or close to that)
> complexity.
As the OP suggested, this could still be the case, the zip object
would simply forward the indexing to the zipped collections, which
would fa
On Fri, 2016-06-24 at 05:26, Rafael Fourquet wrote:
>> My recollection is that part of the indexing interface in Julia (just by
>> convention) is that indexing should be of O(1) (or close to that)
>> complexity.
>
> As the OP suggested, this could still be the case, the zip object
> would simply f
I've found it very useful, even if it is O(n) complexity to get the n-th
element, to allow indexing.
For a database, if you have a packed record (for example, like SQLite's row
format), and you only need to access a single field, it's better to be able
to do just that,
and *not* have to unpack