Most Pandas read methods take either a path-like argument or a file-like argument, and figure out which it is by introspection when called. Actually, most of them even accept a URL-like argument as well
I don't think this is a terrible approach. It doesn't make things quite as explicit as the standard library generally does. But it's convenient, and there's no real ambiguity. On Sun, Sep 5, 2021, 1:19 PM Christopher Barker <python...@gmail.com> wrote: > > This would only be helpful when the CSV is on the disk but csv.reader() >> takes a file object so that it can used with anything like a socket for >> example. json.load() does the same thing. >> > > There has been discussion about adding loading from a “path like” to the > JSON lib. See this list about ten months ago and a recent thread on discuss. > > There resistance, but it ended with the idea that maybe there should be a > PEP for a common interface for all “file” readers — eg JSON, CSV, etc.. And > that interface could be supported by third party libs. That interface > *maybe* would include a single step load from a path-like functionality. > > It seems to me that it is better to keep a generic interface that are >> composable. >> > > No one is suggesting removing the load-from-a-file-like interface. I have > no idea why the fact that some people sometimes need a more flexible > interface (maybe most people, even) somehow means that we shouldn’t make > things easy and obvious for a common use case. > > -CHB > > > > >> Cheers, >> Rémi >> >> >> >> ? And something similar for ‘csv.reader’? I’m not wedded to the details >> here. >> >> The two main reasons I think this might be a positive addition are - >> >> * you wouldn’t have to know or remember the right way to open a CSV file >> (newline=“”). >> * it elides very common code. >> >> but perhaps there are things I’m missing here? >> >> As a side note, I think ‘csv.reader’ could usefully be renamed to >> something else (maybe just Reader?), since it’s kind of out of sync with >> the CamelCase used in ‘DictReader’. But maybe that’s just an attempt at >> foolish consistency :). >> >> best, >> —titus >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/EKHYCTYMXZG3VI4JYFA3Y3LD3ZNMI3IX/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/ZJNJQFC2LKQ76GTEBQNKTB3WO2POTKEN/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/GAPBNBGLOWD27FCTJJV7FEPUZRKUE6FL/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IXWTRZ6RINR5OZECMXHAP7B7MUUY2RH5/ Code of Conduct: http://python.org/psf/codeofconduct/
