[Python-ideas] Re: New syntax for dict literals

Thank you. It unfortunately happens to me mostly while I'm working for REST web servers, especially when writing JSON in the test suites for the app. 2020年6月11日(木) 1:24 Rhodri James : > > On 10/06/2020 16:38, Atsuo Ishimoto wrote: > > Hi > > Thank you for comments > > > > 2020年6月10日(水) 0:11

[Python-ideas] Re: Bringing the print statement back

On Wed, Jun 10, 2020, 8:04 PM Jonathan Crall wrote: > I wouldn't mind if this *only *worked for the specific characters > "print". > I often swap out 'print' for 'pprint', depending on the presentation I'm assuming for. Obviously, I need a 'from pprint import pprint' earlier. It "just works"

[Python-ideas] Re: Bringing the print statement back

After thinking about it for a day, my opinions are: +1 for the limited idea of bringing back the print statement with positional arguments only, as syntactic sugar (and not a replacement) for the print function +0 on a print statement with keyword arguments (again, as syntactic sugar) -1 on

[Python-ideas] Re: Bringing the print statement back

On Wednesday, June 10, 2020, at 19:14 -0500, Chris Angelico wrote: On Wed, Jun 10, 2020 at 10:08 AM Guido van Rossum wrote: One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python

[Python-ideas] Re: Bringing the print statement back

On Wed, Jun 10, 2020 at 10:08 AM Guido van Rossum wrote: > One thing that the PEG parser makes possible in about 20 lines of code is > something not entirely different from the old print statement. I have a > prototype: > > Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020,

[Python-ideas] Re: Bringing the print statement back

I wouldn't mind if this *only *worked for the specific characters "print". However, I think that allowing developers to call complex methods without parentheses will lead to very difficult to read code.I think that surrounding arguments with non-whitespace buffer characters is important for

[Python-ideas] Re: Bringing the print statement back

Nevertheless, it's nice to see how powerful the new parser is! Any chance this would allow us to have a multi-line with statement? with self.context_manager_one(some, parameters, that, are, passed) \ as return_value_one, \ self.context_manager_two(self.p, slice(None),

[Python-ideas] Re: url imports

