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

[Atsuo Ishimoto]

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 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 '${...}' is appearing, too. As I wrote, it was chosen 
> > for
> > implementation reasons. I'm open for other syntax options.
> >
> > I'm curious what you think about another way to construct dictionaries.
>
> Personally I just accept the repetition.  It doesn't generally happen
> often to me, and I'd much rather be explicit.
>
> --
> Rhodri James *-* Kynesim Ltd
___
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/GZODQ6CLBR6EXVOLYPGF65K6UUENMQ5T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

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" and is seamless.

It would become an impedance mismatch if it didn't include 'pprint'. But
what about my 'custom_print' I use occasionally...
___
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/UBZDXBZJE4HCS6ROVRDUZC2X7YWVGKNR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Goble]

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 removing the print function
-1 on parentheses-less function calls for anything else.
___
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/FKOI3W3U7NDOPKALJSVNYZXZN4QG6DVY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Dan Sommers]

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 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun  9 
2020, 16:31:17)

>>> print 2+2
4

But wait, there's more! The same syntax will make it possible 
to call *any* function:


>>> len "abc"
3
>>>

Or any method:

>>> import sys
>>> sys.getrefcount "abc"
24
>>>



A lot of people have been boo-hissing at this, but would it be
possible to restrict it to just simple or dotted names (you 
mentioned

that this part is possible), and only at the REPL? ...


I retrained my muscle memory moving from print to print().  I have 
almost zero use cases of passing end and sep to the function, 
although I did have a few cases of ending my print statements with 
a comma.  I still think that print makes a better statement than 
an expression or a function call; YMMV.  Okay, enough background.


I, too, thought about the convenience of not having to type the 
parentheses at the REPL, but then I can't paste my code from the 
REPL into my program, and that's no good at all.



len("93e8a1b2688b3fc0dc413c182273a14f5dbd39a23d7845d363c5f9b98283ecaaa7a642578afe55442b7a00ae4ce335c7"

... )
96

and I'm having to remember to put that close parenthesis on it, 
and it
doesn't up-arrow correctly, etc, etc. Would be convenient to use 
the

space syntax there.


Well, yeah, but that 
93e8a1b2688b3fc0dc413c182273a14f5dbd39a23d7845d363c5f9b98283ecaaa7a642578afe55442b7a00ae4ce335c7 
probably came from your clipboard (and it's still there, or still 
sitting in a terminal window, or ...), so even if you had to 
retype/paste the whole thing, it's not too bad.


And who has the time to retrain the "len" muscle memory *not* to 
type the parentheses?  ;-)

___
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/R6WBIQELBQVNV3K5DPKTOS76R3ZAS6FA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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, 
> 16:31:17)
> >>> print 2+2
> 4
>
> But wait, there's more! The same syntax will make it possible to call *any* 
> function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>

A lot of people have been boo-hissing at this, but would it be
possible to restrict it to just simple or dotted names (you mentioned
that this part is possible), and only at the REPL? I can think of a
lot of situations where I'd be doing something like:

>>> len("93e8a1b2688b3fc0dc413c182273a14f5dbd39a23d7845d363c5f9b98283ecaaa7a642578afe55442b7a00ae4ce335c7"
... )
96

and I'm having to remember to put that close parenthesis on it, and it
doesn't up-arrow correctly, etc, etc. Would be convenient to use the
space syntax there.

It wouldn't be appropriate to use a __future__ import if it isn't
intended to be brought in eventually, but the same kind of mechanism
would be an effective way to introduce this (instead of magically
recognizing a REPL, you just configure it to run the "from
__alternate__ import no_parens_calls" statement).

As a feature, it feels like the sort of thing that everyone's style
guides would frown on, but it'd be very convenient for quickly
scribbling stuff in the REPL.

ChrisA
___
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/IDXVTAYZQN5E5UKAMKEGOJS6VBU7IJUJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Crall]

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 readability. It makes things feel contained. For the print function it
seems less bad because there is only one argument and oftentimes it is
surrounded by quotes, which mitigates the lack of a buffer character. I
dread reading someone else's code that includes heavy usage of this pattern
for generic function calls.

