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, <python...@gmail.com> wrote: > On Sun, Sep 5, 2021 at 10:32 AM David Mertz, Ph.D. <david.me...@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 <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/ >>> >> > > -- > 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/D2FQZHNSQB67WK3NZV6XMVDYMYZRHYTE/ > 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/Q5CZYZHTBN4HXVXJ5CU7MCFUHIBQIA6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
