Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
___
Python-bugs-list mailing
Ralph Corderoy ralph-pythonb...@inputplus.co.uk added the comment:
fileLineIter() is not a solution that allows this bug to be closed, no.
readline() needs modifying and if that means python-dev discussion then
that's what it needs. Things to consider include changing the record
separator as
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
This fileLineIter function looks like a good recipe to me. Can we close the
issue then?
--
nosy: +amaury.forgeotdarc
resolution: - works for me
status: open - pending
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
A recipe in the comments on a tracker item isn't enough reason to close the
RFE, no.
An entry on the cookbook with a pointer from the docs might be sufficient,
although I'm still not averse to the idea of an actual readrecords method (with
Ray.Allen ysj@gmail.com added the comment:
I think it's a good idea adding a keyword argument to specify the separator of
readlines().
I believe most people can accept the universal meaning of line, which has
similar meaning of record, that is a chunk data, maybe from using line
Douglas Alan darkwate...@gmail.com added the comment:
Personally, I think that this functionality should be built into Python's
readlines. That's where a typical person would expect it to be, and this is
something that is supported by most other scripting language I've used. E.g.,
awk has the
Antoine Pitrou pit...@free.fr added the comment:
Personally, I think that this functionality should be built into
Python's readlines. That's where a typical person would expect it to
be, and this is something that is supported by most other scripting
language I've used.
Adding it to
Nick Coghlan ncogh...@gmail.com added the comment:
On Fri, Jul 23, 2010 at 3:54 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Personally, I think that this functionality should be built into
Python's readlines. That's where a typical
Éric Araujo mer...@netwok.org added the comment:
Ralph, core developers have not rejected this idea. It needs a patch now (even
rough) to get the discussion further.
--
components: +Library (Lib) -Interpreter Core
___
Python tracker
Douglas Alan darkwate...@gmail.com added the comment:
Until this feature gets built into Python, you can use a Python-coded generator
such as this one to accomplish the same effect:
def fileLineIter(inputFile,
inputNewline=\n,
outputNewline=None,
Ralph Corderoy ralph-pythonb...@inputplus.co.uk added the comment:
Google has led me here because I'm trying to see how to process find(1)'s
-print0 output with Python. Perl's -0 option and $/ variable makes this
trivial.
find -name '*.orig' -print0 | perl -n0e unlink
awk(1) has its RS,
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
___
Python-bugs-list mailing
R. David Murray rdmur...@bitdance.com added the comment:
cat temp
this is$#a weird$#file$#
./python
Python 3.1b1+ (py3k:72632:72633M, May 15 2009, 05:11:27)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
f = open('temp', newline='$#')
[50354 refs]
Nick Coghlan ncogh...@gmail.com added the comment:
While RDM's quick test is encouraging, I think one of the key things is
going to be developing tests for the various cases:
- binary mode, single byte line ending
- binary mode, multi-byte line ending
- text mode, single byte single char line
Antoine Pitrou pit...@free.fr added the comment:
-1 on this idea. readlines() exists precisely because line endings are
special when it comes to text IO (because of the various platform
differences).
If you want to split on any character, you can just use read() followed
by split(). No need to
Antoine Pitrou pit...@free.fr added the comment:
And it's certainly not easy to do correctly :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
Antoine Pitrou pit...@free.fr added the comment:
Uh, trying again to remove the keyword :-(
--
keywords: -easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
Antoine Pitrou pit...@free.fr added the comment:
Ok, let me qualify my position a bit:
- -1 for abusing the newline parameter
- -1 for abusing readlines()
- +0 on an additional method (readchunks was suggested) which does the
splitting, either on a single character or on a string
Please bear in
Nick Coghlan ncogh...@gmail.com added the comment:
I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method readrecords
that takes a mandatory record separator makes more sense than using
readlines to read things that are not
Nick Coghlan ncogh...@gmail.com added the comment:
I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method readrecords
that takes a mandatory record separator makes more sense than using
readlines to read things that are not
Changes by Nick Coghlan ncogh...@gmail.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
___
Python-bugs-list mailing list
Antoine Pitrou pit...@free.fr added the comment:
Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is trying
to avoid) or you have to do your own buffering and so forth to split
records as you go. Since the
Douglas Alan d...@alum.mit.edu added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Nick Coghlan ncogh...@gmail.com added the comment:
Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is
trying
Changes by Daniel Diniz aja...@gmail.com:
--
components: +IO
nosy: +benjamin.peterson, pitrou
versions: +Python 3.2 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
Changes by Daniel Diniz aja...@gmail.com:
--
stage: - test needed
versions: +Python 3.1 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
Nick Coghlan ncogh...@gmail.com added the comment:
Any further work on this should wait until the io-in-c branch has landed
(or at least be based on that branch).
--
stage: test needed - needs patch
___
Python tracker rep...@bugs.python.org
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -montanaro.historic
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
___
Facundo Batista [EMAIL PROTECTED] added the comment:
I took a look at it...
It's not as not-complicated as I original thought.
The way would be to adapt the Py_UniversalNewlineFread() function to
*not* process the normal separators (like \n or \r), but the passed one.
A critical point would
Nick Coghlan added the comment:
The mail.python.org link I posted previously is broken. Here's an
updated link to the relevant c.l.p. thread:
http://mail.python.org/pipermail/python-list/2005-February/310020.html
From my point of view, I still think it's an excellent idea and would be
happy to
Facundo Batista added the comment:
Raymond disapproved it, Skip discouraged it, and Nick didn't push it any
more, all more than two years ago.
Nick, please, if you feel this is worthwhile, raise the discussion in
python-dev.
--
nosy: +facundobatista
resolution: - rejected
status: open
30 matches
Mail list logo