In summary: "boo, hiss". For generic method calls I think this is a
terrible idea. However, I would seriously consider a special case grammar
change that only allows functions (or variables?) named "print" to be
called this way. I think this has benefits for backwards-compatibility,
although I will still personally use parens around my prints (because being
surrounded by parens looks so freakin' good) it wouldn't make me tear out
my hair out to see: `print x` in code reviews.

On Tue, Jun 9, 2020 at 8:09 PM Guido van Rossum  wrote:

> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> 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,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> >>> print 2+2
> 4
> >>> print "hello world"
> hello world
> >>> print "hello", input("Name:")
> Name:Guido
> hello Guido
> >>> print 1, 2, 3, sep=", "
> 1, 2, 3
> >>>
>
> But wait, there's more! The same syntax will make it possible to call
> *any* function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>
> Really, *any* method:
>
> >>> class C:
> ...   def foo(self, arg): print arg
> ...
> >>> C().foo 2+2
> 4
> >>>
>
> There are downsides too, though. For example, you can't call a method
> without arguments:
>
> >>> print
> 
> >>>
>
> Worse, the first argument cannot start with a parenthesis or bracket:
>
> >>> print (1, 2, 3)
> 1 2 3
> >>> C().foo (1, 2, 3)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: C.foo() takes 2 positional arguments but 4 were given
> >>> print (2+2), 42
> 4
> (None, 42)
> >>> C().foo [0]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'method' object is not subscriptable
> >>>
>
> No, it's not April 1st. I am seriously proposing this (but I'll withdraw
> it if the response is a resounding "boo, hiss"). After all, we currently
> have a bunch of complexity in the parser just to give a helpful error
> message to people used to Python 2's print statement:
>
> >>> print 1, 2, 3
>   File "", line 1
> print 1, 2, 3
>   ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1,
> 2, 3)?
> >>>
>
> And IIRC there have been a number of aborted attempts at syntactic hacks
> to allow people to call functions (like print) without parentheses,
> although (I think) none of them made it into a PEP. The PEG parser makes
> this much simpler, because it can simply backtrack -- by placing the
> grammar rule for this syntax (tentatively called "call statement") last in
> the list of alternatives for "small statement" we ensure that everything
> that's a valid expression statement (including print() calls) is still an
> expression statement with exactly the same meaning, while still allowing
> parameter-less function calls, without lexical hacks. (There is no code in
> my prototype that checks for a space after 'print' -- it just checks that
> there's a name, number or string following a name, which is never legal
> syntax.)
>
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype
> does not support things like this:
>
> >>> a = (len "abc")
>   File "", line 1
> a = (len "abc")
>  ^
> SyntaxError: invalid syntax
> >>>
>
> I think that strikes a reasonable balance between usability and reduced
> detection of common errors.
>
> I could also dial it back a bit, e.g. maybe it's too much to allow
> 'C().foo x' and we should only allow dotted names (sufficient to access
> functions in imported modules and method calls on variables). Or maybe we
> should only allow simple names (allowing 'len x' but disallowing
> 'sys.getrefcount x'. Or maybe we should really only bring back print
> statements.
>
> I believe there are some other languages that support a similar grammar
> (Ruby? R? Raku?) but I haven't investigated.
>
> Thoughts?
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: 

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

[Neil Girdhar]

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), None) \
as return_value_two:

but with parentheses instead of backslash continuations?

On Wednesday, June 10, 2020 at 12:55:01 PM UTC-4, Guido van Rossum wrote:
>
> 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 
> parser and realized that *if people wanted it* this would be easy to do. So 
> I spent a pleasant hour or two coding it up to my satisfaction.
>
> But I was also trying to satisfy some demand. When Python 3 was young, 
> print becoming a function  was one of the most frequent complaints, and 
> it's still occasionally seen on Twitter. I found at least two StackOverflow 
> issues about it, but the combined upvote count was less than 100.
>
> An early post in this thread reminded me that IPython has a feature called 
> "autocall" that allows exactly this syntax. I don't know how popular it is. 
> However, apparently there the form `f x+1` ends up calling `f("x+1")` (i.e. 
> stringifying the argument), so introducing similar syntax in Python with 
> different semantics would hardly be helpful. (If someone wants to start a 
> debate on argument quoting, please start a new thread, so we can lay this 
> one to rest.)
>
> All in all, it's clear that there's no future for this idea, and I will 
> happily withdraw it.
>
> -- 
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)* 
> 
>
___
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/GE2A256YFTMSSYOQLURCTKZZGL4ZQMG7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: url imports

[J. Pic]

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 interesting to protect Python users, but that would mean
having to specify the permissions of the lib, ie. it wouldn't be able to
write any file or start any kind of background process by default, unless
explicitly granted by your module.
___
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/QDNTQXZNWO6JX5DXDIE4D4MIW3SVW3BM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: url imports

[Caleb Donovick]

>  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 the package they are
authoring are?

>  we stick to, for every python script
> `abc = import("package", "2.*")`

I definitely don't want to worry about which version of a package I need at
a module level.

>  from imports could be done like
> `value = import("package", "1.*").value `

You might want to read about the difference between:

`from package import module`
and
`import package.module as module`

