Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44079

Re: There must be a better way

Show all headers | View raw

On 2013-04-21, Colin J. Williams <cjw@ncf.ca> wrote:
> On 20/04/2013 9:07 PM, Terry Jan Reedy wrote:
>> On 4/20/2013 8:34 PM, Tim Chase wrote:
>>> In 2.x, the csv.reader() class (and csv.DictReader() class) offered
>>> a .next() method that is absent in 3.x
>>
>> In Py 3, .next was renamed to .__next__ for *all* iterators. The
>> intention is that one iterate with for item in iterable or use builtin
>> functions iter() and next().
>>
>>
> Thanks to Chris, Tim and Terry for their helpful comments.
>
> I was seeking some code that would be acceptable to both Python 2.7 and 3.3.
>
> In the end, I used:
>
> inData= csv.reader(inFile)
>
> def main():
>      if ver == '2':
>          headerLine= inData.next()
>      else:
>          headerLine= inData.__next__()
>      ...
>      for item in inData:
>          assert len(dataStore) == len(item)
>          j= findCardinal(item[10])
>          ...
>
> This is acceptable to both versions.
>
> It is not usual to have a name with preceding and following 
> udserscores,imn user code.
>
> Presumably, there is a rationale for the change from csv.reader.next
> to csv.reader.__next__.
>
> If next is not acceptable for the version 3 csv.reader, perhaps __next__ 
> could be added to the version 2 csv.reader, so that the same code can be 
> used in the two versions.
>
> This would avoid the kluge I used above.

Would using csv.DictReader instead a csv.reader be an option?

-- 
Neil Cerutti

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-20 19:46 -0400
  Re: There must be a better way Chris Rebert <clp2@rebertia.com> - 2013-04-20 16:57 -0700
  Re: There must be a better way Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-21 00:06 +0000
    Re: There must be a better way Tim Chase <python.list@tim.thechases.com> - 2013-04-20 19:34 -0500
    Re: There must be a better way Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-20 21:07 -0400
      Re: There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-21 09:15 -0400
        Re: There must be a better way Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-04-21 16:39 +0300
          Re: There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-21 11:17 -0400
        Re: There must be a better way Peter Otten <__peter__@web.de> - 2013-04-21 15:43 +0200
          Re: There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-21 11:30 -0400
          Re: There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-21 11:30 -0400
        Re: There must be a better way Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-04-22 15:32 +0100
        Re: There must be a better way Neil Cerutti <neilc@norwich.edu> - 2013-04-22 14:42 +0000
          Re: There must be a better way "Colin J. Williams" <cjw@ncf.ca> - 2013-04-22 13:44 -0400
            Re: There must be a better way Neil Cerutti <neilc@norwich.edu> - 2013-04-23 13:36 +0000
              Re: There must be a better way Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-04-23 15:15 +0100
              Re: There must be a better way Tim Chase <python.list@tim.thechases.com> - 2013-04-23 09:30 -0500
              Re: There must be a better way Skip Montanaro <skip@pobox.com> - 2013-04-23 09:36 -0500
              Re: There must be a better way (correction) Tim Chase <python.list@tim.thechases.com> - 2013-04-23 10:02 -0500

csiph-web