[Python-ideas] Re: Live variable analysis -> earlier release?

This would almost certainly break my code. As a DSL developer I do a lot of (exec | eval | introspection | ... ) shenanigans, that would make doing liveness analysis undecidable. On Wed, Apr 8, 2020 at 10:51 AM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Apr 8, 2020,

[Python-ideas] Re: Optimize out unused variables

I like the idea of formalizing "unused variables". How about having a syntax for it? Allowing a "." instead of an identifier to signify this behaviour [reusing Serhiy's examples]: head, ., rest = path.partition('/') first, second, *. = line.split() for . in range(10): ... [k for k, . in pairs]

[Python-ideas] Re: Improvement: __json__

In trying to do this (again), I've realized that you *can't* just check for hasattr(obj, '__json__') in a JSONEncoder.default method because default only get's called for types it doesn't know how to serialize; so if you e.g. subclass a dict, default() never gets called for the dict subclass.

[Python-ideas] Re: Optimize out unused variables

On Apr 8, 2020, at 10:59, Serhiy Storchaka wrote: > > I doubted whether or not to write, but since Guido has already touched a > similar topic (see "Live variable analysis -> earlier release"), so will I > write. > > It is common to assign some values which are never used to variables

[Python-ideas] Re: Improvement: __json__

I think that we should support the linked data use case with at least: 1. a __json__(obj, spec=None) method and 2. a more-easily modifiable make_iterencode/iterencode implementation in the json module of the standard library. On Wed, Apr 8, 2020 at 5:00 PM Andrew Barnert wrote: > On Apr 8,

[Python-ideas] Re: Improvement: __json__

On Apr 8, 2020, at 12:55, Wes Turner wrote: > > We should welcome efforts to support linked data in Python. Fine, but that’s doesn’t meant we should derail every proposal that has anything to do with JSON by turning it into a proposal for linked data, or consider a useful proposal to be

[Python-ideas] Re: Improvement: __json__

I'm aware of a couple Python implementations of JSON-LD: pyld [1] and rdflib-jsonld [2]. But you don't need a JSON-LD parser to parse or produce JSON-LD: You can just frame the data in the json document correctly such that other tools can easily parse your necessarily complex data types stored

[Python-ideas] Re: Improvement: __json__

On Apr 8, 2020, at 01:18, Wes Turner wrote: > > I don't see the value in using JSON to round-trip from Python to the same > Python code. > > External schema is far more useful than embedding part of an ad-hoc nested > object schema in type annotations that can't also do or even specify data

[Python-ideas] Re: Improvement: __json__

On Wed, Apr 8, 2020 at 1:18 AM Wes Turner wrote: > > I don't see the value in using JSON to round-trip from Python to the same > Python code. > There is a bit of a value: it's a human-readable format that matches the Python Data model pretty well. I've used it for that reason. Maybe I should be

[Python-ideas] Optimize out unused variables

I doubted whether or not to write, but since Guido has already touched a similar topic (see "Live variable analysis -> earlier release"), so will I write. It is common to assign some values which are never used to variables because the syntax demands this. For example: head, _, rest =

[Python-ideas] Re: Live variable analysis -> earlier release?

On Apr 8, 2020, at 09:57, Guido van Rossum wrote: > >  > Look at the following code. > > def foo(a, b): > x = a + b > if not x: > return None > sleep(1) # A calculation that does not use x > return a*b > > This code DECREFs x when the frame is exited (at the return

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, Apr 8, 2020 at 10:23 AM Guido van Rossum wrote: > On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote: > >> This would break uses of locals(), e.g. >> > > Hm, okay, so suppose the code analysis was good enough to recognize most > un-obfuscated uses of locals(), exec() and eval() (and

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, Apr 8, 2020 at 10:21 AM Guido van Rossum wrote: > On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote: > >> This would break uses of locals(), e.g. >> > > Hm, okay, so suppose the code analysis was good enough to recognize most > un-obfuscated uses of locals(), exec() and eval() (and

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, 8 Apr 2020 10:18:47 -0700 Guido van Rossum wrote: > > > But when I leave "large" temp objects hanging and > > give a rip, I already stick in "del" statements anyway. Very rarely, > > but it happens. > > > > I recall that in the development of asyncio there were a few places where >

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, Apr 8, 2020 at 10:13 AM Tim Peters wrote: > My guess: it would overwhelmingly free tiny objects, giving a > literally unmeasurable (just theoretically provable) memory savings, > at the cost of adding extra trips around the eval loop. So not really > attractive to me. Yeah, the extra

[Python-ideas] Re: Live variable analysis -> earlier release?

On 2020-04-08 17:53, Guido van Rossum wrote: Look at the following code. def foo(a, b):     x = a + b     if not x:     return None     sleep(1)  # A calculation that does not use x     return a*b This code DECREFs x when the frame is exited (at the return statement). But (assuming)

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote: > This would break uses of locals(), e.g. > Hm, okay, so suppose the code analysis was good enough to recognize most un-obfuscated uses of locals(), exec() and eval() (and presumably sys._getframe() -- IIUC there's already a Python implementation

[Python-ideas] Re: Live variable analysis -> earlier release?

On Wed, 8 Apr 2020 09:53:41 -0700 Guido van Rossum wrote: > Look at the following code. > > def foo(a, b): > x = a + b > if not x: > return None > sleep(1) # A calculation that does not use x > return a*b > > This code DECREFs x when the frame is exited (at the return

[Python-ideas] Re: Live variable analysis -> earlier release?

[Guido] > Look at the following code. > > def foo(a, b): > x = a + b > if not x: > return None > sleep(1) # A calculation that does not use x > return a*b > > This code DECREFs x when the frame is exited (at the return statement). > But (assuming) we can clearly see that x

[Python-ideas] Re: Live variable analysis -> earlier release?

This would break uses of locals(), e.g. def foo(a, b): x = a + b if not x: return None del x print('{x}, {a}, {b}'.format(**locals())) return a * b foo(1, 2) Plus if the calculation raises an exception and I'm looking at the report on Sentry, I'd like to see the

[Python-ideas] Re: Live variable analysis -> earlier release?

> Can anyone tear this idea apart? `exec` and `eval` come to mind... I'm sure there are also nasty `inspect` hacks this could break, too? def foo(a, b): x = a + b if not x: return None sleep(1) # A calculation that does not use x return eval("x")

[Python-ideas] Live variable analysis -> earlier release?

Look at the following code. def foo(a, b): x = a + b if not x: return None sleep(1) # A calculation that does not use x return a*b This code DECREFs x when the frame is exited (at the return statement). But (assuming) we can clearly see that x is not needed during the

[Python-ideas] Re: "except BaseException with f as result"

On 9/04/20 1:37 am, Soni L. wrote: On 2020-04-08 10:33 a.m., Greg Ewing wrote:     try:     first = next(iterator)     except abdl.exceptions.ValidationError as e: validation_handler(e)     except StopIteration as e: return stop_handler(e) ... I can do that today, can't I? Yep! --

[Python-ideas] Re: "except BaseException with f as result"

On 2020-04-08 10:33 a.m., Greg Ewing wrote: On 9/04/20 1:22 am, Soni L. wrote: it's hard to reason about it if your eyes just keep jumping into the except bodies because they have the same indentation and everything as the normal code. I am gonna say my proposal improves accessibility,

[Python-ideas] Re: "except BaseException with f as result"

On 9/04/20 1:22 am, Soni L. wrote: it's hard to reason about it if your eyes just keep jumping into the except bodies because they have the same indentation and everything as the normal code. I am gonna say my proposal improves accessibility, even if it doesn't make a difference to most ppl.

[Python-ideas] Re: "except BaseException with f as result"

On 2020-04-08 10:22 a.m., Soni L. wrote: On 2020-04-08 10:12 a.m., Joao S. O. Bueno wrote: On Tue, 7 Apr 2020 at 23:17, Greg Ewing > wrote: On 8/04/20 1:14 pm, Soni L. wrote: >      def get_property_values(self, prop): >      try:

[Python-ideas] Re: "except BaseException with f as result"

On 2020-04-08 10:12 a.m., Joao S. O. Bueno wrote: On Tue, 7 Apr 2020 at 23:17, Greg Ewing > wrote: On 8/04/20 1:14 pm, Soni L. wrote: >      def get_property_values(self, prop): >      try: >      factory =

[Python-ideas] Re: "except BaseException with f as result"

On Tue, 7 Apr 2020 at 23:17, Greg Ewing wrote: > On 8/04/20 1:14 pm, Soni L. wrote: > > > def get_property_values(self, prop): > > try: > > factory = self.get_supported_properties()[prop] > > except KeyError with keyerror_handler; > > iterator =

[Python-ideas] Re: "except BaseException with f as result"

Andrew Barnert writes: > I don’t like the idea either; but I think I like your version even less. > > It reads perfectly well, but with the wrong meaning. Even though I > know what you’re intending, I can’t make myself read that as result > getting bound to what f returns, only as result

[Python-ideas] Re: Improvement: __json__

You don't need JSON at all in order to serialize and deserialize instances of Python objects and primitives. Pickle (or e.g. Arrow + [parquet,]) handles nested, arbitrary complex types efficiently and without dataclasses and/or type annotations. I don't see the value in using JSON to round-trip

[Python-ideas] Re: Improvement: __json__

On Apr 7, 2020, at 18:10, Wes Turner wrote: > >  > *That* should read as "are not sufficient". > > Stuffing all of those into annotations is going to be cumbersome; resulting > in there being multiple schema definitions to keep synchronized and validate > data according to. > > I think

[Python-ideas] Re: "except BaseException with f as result"

On Apr 7, 2020, at 22:58, Stephen J. Turnbull wrote: > > BTW, although obviously I don't like the idea much, I think > >except BaseException as result with f: > > reads better than the original suggestion: > >except BaseException with f as result: > > in the event this idea gets