https://docs.python.org/3/reference/simple_stmts.html#the-import-statement

 >  this completely removes the virtualenvs issue

???
Virtuelenv is amazing.

>  and solves alot of problematic issues with python imports

???


On Wed, Jun 10, 2020 at 9:50 AM Aditya Shankar  wrote:

> 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 = import("package", "2.*")`
>
> from imports could be done like
>
> `value = import("package", "1.*").value `
>
> this completely removes the virtualenvs issue, and solves alot of
> problematic issues with python imports
> ___
> 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/FNQLJJMEDNPV3TWHVI6GFSEZWRUHY6M6/
> 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/4ZS55OHWNR4DKYLD3OFELIQ74ZACY2ME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

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 with objects that can't be patched during
runtime such as datetime (TypeError: can't set attributes of
built-in/extension type 'datetime.datetime') that you'd need to import from
that library instead of from datetime, it still brings value in making
serialization and deserialization into the versatile and popular JSON
format easier and more reusable than with the current object_hook, by
leveraging typical object oriented programing in a very boring way that
makes it easy for anyone to grasp.

The README looks like:

Instead of:

from json import loads, dumps
from uuid import UUID, uuid4

obj = uuid4()
encoded = dumps(str(obj))
decoded = UUID(loads(encoded))

assert obj == decoded

We can do:

from jsonlight import loads, dumps
from uuid import UUID, uuid4

obj = uuid4()
encoded = dumps(obj)
decoded = loads(UUID, encoded)
assert obj == decoded

This is because jsonlight patches uuid.UUID class to add the following
methods:

- ``__jsondump__``: return a representation of self with JSON data types
- ``__jsonload__``: instantiate an object based on the result from
__jsondump__

You can see that the main difference with ``json.loads`` is that
``jsonlight.loads`` requires a type as the first argument. This is because
``jsonlight.loads`` will first call ``json.loads`` to convert the string
into a
Python object with basic JSON types, and then pass that to the type's
``__jsonload__`` function.

Other types can't be monkey patched, so you have to import them from
jsonlight
instead, which is the sad case of datetime:

from jsonlight import loads, dumps, datetime
obj = datetime.now()
assert obj == loads(datetime, dumps(obj))

You may also define ``__jsondump__`` and ``__jsonload__`` methods on your
own
classes, example:

from jsonlight import load

class YourClass:
def __init__(self, uuid=None):
self.uuid = uuid or uuid4()

def __jsondump__(self):
return dict(uuid=self.uuid)

@classmethod
def __jsonload__(cls, data):
return cls(load(UUID, data['uuid'])

# This also works, but would not illustrate how to support
recursion
# return cls(UUID(data['uuid']))

As you can see:

- you don't have to worry about calling ``__jsondump__`` on return values of
  your own ``__jsondump__`` because ``jsonlight.dumps`` will do that
  recursively,
- you have full control on deserialization just like with ``__setstate__``,
but if
  you call jsonlight.load in there yourself then you don't have to duplicate
  deserialization logic or bother calling ``__jsonload__`` on nested
objects
  yourself,

Monkey-patched stdlib objects are:

- UUID
- Path

Feel free to add more.

Stdlib objects that couldn't be monkey patched, and that you have to import
from jsonlight instead are:

- datetime
___
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/PL3UN25ASVP5IDSAPK5RGYIBY6GKLWHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: url imports

[Brett Cannon]

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 the `import` statement isn't anything special
and everything it does is implemented in Python already.

On Wed, Jun 10, 2020 at 9:47 AM Aditya Shankar  wrote:

> 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 = import("package", "2.*")`
>
> from imports could be done like
>
> `value = import("package", "1.*").value `
>
> this completely removes the virtualenvs issue, and solves alot of
> problematic issues with python imports
> ___
> 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/FNQLJJMEDNPV3TWHVI6GFSEZWRUHY6M6/
> 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/ZHAAJF7ITYPMDGZUVLBZNI63UZKKIASW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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
parser and realized that *if people wanted it* this would be easy to do. So
I spent a pleasant hour or two coding it up to my satisfaction.

But I was also trying to satisfy some demand. When Python 3 was young,
print becoming a function  was one of the most frequent complaints, and
it's still occasionally seen on Twitter. I found at least two StackOverflow
issues about it, but the combined upvote count was less than 100.

An early post in this thread reminded me that IPython has a feature called
"autocall" that allows exactly this syntax. I don't know how popular it is.
However, apparently there the form `f x+1` ends up calling `f("x+1")` (i.e.
stringifying the argument), so introducing similar syntax in Python with
different semantics would hardly be helpful. (If someone wants to start a
debate on argument quoting, please start a new thread, so we can lay this
one to rest.)

