[Python-ideas] Re: encode/decode for all objects

On Thu, Jul 16, 2020, at 02:13, Stephen J. Turnbull wrote: > Michael A. Smith writes: > > > It seems to me that obj.encode("json") and str.decode("json"), for example, > > would be a powerful feature, > > This idea comes up a lot in various forms. The most popular lately is > an optional

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

On Mon, Jul 20, 2020 at 3:17 AM Rhodri James wrote: > Ironically that example pushes me back to -1. It may look a lot like > xarray and pandas working, but that just means it should be in xarray > and/or pandas. after following most of this discussion, I'm still not sure what we'd get with

[Python-ideas] Re: isolating user allocations

Hi Guido, I guess I didn't think it through. Thanks for all your comments! Regards On Mon, Jul 20, 2020 at 10:35 PM Guido van Rossum wrote: > Wenjun, > > I feel we're just not communicating. Your suggestion seems to be a > solution in search of a problem. And now you're making more super >

[Python-ideas] Official joint communication from the Python Steering Council, PSF Board of Directors, and PSF Conduct WG

[This has been sent to python-committers, python-dev, and python-ideas] Recently, a series of discussions on this mailing list resulted in behavior that did not live up to the standards of the Python Community. The PSF Board of Directors, Python Steering Council, and the PSF Conduct Working Group

[Python-ideas] Re: Simplifying functions syntax

Actually, Callable is fine the way it is, the chosen name is most fitting and the generic syntax is slightly difference than how it's done in C/C++ (Known difference are due to language differences between Python and C/C++) ___ Python-ideas mailing

[Python-ideas] Re: Simplifying functions syntax

(The only not unreasonable suggestion in the OP's proposal is to try and come up with something better than Callable --- we've introduced other syntax specifically for type annotations, and are likely to do so again. But **PLEASE** start a new thread for that.) On Mon, Jul 20, 2020 at 7:37 PM

[Python-ideas] Re: isolating user allocations

Wenjun, I feel we're just not communicating. Your suggestion seems to be a solution in search of a problem. And now you're making more super speculative suggestions. How much do you actually know about Python's internals? It's not at all like C++, where I could see the distinction between user

[Python-ideas] Re: isolating user allocations

Hi Guido, Thank you for bearing with me. I wasn't trying to say you guys are mean btw. I thought that the interpreter might allocate some memory for its own use. Perhaps I was wrong, but I'll work with your examples here just to be sure. Stack frames would be considered as interpreter objects

[Python-ideas] Re: Simplifying functions syntax

Chris Angelico, you have a good point. An alternative solution that would achieve similar or even better results in terms of simplification would be not creating `fun` as a keyword and allowing developers to create functions in Python without a keyword (like in C-family). That way, a new

[Python-ideas] Re: isolating user allocations

On Mon, Jul 20, 2020 at 4:09 PM Wenjun Huang wrote: > Hi Barry, > > It's not just about leaks. You might want to know if certain objects are > occupying a lot of memory by themselves. Then you can optimize the memory > usage of these objects. > > Another possibility is to do binary

[Python-ideas] Re: isolating user allocations

Hi Barry, It's not just about leaks. You might want to know if certain objects are occupying a lot of memory by themselves. Then you can optimize the memory usage of these objects. Another possibility is to do binary instrumentation and see how the user code is interacting with objects. If we

[Python-ideas] Re: Simplifying functions syntax

There is absolutely no possibility that this will go anywhere. It breaks every single Python program written since 1989, with absolutely ZERO new functionally. Changing the spelling of a few of the most come keywords is a non-starter. If you can time travel to 1987 and propose differently spelled

[Python-ideas] Re: Simplifying functions syntax

On Tue, Jul 21, 2020 at 8:10 AM Thiago Carvalho D' Ávila wrote: > In order to make this possible the following changes would be needed: > 1. adding `fun` keyword to method definition (maintaining `def` for backwards > compatibility); > 2. adding `fun` built-in type in addition to Callable; If

[Python-ideas] Simplifying functions syntax

Python is a simple language to understand, but to me functions are a special case. And according to the Zen of Python (PEP20 ): `Special cases aren't special enough to break the rules.`. For beginners, Python functions can cause some pain that boils down

[Python-ideas] Re: isolating user allocations

> On 20 Jul 2020, at 18:51, Wenjun Huang wrote: > >  > Hi Guido, > > It's great to hear from you directly :) > > Sorry for not mentioning this earlier. The use case here is profiling. > Specifically, Scalene: https://github.com/emeryberger/scalene. > > At the moment, Scalene does stack

[Python-ideas] Re: isolating user allocations

Hi Guido, It's great to hear from you directly :) Sorry for not mentioning this earlier. The use case here is profiling. Specifically, Scalene: https://github.com/emeryberger/scalene. At the moment, Scalene does stack inspection to decide if an allocation is from the user. If there are hooks

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

I don't know what to do about the zero iterations case, though. Perhaps simply `if not:' Best wishes Rob Cliffe ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

Also, let me be clear that this feature will never be added to the language. On Mon, Jul 20, 2020 at 07:36 Guido van Rossum wrote: > On Mon, Jul 20, 2020 at 03:22 Jonathan Fine wrote: > >> This is a continuation of my previous post to this thread. >> >> Python's FOR ... ELSE ... , Raymond

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On Mon, Jul 20, 2020 at 03:22 Jonathan Fine wrote: > This is a continuation of my previous post to this thread. > > Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in > some ideas of Don Knuth. > That’s news to me (both that it’s due to Knuth and that Raymond said so). I

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

> On 20 Jul 2020, at 09:56, Alex Hall wrote: > > On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas > mailto:python-ideas@python.org>> wrote: > May I repeat: Spelling 'if break:' and 'if not break:' rather than say > 'on_break:' etc. would avoid adding new keywords. > > I don't

[Python-ideas] Re: Pickle security improvements

Pydantic (https://pydantic-docs.helpmanual.io/) can already do that. On Monday, 13 July 2020 21:03:14 CEST Edwin Zimmerman wrote: > I would have interest in it. > > > > --Edwin > > > > > > I'm no security expert, but we've got a big pile of serialization code that > is kind of like

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

This is a continuation of my previous post to this thread. Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in some ideas of Don Knuth. For that reason, and others, I'll concisely review these ideas. In the very early days, a computer program was a sequence of commands. The

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

On 20/07/2020 06:11, Ricky Teachey wrote: On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote: One use case that comes up in xarray and pandas is support for indicating indexing "modes". For example, when indexing with floating point numbers it's convenient to be able to opt-in to approximate

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > May I repeat: Spelling 'if break:' and 'if not break:' rather than say > 'on_break:' etc. would avoid adding new keywords. > > I don't know what to do about the zero iterations case, though. > It

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On Sun, 19 Jul 2020 at 15:43, Олег Комлев wrote: > Thank to all disputants. > It is possible to borrow the keyword "case" from PEP-622 (when it appears > https://www.python.org/dev/peps/pep-0622). Keyword "case" can be written > instead of "else/elif". I.e. > case COND: > ... > [case COND: >

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On 15/07/2020 09:20, Dominik Vilsmeier wrote: But `finally` with a `for` loop is redundant since the code can be placed just after the loop. For `try/except` it's a different situation since the exception might bubble up, so "normal" code after the `try` won't be reached. +1 Also