Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 28.03.17 02:35, Greg Ewing wrote: Paul Moore wrote: Is this a well-defined idea? ... There's nothing describing how multiple values would be stored in the same file/transmitted in the same stream. I think this is something that's outside the scope of the spec. But since the grammar makes i

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On Tue, Mar 28, 2017 at 8:37 AM, Chris Angelico wrote: > > Yes, but if the "in" operator is used, it would still work, because > r"..." is a str, and "str" in "string" is meaningful. > > But I think a better solution will be for regex literals to be > syntax-highlighted differently. If they're a t

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On Tue, Mar 28, 2017 at 2:24 PM, Markus Meskanen wrote: > While I agree with most of your arguments, surely you must be the one joking > here? "Ugly" is obviously a matter of opinion, I personally find the > proposed syntax more beautiful than the // used in many other languages. But > claiming it

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

On 3/27/17, Chris Angelico wrote: > On Mon, Mar 27, 2017 at 12:26 PM, Terry Reedy wrote: >> It might be possible (or not!) to make the clause-heading words like >> 'where' >> or 'groupby' (this would have to be one word) recognized as special only >> in >> the context of starting a new comprehens

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On Mar 28, 2017 06:08, "Steven D'Aprano" wrote: On Mon, Mar 27, 2017 at 05:17:40PM +0200, Simon D. wrote: > The regexp string litteral could be represented by : re"" > > It would ease the use of regexps in Python, allowing to have some regexp > litterals, like in Perl or JavaScript. > > We may e

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On Mon, Mar 27, 2017 at 05:17:40PM +0200, Simon D. wrote: > The regexp string litteral could be represented by : re"" > > It would ease the use of regexps in Python, allowing to have some regexp > litterals, like in Perl or JavaScript. > > We may end up with an integration like : > > >>> import

Re: [Python-ideas] Adding an 'errors' argument to print

On Mon, Mar 27, 2017 at 8:52 PM, Barry wrote: > I took to using > > chcp 65001 > > This puts cmd.exe into unicode mode. conhost.exe hosts the console, and chcp.com is a console app that calls GetConsoleCP, SetConsoleCP and SetConsoleOutputCP to show or modify the console's input and output c

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

2017-03-27 17:04 GMT+02:00 Steven D'Aprano : > Of course pathlib can already read JSON, or for that matter ReST text > or JPG binary files. It can read anything as text or bytes, including > JSON: > > some_path.write_text(json.dumps(obj)) > json.loads(some_path.read_text()) Note: You should specif

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Paul Moore wrote: Is this a well-defined idea? ... There's nothing describing how multiple values would be stored in the same file/transmitted in the same stream. I think this is something that's outside the scope of the spec. But since the grammar makes it clear when you've reached the end of

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Ram Rachum schrieb am Mo., 27. März 2017 um 16:42 Uhr: > Another idea: Maybe make json.load and json.dump support Path objects? > yes, all string-path expecting stdlib APIs should support PEP 519 https://www.python.org/dev/peps/pep-0519/ ___ Python-id

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

FWIW, pyline could produce streaming JSON w/ json.dumps(indent=0), but because indent>0, there are newlines. pydoc json | pyline '{"a":l} if "json" in l.lower() else None' -O json pydoc json | pyline -r '.*JSON.*' 'rgx and line' -O json It's a similar issue: what are good default JSON enc

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On Mon, Mar 27, 2017 at 10:34 AM, Chris Barker wrote: > On Mon, Mar 27, 2017 at 7:59 AM, Paul Moore wrote: > >> On 27 March 2017 at 15:40, Ram Rachum wrote: >> > Another idea: Maybe make json.load and json.dump support Path objects? >> >> If they currently supported filenames, I'd say that's a

Re: [Python-ideas] Adding an 'errors' argument to print