All in all, it's clear that there's no future for this idea, and I will
happily withdraw it.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/6F2HDRNY5MU54HQAEI2V4AELQQ5EA3RN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] url imports

[Aditya Shankar]

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 = import("package", "2.*")`

from imports could be done like

`value = import("package", "1.*").value `

this completely removes the virtualenvs issue, and solves alot of problematic 
issues with python imports
___
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/FNQLJJMEDNPV3TWHVI6GFSEZWRUHY6M6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

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 limitations:

- these functions are limited to json types, which are rudimentary on one
hand but on the other it really seems like their current standard is here
to stay
- dict, list, set and other types that may contain different types would
not be able to do any type conversion, encoding list(UUID()) does not make
it possible to get the UUID type back in the decoded list object, unless
you implement your list subclass for example then it's up to you as a user

But with this limitations come the following advantages:

- you still have full control of deserialization logic in your own classes,
- it's easier than implementing an object_hook function because you don't
have to code a type detection logic: the class __jsonload__ should know
what type to apply on what attribute,
- serialization becomes easy to safen, good for users who don't care /
don't need anything particularly sophisticated - for which the current
hooks work,
- json is a popular format, PostgreSQL's JSON field is not the only really
enjoyable thing we can do with json,

Here's a simple example to illustrate:

from uuid import UUID, uuid4


class YourClass:
def __init__(self, uuid=None):
self.uuid = uuid or uuid4()

def __jsondump__(self):
return dict(uuid=str(self.uuid))
# if uuid has __jsondump__, then this would be possible too:
# return dict(uuid=self.uuid.__jsondump__())
#
# if the encoder would call __jsondump__ automatically, then this
would
# be enough:
# return dict(uuid=self.uuid)

@classmethod
def __jsonload__(cls, data):
return cls(UUID(data['uuid']))

def __eq__(self, other):
if isinstance(other, type(self)):
return other.uuid == self.uuid
return super().__eq__(other)


obj = YourClass()
encoded = obj.__jsondump__()
decoded = YourClass.__jsonload__(encoded)
assert obj == decoded

I'll try that in PyPi then (just have to monkey patch the stdlib objects),
if I find material to prove that it's worth the maintenance cost then I'll
come back with more.

Thank you very much for sharing some of your insight

Have a great day <3
___
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/ZHDEURKXYMXPKSNY722MN3WK7AQZZZ7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Dan Sommers]

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 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 and just transmit that string.  Why bother with JSON 
>> and

>> all of its verbosity and restrictions in the first place?
>>
>> If interoperability is a concern, then how much does this 
>> sort of

>> thing complicate your JSON and all of the other
>> producers/consumers?  Will their applications, standard 
>> libraries,

>> and best practices "just work"?
> What if it's to be produced and consumed by your app (so, no
> interoperability), but you want it to be human-readable and
> human-editable? JSON is pretty good for that.


Readable, yes.  Mostly.

Editable?  YMMV.

Both reading and writing definitely get worse, however, as soon as 
you have to add your own type annotations and sub-structures. 
Then again, I used to read/write/edit assembly language programs 
happily with ed, so all of this is fairly subjective.


True, but I don't think the stdlib needs to cater to that 
requirement

when there are hooks to write your own customizations.



I agree in general, but it might be worth having a few recipes 
in the
docs or something. Make it clear that the Python json module 
*can*
encode these kinds of things, but it's up to you as the app 
designer
to decide how (among a number of equally viable options) you 
want to

represent them.


Hooks and non-trivial examples in the documentation are both 
excellent.

___
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/JGJCX6MP7IJCWKCDJ2B5KLI4CWVPCZ66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Eric V. Smith]

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 
anything from the stdlib by default ? It really seems like it "almost 
got there".
My reason: because it's yet something else to maintain in the standard 
library, and doesn't add enough value to justify its existence and 
ongoing maintenance cost.


Perhaps the stdlib JSONEncoder could check for a new __json__ method 
on every object it serializes. Similar to __getstate__, __json__ 
should however return data that only contains json-compatible types. 
Then we could go on and add it for stdlib objects such as uuid and 
datetime, and have a rudimentary but failsafe json dumpsing function 
that works with any python object from the stdlib, as well as your own 
objects where you add a __json__ magic method.


There are many, many design decisions that would need to be made. Off 
the top of my head: what about recursive data structures? And basically 
every other decision ever made by pickle over the years.


My suggestion would be to write a package to do this yourself, then 
upload it to PyPI. I think functools.singledispatch would be a good 
building block.




> IMO, it's worse than that.

Agreed that JSON deserialization is a problem I would rather not even 
try to solve actually. Choosing what type to deserialize with seems 
like a problem that doesn't have an elegant solution:


- even with a schema: what if an attribute has different types within 
the same list, then the schema will not work or have to be complex
- storing the types into the encoded output like Pickle, but that 
changes the schema and might also be subject to the same security 
warnings that Pickle has


So, custom-typed deserialized doesn't look like something that could 
get in the stdlib.


That said, rudimentary and failsafe JSON serialization seems reachable 
and still useful.


I'd be even more opposed to a a "serialize but not deserialize" version 
going into the standard lib.


Eric

___
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/JLKVSEPS7PPAO4ETJ7GDMSVP3IKIL5N4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

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 and so on).


Yeah, I don't think '${...}' is appearing, too. As I wrote, it was chosen for
implementation reasons. I'm open for other syntax options.

I'm curious what you think about another way to construct dictionaries.


Personally I just accept the repetition.  It doesn't generally happen 
often to me, and I'd much rather be explicit.


--
Rhodri James *-* Kynesim Ltd
___
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/AOMGP7GFRYQREJVVF7ZIQCEALN2JH6MZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

> 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 really seems like it "almost got there".

Perhaps the stdlib JSONEncoder could check for a new __json__ method on
every object it serializes. Similar to __getstate__, __json__ should
however return data that only contains json-compatible types. Then we could
go on and add it for stdlib objects such as uuid and datetime, and have a
rudimentary but failsafe json dumpsing function that works with any python
object from the stdlib, as well as your own objects where you add a
__json__ magic method.

> IMO, it's worse than that.

Agreed that JSON deserialization is a problem I would rather not even try
to solve actually. Choosing what type to deserialize with seems like a
problem that doesn't have an elegant solution:

- even with a schema: what if an attribute has different types within the
same list, then the schema will not work or have to be complex
- storing the types into the encoded output like Pickle, but that changes
the schema and might also be subject to the same security warnings that
Pickle has

So, custom-typed deserialized doesn't look like something that could get in
the stdlib.

That said, rudimentary and failsafe JSON serialization seems reachable and
still useful.
___
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/EUA3ATHUVYI7RY27I4WJUME7BV473CQD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Atsuo Ishimoto]

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 inherit private credentials from the arguments, which
> need to be explicitly del'ed from d.

And in case of locals() is useful, the code may eventually become
unsafe someday later.

> I understand that this was done for ease of your POC implementatation,
> and you prefer a letter.  But I'd like to emphasize:  Please don't use
> $ for this.  Among other things, it is both in appearance and
> historically based on "S" for "set"!
>

I don't like it, either. But choice of valid letters are limited to
such as “$", "'" and "?".
So I think '$' is the best choice among these letters ;)

> Also, please use dict display syntax (':' not '=').
>

Ah, this is a typo. I use ':' in my implementation.

> If you're going to use prefix characters, I suggest 'd' for "dict",
> and maybe 's' for "set" as well (to allow the use case 's{}' for the
> empty set, though that's not terribly useful vs. set(). I'm mostly
> proposing it so I be the first to say "-1" on 's{}'. :-)
>

'd{}' would be a nice choice.
>
> It occurs to me there's an alternative syntax with even less notation:
>
> d = {'tel' : '123-456-789', first, last, addr1, addr2}
>

This is acceptable, but I prefer prefixed dict better.

Or, instead of prefixing a letter, we may be able to omit the key of
items inside dict display.

d = {:name, :addr, ’tel': '123-4567’}

Thoughts?
___
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/6Y3NSEBKALWJSB63MWMXRA6KTZ46CMD3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Atsuo Ishimoto]

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 '${...}' is appearing, too. As I wrote, it was chosen for
implementation reasons. I'm open for other syntax options.

I'm curious what you think about another way to construct dictionaries.
___
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/6GBBCMETAQ3GAG7C7I36STTYPYLD2OW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Chris Angelico]

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, then you may as well use pickle and base64
> >> (and an HMAC!) to convert your python data to an opaque ASCII
> >> string and just transmit that string.  Why bother with JSON and
> >> all of its verbosity and restrictions in the first place?
> >>
> >> If interoperability is a concern, then how much does this sort of
> >> thing complicate your JSON and all of the other
> >> producers/consumers?  Will their applications, standard libraries,
> >> and best practices "just work"?
> > What if it's to be produced and consumed by your app (so, no
> > interoperability), but you want it to be human-readable and
> > human-editable? JSON is pretty good for that.
>
> True, but I don't think the stdlib needs to cater to that requirement
> when there are hooks to write your own customizations.
>

I agree in general, but it might be worth having a few recipes in the
docs or something. Make it clear that the Python json module *can*
encode these kinds of things, but it's up to you as the app designer
to decide how (among a number of equally viable options) you want to
represent them.

ChrisA
___
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/WJ2RIM7HE7VIC7763AVYRUUIU2REAIOT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Eric V. Smith]

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 your python data to an opaque ASCII
string and just transmit that string.  Why bother with JSON and
all of its verbosity and restrictions in the first place?

If interoperability is a concern, then how much does this sort of
thing complicate your JSON and all of the other
producers/consumers?  Will their applications, standard libraries,
and best practices "just work"?

What if it's to be produced and consumed by your app (so, no
interoperability), but you want it to be human-readable and
human-editable? JSON is pretty good for that.


True, but I don't think the stdlib needs to cater to that requirement 
when there are hooks to write your own customizations.


Eric
___
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/3DMKTT3OHDXDVKRVDI2XFPJHEWXQRLPH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

> 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 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/5L2VCMD3GY4GEHU6X3HCPRKRU3Q5EXM6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brandt Bucher]

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

[Python-ideas] Re: JSON Serializing UUID objects

[Chris Angelico]

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 and just transmit that string.  Why bother with JSON and
> all of its verbosity and restrictions in the first place?
>
> If interoperability is a concern, then how much does this sort of
> thing complicate your JSON and all of the other
> producers/consumers?  Will their applications, standard libraries,
> and best practices "just work"?

What if it's to be produced and consumed by your app (so, no
interoperability), but you want it to be human-readable and
human-editable? JSON is pretty good for that.

ChrisA
___
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/3UGLWJADP4FRGK7NQ76ZT5JY4GOXWKCE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Dan Sommers]

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, but if you use it then any object 
from the

python standard library will just work.



I think a JSONEncoder for standard types would be nice to have.


Perhaps.

A JSONDecoder is much more complicated. What would it do? 
Convert every string that looks like an ISO datetime into a 
Python datetime object? Or convert objects like `{"type": 
"datetime", "value": "2020-01-01T12:34:56"}`?


IMO, it's worse than that.

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 and just transmit that string.  Why bother with JSON and 
all of its verbosity and restrictions in the first place?


If interoperability is a concern, then how much does this sort of 
thing complicate your JSON and all of the other 
producers/consumers?  Will their applications, standard libraries, 
and best practices "just work"?

___
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/MTHCMJZJCZWF547AYHJOHGBSNQENGTWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Eric V. Smith]

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 optional to use, but if you use it then any object
from the python standard library will just work.


I think a JSONEncoder for standard types would be nice to have.

 A JSONDecoder is much more complicated. What would it do? Convert 
every string that looks like an ISO datetime into a Python datetime 
object? Or convert objects like `{"type": "datetime", "value": 
"2020-01-01T12:34:56"}`?


The general problem here is that if you're encoding things for a 
non-python program to use, you can't do something non-standard like the 
above. And if you're looking for something that only other python 
programs can use, you're better off using pickle or some other non-JSON 
format.


That's why these ideas never result in any changes to the stdlib json 
library.


Eric

___
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/7HND6Y6YWTZET5C2ZYPFZNSC6DNIXSYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Bar Harel]

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  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 library will just work.
> ___
> 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/C3IW6RMZYKI36XLUZCARL4QX3ENKNLDU/
> 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/WJW7WNBE6BPNFPU7YRUCPPD2NXTWIM6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Alex Hall]

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 many existing libraries. You might like one of my recent
projects:

https://github.com/alexmojaki/datafunctions

or:

https://pydantic-docs.helpmanual.io/
https://github.com/lidatong/dataclasses-json

https://github.com/ltworf/typedload/
___
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/OK6D6VLH7ZPAUOHU3TLHWFVVBIBUNUZI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

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
enough.
___
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/L4AMRUI45LPJJAYGDEUKDOKXC7XSQ3FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[Alex Hall]

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 library will just work.
>

I think a JSONEncoder for standard types would be nice to have.

 A JSONDecoder is much more complicated. What would it do? Convert every
string that looks like an ISO datetime into a Python datetime object? Or
convert objects like `{"type": "datetime", "value": "2020-01-01T12:34:56"}`?
___
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/M2PASBYUD33C45ZADZWPKYOSVE5FSMFS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: JSON Serializing UUID objects

[J. Pic]

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

[Python-ideas] Re: JSON Serializing UUID objects

[Pablo Alcain]

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 serialization, something like
json.dumps(object, method=str) (don't know if that is an option at the
moment)

On Wed, Jun 10, 2020 at 9:19 AM J. Pic  wrote:

> 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 == uuid.UUID(str(example))
> True
>
> But are not serializable out of the box:
>
> >>> json.dumps(example)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3.8/json/__init__.py", line 231, in dumps
> return _default_encoder.encode(obj)
>   File "/usr/lib/python3.8/json/encoder.py", line 199, in encode
> chunks = self.iterencode(o, _one_shot=True)
>   File "/usr/lib/python3.8/json/encoder.py", line 257, in iterencode
> return _iterencode(o, 0)
>   File "/usr/lib/python3.8/json/encoder.py", line 179, in default
> raise TypeError(f'Object of type {o.__class__.__name__} '
> TypeError: Object of type UUID is not JSON serializable
>
> Wouldn't it be pythonically possible to make this work out of the box,
> without going through the string typecasting ?
>
> If that discussion goes well perhaps we can also talk about datetimes ...
> I know there's nothing about datetime formats in the json specification,
> that users are free to choose, but could we choose a standard format by
> default that would just work for people who don't care about the format
> they want.
>
> Thank you in advance for your replies
>
> Have a great day
>
> --
> ∞
> ___
> 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/W23G6CWWXPCB3L5M2UGGLOEALO5WN4IN/
> 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/NFYCQGEQ7R7MHCNVGP5WXHXRIJN7LN52/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Derrick Joseph via Python-ideas]

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 similar grammar 
>> (Ruby? R? Raku?) but I haven't investigated.
>
> Lua has a similar feature: a name (including a dotted name or index[ing], 
> which are identical in Lua) immediately followed by a string literal or table 
> literal is syntactic sugar for calling the named function/callable with that 
> string or table as its only argument. This is commonly used with print() and 
> require(), and also is sometimes used (with table literals) to simulate 
> calling a function with named arguments.
>
> Lua allows this to be chained: for example, the line `require "math" "test"` 
> is the same as `require("math")("test")`, calling the result of 
> `require("math") with the argument "test". (Incidentally, `require "math"` 
> returns a non-callable table, so actually running that will generate an error 
> message saying "attempt to call a table value". So it's a bad example, but 
> there are legitimate use cases for this.)
>
> However, Lua only supports this for single arguments (two or more require the 
> parentheses) and only for an argument that is a string literal or table 
> literal, nothing else (in particular, numbers and names require the 
> parentheses).___
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/BN7UNBLJNF2O5X2JHM2BOUJBKPIY7MBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] JSON Serializing UUID objects