What if you want to import a lib in two different scripts, would you have to call your import function with the given version (and permissions I suppose, if you want to follow Deno's path) every time ? IMHO, being able to set the permissions of an imported library like Deno does could be

[Python-ideas] Re: url imports

> i.e. instead of > `pip install package` > and > `import package` > and > `pip freeze > requirements.txt` > for every import, I am unclear on what you mean by "for every import". I have never once done this and I maintain half a dozen packages. Do people really not know what the requirements of

[Python-ideas] Re: JSON Serializing UUID objects

I published a lib on PyPi that does that, which pushed to write a complete readme, that I will reproduce here if anybody is interested in more discussion about this, along with my conclusions: Overall, it seems like the cost of maintenance is going to be insignificant. While the value is reduced

[Python-ideas] Re: url imports

Do note that is not as easy as it seems as you would have to figure out how to manage dependencies appropriately, especially if you are going to support using different versions at the same time. Otherwise you could write your own function today to see if you can get a proof-of-concept working as

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 9, 2020 at 6:33 PM Greg Ewing wrote: > Why is this being proposed? > > I think we would need a very strong reason to consider this, > and so far I haven't seen any justification other than "because > we can". > There was definitely something of that... I was looking at the new PEG

[Python-ideas] url imports

it'd be really cool if we could drop virtualenvs + requirements.txt altogether, i.e., like deno, mordern javascript and so... i.e. instead of `pip install package` and `import package` and `pip freeze > requirements.txt` for every import, we stick to, for every python script `abc =

[Python-ideas] Re: JSON Serializing UUID objects

Or, there might be a way to get the best of both worlds. Consider this silly example: encoded = yourobject.__jsondump__() # this should work yourobject == YourClass.__jsonload__(encoded) Basically very similar to __getstate__ and __setstate__ with pickle, with the following

[Python-ideas] Re: JSON Serializing UUID objects

On Wednesday, June 10, 2020, at 10:37 -0500, Chris Angelico wrote: On Thu, Jun 11, 2020 at 1:35 AM Eric V. Smith wrote: On 6/10/2020 11:00 AM, Chris Angelico wrote: > On Thu, Jun 11, 2020 at 12:45 AM Dan Sommers > <2qdxy4rzwzuui...@potatochowder.com> wrote: >> If you control both the

[Python-ideas] Re: JSON Serializing UUID objects

On 6/10/2020 11:59 AM, J. Pic wrote: > I don't think the stdlib needs to cater to that requirement > when there are hooks to write your own customizations. If the stdlib offers such hooks, as well as objects that don't serialize by default, why not ship a usable hook that would serialize

[Python-ideas] Re: New syntax for dict literals

On 10/06/2020 16:38, Atsuo Ishimoto wrote: Hi Thank you for comments 2020年6月10日(水) 0:11 Rhodri James : Python is not Perl. By that I mean Python in general tends not to use non-alphanumeric symbols unless they already have a well established meaning (such as quote marks, arithmetic operators

[Python-ideas] Re: JSON Serializing UUID objects

> I don't think the stdlib needs to cater to that requirement > when there are hooks to write your own customizations. If the stdlib offers such hooks, as well as objects that don't serialize by default, why not ship a usable hook that would serialize anything from the stdlib by default ? It

[Python-ideas] Re: New syntax for dict literals

Hi Thank you for comments 2020年6月10日(水) 12:12 Stephen J. Turnbull : > DTRTs. How often would locals() be usable in this way? Note: in the > case of requests, this might be a vulnerability, because the explicit > dict display would presumably include only relevant items, while > locals() might

[Python-ideas] Re: New syntax for dict literals

Hi Thank you for comments 2020年6月10日(水) 0:11 Rhodri James : > > Python is not Perl. By that I mean Python in general tends not to use > non-alphanumeric symbols unless they already have a well established > meaning (such as quote marks, arithmetic operators and so on). Yeah, I don't think

[Python-ideas] Re: JSON Serializing UUID objects

On Thu, Jun 11, 2020 at 1:35 AM Eric V. Smith wrote: > > On 6/10/2020 11:00 AM, Chris Angelico wrote: > > On Thu, Jun 11, 2020 at 12:45 AM Dan Sommers > > <2qdxy4rzwzuui...@potatochowder.com> wrote: > >> If you control both the producers and the consumers, and they're > >> both written in Python,

[Python-ideas] Re: JSON Serializing UUID objects

On 6/10/2020 11:00 AM, Chris Angelico wrote: On Thu, Jun 11, 2020 at 12:45 AM Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: If you control both the producers and the consumers, and they're both written in Python, then you may as well use pickle and base64 (and an HMAC!) to convert

[Python-ideas] Re: JSON Serializing UUID objects

> Why bother with JSON and all of its verbosity and restrictions in the first place? Well PostgreSQL offers query abilities on JSON fields nowadays, so that's the reason I've been migrating stuff from pickle to json, because then I can query on the data.

[Python-ideas] Re: Bringing the print statement back

Eh, I find that readability suffers in most of the examples shown. Let's save this for custom infix operators or something. That seems like a much more interesting discussion to me. ___ Python-ideas mailing list -- python-ideas@python.org To

[Python-ideas] Re: JSON Serializing UUID objects

On Thu, Jun 11, 2020 at 12:45 AM Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > If you control both the producers and the consumers, and they're > both written in Python, then you may as well use pickle and base64 > (and an HMAC!) to convert your python data to an opaque ASCII > string

[Python-ideas] Re: JSON Serializing UUID objects

On Wednesday, June 10, 2020, at 08:48 -0500, Alex Hall wrote: On Wed, Jun 10, 2020 at 3:42 PM J. Pic wrote: I understand, do you think the python standard library should provide a JSONEncoder and JSONDecoder that supports python standard library objects ? It would be optional to use,

[Python-ideas] Re: JSON Serializing UUID objects

On 6/10/2020 9:48 AM, Alex Hall wrote: On Wed, Jun 10, 2020 at 3:42 PM J. Pic > wrote: I understand, do you think the python standard library should provide a JSONEncoder and JSONDecoder that supports python standard library objects ? It would be

[Python-ideas] Re: JSON Serializing UUID objects

Since there's no standard for this in json, deciding to serialize to str is quite arbitrary. I personally serialize UUIDs to binary data as it takes less space. Some serialize it to hexadecimal. Tbh, it sounds like a good idea but can have it's pitfalls. On Wed, Jun 10, 2020, 4:43 PM J. Pic

[Python-ideas] Re: JSON Serializing UUID objects

On Wed, Jun 10, 2020 at 4:09 PM J. Pic wrote: > Good point, but then I'm not sure the decoder could be used for untrusted > json anymore. > > Another solution would be to generate a schema in a separate variable, > which would represent the JSON structure with Python types. > For that there are

[Python-ideas] Re: JSON Serializing UUID objects

Good point, but then I'm not sure the decoder could be used for untrusted json anymore. Another solution would be to generate a schema in a separate variable, which would represent the JSON structure with Python types. Also, there's still simple regexp pattern matching that could also be good

[Python-ideas] Re: JSON Serializing UUID objects

On Wed, Jun 10, 2020 at 3:42 PM J. Pic wrote: > I understand, do you think the python standard library should provide a > JSONEncoder and JSONDecoder that supports python standard library objects ? > > It would be optional to use, but if you use it then any object from the > python standard

[Python-ideas] Re: JSON Serializing UUID objects

I understand, do you think the python standard library should provide a JSONEncoder and JSONDecoder that supports python standard library objects ? It would be optional to use, but if you use it then any object from the python standard library will just work.

[Python-ideas] Re: JSON Serializing UUID objects

I don't know how or even whether this would be possible ootb. On one side, I do really like the idea; on the other hand, it kind of seems like going down a bumpy road (as you said, datetimes? filepaths?urls?). And the de-serialization would not be easy. What if we added a function call for the

[Python-ideas] Re: Bringing the print statement back

Hi, Just curious, why would bringing back Python 2’s print statement be a good idea? Warm Regards, Sadhana Srinivasan On Wed, Jun 10, 2020 at 2:39 AM, Jonathan Goble wrote: > On Tue, Jun 9, 2020 at 8:08 PM Guido van Rossum wrote: > >> I believe there are some other languages that support a

[Python-ideas] JSON Serializing UUID objects

Hi all, This is a proposal to enable uuid objects serialization / deserialization by the json module out of the box. UUID objects cast to string: >>> example = uuid.uuid4() >>> str(example) 'b8bcbfaa-d54f-4f33-9d7e-c91e38bb1b63' The can be casted from string: >>> example ==

[Python-ideas] Re: PYTHONLOGGING env variable

> > But if the libraries are already doing logging, can't I already do that? > > And if the libraries aren't doing logging, this won't magically add > logging to them, will it? > As a best practice, libraries log into a NullHandler to avoid setting up the root logger, and to prevent sending

[Python-ideas] Re: Bringing the print statement back

On 10/06/2020 01:06, Guido van Rossum wrote: print 2+2 4 print "hello world" hello world Bearing in mind that I'm a reactionary old curmudgeon who hates change, this gets a tepid -0.5 from me. It put me in mind of Tcl. Now I don't use Tcl a lot, and mostly that's in convoluted

[Python-ideas] Re: Bringing the print statement back

On Wed, 10 Jun 2020 at 08:30, Steven D'Aprano wrote: > Given Python's execution model where we have statements and functions, I > think that it is a feature that they have different syntax. If I see > words separated by spaces: > > import math > del spam > while condition > if obj

[Python-ideas] Re: New syntax for dict literals

Chris Angelico writes: > On Wed, Jun 10, 2020 at 1:15 PM Stephen J. Turnbull > wrote: > > > > Executive summary: > > > > Dicts are unordered, so we can distinguish dict from set by the first > > item (no new notation), and after that default identifiers to (name : > > in-scope value)

[Python-ideas] Re: Bringing the print statement back

10.06.20 03:06, Guido van Rossum пише: No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). Well you have my "boo, hiss". I like programming languages which have such feature, but they have it from start, it is an integral

[Python-ideas] Re: Bringing the print statement back

On Tue, Jun 09, 2020 at 05:06:37PM -0700, Guido van Rossum wrote: > But wait, there's more! The same syntax will make it possible to call *any* > function: > > >>> len "abc" > 3 As you point out later on, there are issues with zero-argument calls and calls where the first argument starts with

[Python-ideas] Re: New syntax for dict literals

On Wed, Jun 10, 2020 at 1:15 PM Stephen J. Turnbull wrote: > > Executive summary: > > Dicts are unordered, so we can distinguish dict from set by the first > item (no new notation), and after that default identifiers to (name : > in-scope value) items. Also some notational bikeshedding. Be