I really like json.loadf I'd also like to see a csv.loadf. not sure the `f` is needed: you could use @functools.singledispatch

On Mon, 6 Sep 2021, 01:12 Christopher Barker, <pythonchb@gmail.com> wrote:
On Sun, Sep 5, 2021 at 10:32 AM David Mertz, Ph.D. <david.mertz@gmail.com> wrote:
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.

The folks in favor of adding this to json are split between overloading load() (my preference) and adding a new, explicit method: loadf() or something like that. Either way, it's useful. I honestly don't get the objection. MY takle is that mosto f the core devs are doing "systsms programming" rather than "scripting" -- which means that they a:

Want to be more explicit and robust
Need more flexibiilty around various file-like objects
Don't mind a bit more expertise required. (e.g. specifying the encoding correctly)
Don't mind  a couple extra lines of code.

So why add a function to make it simple and easy to read a file fro a path-like?

I really wish the core devs would remember how useful Python is as a scripting language, and how many people use it that way.

Pandas is a good example, I lot of folks use it in a scripting context, so it provided features that make it easy to do so.

-CHB


On Sun, Sep 5, 2021, 1:19 PM Christopher Barker <pythonchb@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-leave@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-leave@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-leave@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/


--
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-leave@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/D2FQZHNSQB67WK3NZV6XMVDYMYZRHYTE/
Code of Conduct: http://python.org/psf/codeofconduct/