[J. Pic]

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 == uuid.UUID(str(example))
True

But are not serializable out of the box:

>>> json.dumps(example)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/json/__init__.py", line 231, in dumps
return _default_encoder.encode(obj)
  File "/usr/lib/python3.8/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.8/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
  File "/usr/lib/python3.8/json/encoder.py", line 179, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type UUID is not JSON serializable

Wouldn't it be pythonically possible to make this work out of the box,
without going through the string typecasting ?

If that discussion goes well perhaps we can also talk about datetimes ... I
know there's nothing about datetime formats in the json specification, that
users are free to choose, but could we choose a standard format by default
that would just work for people who don't care about the format they want.

Thank you in advance for your replies

Have a great day

-- 
∞
___
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/W23G6CWWXPCB3L5M2UGGLOEALO5WN4IN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PYTHONLOGGING env variable

[Bar Harel]

>
> 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 messages to the default fallback.

In other words, the current best practice mentioned by the Python docs
(which I personally believe is good) prevents you from seeing errors if the
root logger wasn't set up correctly, or set up at all.

Even if they don't send it to NullHandler, log messages below warning level
aren't displayed by default.

With my proposal you'd be able to see everything with 1 simple flag, no
matter the configuration. It could have saved me, and probably other
developers as well, lots of time.