I took to using chcp 65001 This puts cmd.exe into unicode mode. Of course the python 3.6 make this uneccesary i understand. Barry > On 24 Mar 2017, at 15:41, Ryan Gonzalez wrote: > > Recently, I was working on a Windows GUI application that ends up running > ffmpeg, and I wanted to se

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

This is a better link: https://en.m.wikipedia.org/wiki/JSON_Streaming On Mar 27, 2017 3:45 PM, "David Mertz" wrote: > The format JSON lines (http://jsonlines.org/) is pretty widely used, but > is an extension of JSON itself. Basically, it's the idea that you can put > one object per physical lin

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

The format JSON lines (http://jsonlines.org/) is pretty widely used, but is an extension of JSON itself. Basically, it's the idea that you can put one object per physical line to allow incremental reading or spending of objects. It's a good idea, and I think the `json` module should support it. Bu

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 17:43, Bruce Leban wrote: > the ability to read one json object from the input rather than reading the > entire input Is this a well-defined idea? From a quick read of the JSON spec (which is remarkably short on details of how JSON is stored in files, etc) the only reference I

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On Mon, Mar 27, 2017 at 9:43 AM, Bruce Leban wrote: > I'm not in favor of this idea for the reason mentioned by many of the > other posters. BUT ... this does bring up something missing from json > readers: *the ability to read one json object from the input rather than > reading the entire input

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

I'm not in favor of this idea for the reason mentioned by many of the other posters. BUT ... this does bring up something missing from json readers: *the ability to read one json object from the input rather than reading the entire input* and attempting to interpret it as one object. For my use cas

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 03/27/2017 08:04 AM, Steven D'Aprano wrote: On Mon, Mar 27, 2017 at 02:50:38PM +0200, Ram Rachum wrote: What do you think about adding methods pathlib.Path.write_json and pathlib.Path.read_json , similar to write_text, write_bytes, read_text, read_bytes? That's not pathlib's responsibilit

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:48, Eric V. Smith wrote: > On 3/27/17 10:40 AM, Ram Rachum wrote: >> >> Another idea: Maybe make json.load and json.dump support Path objects? > > > json.dump requires open file objects, not strings or Paths representing > filenames. > > But does this not already do what you

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On 27.03.17 18:17, Simon D. wrote: After some french discussions about this idea, I subscribed here to suggest adding a new string litteral, for regexp, inspired by other types like : u"", r"", b"", br"", f""… The regexp string litteral could be represented by : re"" It would ease the use of re

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 3/27/17 10:40 AM, Ram Rachum wrote: Another idea: Maybe make json.load and json.dump support Path objects? json.dump requires open file objects, not strings or Paths representing filenames. But does this not already do what you want: Path('foo.json').write_text(json.dumps(obj)) ? Eric.

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On Mon, Mar 27, 2017 at 7:59 AM, Paul Moore wrote: > On 27 March 2017 at 15:40, Ram Rachum wrote: > > Another idea: Maybe make json.load and json.dump support Path objects? > > If they currently supported filenames, I'd say that's a reasonable > extension. Given that they don't, it still seems l

[Python-ideas] What about regexp string litterals : re".*" ?

Hello, After some french discussions about this idea, I subscribed here to suggest adding a new string litteral, for regexp, inspired by other types like : u"", r"", b"", br"", f""… The regexp string litteral could be represented by : re"" It would ease the use of regexps in Python, allowing to

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On Mon, Mar 27, 2017 at 02:50:38PM +0200, Ram Rachum wrote: > Hi guys, > > What do you think about adding methods pathlib.Path.write_json and > pathlib.Path.read_json , similar to write_text, write_bytes, read_text, > read_bytes? > > This would make writing / reading JSON to a file a one liner in

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:40, Ram Rachum wrote: > Another idea: Maybe make json.load and json.dump support Path objects? If they currently supported filenames, I'd say that's a reasonable extension. Given that they don't, it still seems like more effort than it's worth to save a few characters

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Another idea: Maybe make json.load and json.dump support Path objects? Much better. Or maybe add json.load_path and dump_path ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: ht

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27.03.17 15:50, Ram Rachum wrote: Hi guys, What do you think about adding methods pathlib.Path.write_json and pathlib.Path.read_json , similar to write_text, write_bytes, read_text, read_bytes? This would make writing / reading JSON to a file a one liner instead of a two-line with clause.

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

> On Mar 27, 2017, at 10:36 AM, Paul Moore wrote: > > On 27 March 2017 at 15:33, Donald Stufft > wrote: >> What do you think about adding methods pathlib.Path.write_json and >> pathlib.Path.read_json , similar to write_text, write_bytes, read_text, >> read_bytes? >> >>

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Another idea: Maybe make json.load and json.dump support Path objects? On Mon, Mar 27, 2017 at 4:36 PM, Paul Moore wrote: > On 27 March 2017 at 15:33, Donald Stufft wrote: > > What do you think about adding methods pathlib.Path.write_json and > > pathlib.Path.read_json , similar to write_text,

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:33, Donald Stufft wrote: > What do you think about adding methods pathlib.Path.write_json and > pathlib.Path.read_json , similar to write_text, write_bytes, read_text, > read_bytes? > > > > -1, I also think that write_* and read_* were mistakes to begin with. Text is (much)

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

> On Mar 27, 2017, at 8:50 AM, Ram Rachum wrote: > > What do you think about adding methods pathlib.Path.write_json and > pathlib.Path.read_json , similar to write_text, write_bytes, read_text, > read_bytes? > -1, I also think that write_* and read_* were mistakes to begin with. — Donald S

Re: [Python-ideas] Add pathlib.Path.write_json andpathlib.Path.read_json

-1, should we also include write_ini, write_yaml, etc? A class cannot account for everyone who wants to use it in different ways. On Mar 27, 2017 17:07, "Steve Dower" wrote: > It was enough of a benefit for text (and I never forget the argument order > for writing text to a file, unlike json.du

Re: [Python-ideas] Add pathlib.Path.write_json andpathlib.Path.read_json

It was enough of a benefit for text (and I never forget the argument order for writing text to a file, unlike json.dump(file_or_data?, data_or_file?) ) +1 Top-posted from my Windows Phone -Original Message- From: "Paul Moore" Sent: ‎3/‎27/‎2017 5:57 To: "Ram Rachum" Cc: "python-ideas"

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 13:50, Ram Rachum wrote: > This would make writing / reading JSON to a file a one liner instead of a > two-line with clause. That hardly seems like a significant benefit... Paul ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Oh, and also it saves you from having to import json. On Mon, Mar 27, 2017 at 2:50 PM, Ram Rachum wrote: > Hi guys, > > What do you think about adding methods pathlib.Path.write_json and > pathlib.Path.read_json , similar to write_text, write_bytes, read_text, > read_bytes? > > This would make w

[Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Hi guys, What do you think about adding methods pathlib.Path.write_json and pathlib.Path.read_json , similar to write_text, write_bytes, read_text, read_bytes? This would make writing / reading JSON to a file a one liner instead of a two-line with clause. Thanks, Ram. __

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

On 27 March 2017 at 10:54, Brice PARENT wrote: > I get it, but it's more a matter of perception. To me, the version I > described is just Python, while yours is Python + specific syntax. As this > syntax is only used in PyQL sub-language, it's not really Python any more... ... which is why I susp

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

Le 27/03/17 à 10:55, Pavel Velikhov a écrit : Hi Brice, On 27 Mar 2017, at 10:17, Brice PARENT > wrote: I prefer this a lot to the original syntax, and I really think this has much better chances to be integrated (if such an integration had to be done, and not kep

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

Hi Brice, > On 27 Mar 2017, at 10:17, Brice PARENT wrote: > > I prefer this a lot to the original syntax, and I really think this has much > better chances to be integrated (if such an integration had to be done, and > not kept as a separate module). > > Also, maybe managing this with classes