Regarding your request for an example, this won't change anything from the
point of view of the library creator.
As for the library user, he can continue as he does, knowing that in case
there's ever a hard-to-figure bug he can turn on that flag together with
-Xdev and have an easier time figuring things out.
It's also useful for external developers tackling code that is not theirs.
They can give themselves a guarantee that no matter the script, if it logs,
it'll show.


Keep in mind developers can also use it for cases where they don't set up
the logging, as a permanent replacement for basicConfig, but I believe it's
not a best practice for many reasons.

Bar
___
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/RSB7M7YLCEPYJFFXU24X7YSEVPGQI2HC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rhodri James]

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 environments driving test 
equipment, but I find it gets really hard to read surprisingly quickly.


--
Rhodri James *-* Kynesim Ltd
___
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/CDHCDQIYD4YQDMGMNFHDZURIQ2UL7OOS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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
> assert condition
>
> I know that they are special syntactic forms, even if I'm reading code
> using some new statement I had missed learning about:
>
> # Python 7 code, fallen through a wormhole
> require thing
> demand permission
> spam contacts
> verb object
>
> I don't think we should give up that nice clean distinction between
> function calls which always require parens, and statements which don't
> require parens, merely to add a second way to call functions that saves
> one char:

Agreed.

On Wed, 10 Jun 2020 at 08:47, Serhiy Storchaka  wrote:
>
> 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 part of
> programming culture for these languages, and Python is built on very
> different (and often opposite) design principles.

Also agreed.

There are languages with parenthesis-less function calls. They are
typically languages with a strong emphasis and cultural bias for
building DSLs using the language. Python, though, has always resisted
such "build your own DSL" styles, and any attempt to write code in
such a style looks out of place. While it wouldn't be impossible to
alter that bias, it would be quite a significant culture shift, and
I'd be surprised if it came without pain (I can imagine new libraries
written with the intention of being used "DSL style" being awkward to
use from "function style" code).

On the other hand, paren-less calls *in a REPL* are more common, and
probably more comfortable (e.g., things like IPython's magic syntax).
Whether this is something that could be implemented *only* in the
REPL, I don't know (probably not - things like the `code` module would
need to be able to support it as well) but that might be a
possibility. It's certainly the only place where I feel that
paren-less calls look OK *for Python*.

Paul
___
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/25DEADPQVGZCGZXPLF5WX2FSP36HBBWZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

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) items.
 > 
 > Be careful with this assumption. Python's dictionaries DO retain
 > order,

Thank you for the reminder!  I did forget that point.

 > even if you can't easily talk about "the fifth element" [1], so
 > anything that imposes requirements on the entry listed
 > syntactically first may have consequences.

No requirements imposed!  If iteration order matters and you want to
take advantage of abbreviation, you might have to write

d = {first : first, last, addr1, addr2, tel='123-456-789'}

but frequently it would just work naturally:

d = {first : first, last, addr1, addr2}

Admittedly this distinction may be even more subtle than grit on Tim's
screen, or randomizing the hash seed per process.  And I suspect that
people who want this feature will prefer the d{} notation for
consistency inside the braces.

Steve
___
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/ENXYVRXOAEOBWHN6SQK5K4IJUTRHHXLB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 part of 
programming culture for these languages, and Python is built on very 
different (and often opposite) design principles.


Who it will help? Will it help to translate old code from Python 2? Not 
at all, because of many differences in syntax. Will it help beginners? 
Not at all, it will make learning Python harder because of more complex 
rules and weird special cases. Will it help professional Python 
programmers? Not at all, they will need to learn new rules for uncommon 
syntax which they are not able to use for many years due to 
compatibility with older Python versions. Also it will add a headache 
when modify code (add parentheses for the first argument or reformatiing 
the code in multiple lines). Saving one key press is not worth it. Will 
it help programmers experienced in other programming languages? Not at 
all, because of multiple subtle differences between different languages. 
Looks it will make Python worse for everybody.



After all, we currently have a bunch of complexity in the parser just to give a 
helpful error message to people used to Python 2's print statement:


And the proposed feature will be incompatible with this error message. 
So we will lost a helpful error message too.

___
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/4EQD7O5RZ7VM5HYCJNORWXS7O5POLHAI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 parens.

Ruby allows parens-less function calls. Run this in Ruby and weep:

#!/usr/bin/ruby
def a(x=4)
x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"


For those who don't have Ruby installed, here is the output:

a + b => 7
a+b   => 7
a+ b  => 7
a +b  => 3

In case it's not obvious, the problem isn't the call to print, but the 
call to function `a`. (Tested in Ruby 2.5).

There's also yet another precedence rule to learn:

sqrt x + 1

means what?

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
assert condition

I know that they are special syntactic forms, even if I'm reading code 
using some new statement I had missed learning about:

# Python 7 code, fallen through a wormhole
require thing
demand permission
spam contacts
verb object

I don't think we should give up that nice clean distinction between 
function calls which always require parens, and statements which don't 
require parens, merely to add a second way to call functions that saves 
one char:

func(x)
func x

I'd be more interested in the idea if there was more benefit than just 
the avoidance of a pair of parens. Something that either can't be done 
at all, or can only be done with difficulty. Something like IPython's 
%magic syntax perhaps?



-- 
Steven
___
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/WG3NCEQX7CIEEGHHWJQFLOWVBJ7UQQC6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 careful with this assumption. Python's dictionaries DO retain
order, even if you can't easily talk about "the fifth element" [1], so
anything that imposes requirements on the entry listed syntactically
first may have consequences.

ChrisA

[1] which, as we all know, is Boron
___
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/EMT5JC5K6JCME5U6HKOWD3XBTHZEBFSD/
Code of Conduct: http://python.org/psf/codeofconduct/