Re: [Python-ideas] Dedicated string concatenation operator

For changes that break this much previous code, you need a really, really, really good reason. "Even though it's kind of weird, I find the separation between addition and concatenation useful." does not qualify. ___ Python-ideas mailing list

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

Finding more realistic use cases is key -- the actual spec is pretty obvious and doesn't worry me in terms of added language or implementation complexity. I think just finding a data structure that should implement its own min/max funtionality (or maybe one of these, like heapq) is not enough

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

> Are there any builtins or std library classes that offer their own min()/max() methods? My first instinct was heapq[1], since the way to access the min value is simply heap[0] (and I thought it could benefit from __min__) -- it's almost the perfect motivating example. But as it stands, the

Re: [Python-ideas] Dedicated string concatenation operator

On Wed, Jun 20, 2018 at 07:51:46PM +0800, Ken Hilton wrote: > I propose adding a dedicated operator for string concatenation. Guido's time machine strikes again: py> "Hello" + "World" 'HelloWorld' (This has been in the language since at least version 1.5 and probably back even further to 1.0

Re: [Python-ideas] Check type hints in stack trace printing

To clarify some more, you'd then have to use the decorator like: @type_check_on_traceback def three(arg: str) -> str: return "{}({}) ".format(arg, len(arg)) on every function where you want this behaviour. Note that this will also emit warnings on tracebacks of exceptions that are later

Re: [Python-ideas] Copy (and/or pickle) generators

I wanted to sound out a couple things. First, I couldn't find any real discussion about it after 2011 so I had no idea if the reasons it was ruled unfeasible with Python 2 still held nearly 10 years later with Python 3. I was mainly wondering if all the recent asynchronous work had changed things

[Python-ideas] staticmethod and classmethod should be callable

While working on PEP 579 and friends, I noticed one oddity with classmethods: for Python classes, the object stored in the class __dict__ is of type "classmethod". For extension types, the type is "classmethod_descriptor". In turns out that the latter is callable itself, unlike staticmethod or

[Python-ideas] Check type hints in stack trace printing

El 14/06/18 a las 14:37, Steven D'Aprano escribió: > On Thu, Jun 14, 2018 at 01:03:37PM +0200, Daniel Sánchez Fábregas wrote: >> My idea consist in: >> Adding a method to perform type checking in traceback objects >> When printing stack traces search for mistyped arguments and warn about >> them

Re: [Python-ideas] POPT (Python Ob ject Provider Threads)

On 20 June 2018 at 00:47, Martin Bammer wrote: > If this idea is well implemented I expect a big performance improvement for > all Python applications. Given the free lists already maintained for several builtin types in the reference implementation, I suspect you may be disappointed on that

Re: [Python-ideas] staticmethod and classmethod should be callable

On Wed, Jun 20, 2018 at 11:56:05AM +0200, Jeroen Demeyer wrote: [...] > Since it makes sense to merge the classes "classmethod" and > "classmethod_descriptor" (PEP 579, issue 8), one of the above behaviors > should be changed. Given that adding features is less likely to break > stuff, I would

[Python-ideas] Dedicated string concatenation operator

Hi all, just another wild idea. I've been working a lot with PHP lately (boo!), and one of the things I have a love-hate relationship with in it is its string concatenation operator: . Counter-intuitively to Python, `.` is used to concatenate strings; `"str1" . "str2"` evaluates to `"str1str2"`.

Re: [Python-ideas] POPT (Python Ob ject Provider Threads)

Of course I'm happy that Python is so much optimized. I'm only disappointed that I couldn't help to improve the speed with my idea ;-) On 2018-06-20 22:50, Guido van Rossum wrote: On Wed, Jun 20, 2018 at 1:16 PM Martin Bammer > wrote: I saw this free lists

Re: [Python-ideas] POPT (Python Ob ject Provider Threads)

On Wed, Jun 20, 2018 at 1:16 PM Martin Bammer wrote: > I saw this free lists implementation this morning in the floatobject and > listobject sources, > > which already handles the reuse of objects. I must admit I like this > implementation. It's pretty smart. > > And yes I'm a little bit

Re: [Python-ideas] Copy (and/or pickle) generators

On Wed, Jun 20, 2018 at 6:34 AM Micheál Keane wrote: [..] > First, I couldn't find any real discussion about it after 2011 so I had no > idea if the reasons it was ruled unfeasible with Python 2 still held nearly > 10 years later with Python 3. I was mainly wondering if all the recent >

Re: [Python-ideas] staticmethod and classmethod should be callable

20.06.18 19:20, Guido van Rossum пише: +1 -- when we introduced these we didn't see the use case so clearly, but it definitely exists. How would you call a classmethod descriptor in this case? ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] staticmethod and classmethod should be callable

Maybe. Though it has surprised me occasionally that pulling a classmethod or staticmethod out of the class dict (like in Jeroen's original example) doesn't work. On Wed, Jun 20, 2018 at 10:34 AM Serhiy Storchaka wrote: > 20.06.18 12:56, Jeroen Demeyer пише: > > Are there any reasons to *not*

Re: [Python-ideas] Copy (and/or pickle) generators

This was already posted in the thread, but https://github.com/ll/cloudpickle-generators is just an extension to the standard pickle machinery and is able to support closures, nonlocals, and globals:

Re: [Python-ideas] staticmethod and classmethod should be callable

On Wed, Jun 20, 2018 at 9:31 AM Serhiy Storchaka wrote: > 20.06.18 19:20, Guido van Rossum пише: > > +1 -- when we introduced these we didn't see the use case so clearly, > > but it definitely exists. > > How would you call a classmethod descriptor in this case? > With an extra first argument

Re: [Python-ideas] staticmethod and classmethod should be callable

20.06.18 19:37, Guido van Rossum пише: On Wed, Jun 20, 2018 at 9:31 AM Serhiy Storchaka > wrote: 20.06.18 19:20, Guido van Rossum пише: > +1 -- when we introduced these we didn't see the use case so clearly, > but it definitely exists. How

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

20.06.18 10:00, Steven D'Aprano пише: On Wed, Jun 20, 2018 at 07:05:19AM +0300, Serhiy Storchaka wrote: 1. What to do with additional min() and max() arguments: key and default. Since there are no reflected versions of min/max, there is no trouble with extra arguments. Just pass them through

Re: [Python-ideas] staticmethod and classmethod should be callable

+1 -- when we introduced these we didn't see the use case so clearly, but it definitely exists. On Wed, Jun 20, 2018 at 4:44 AM Steven D'Aprano wrote: > On Wed, Jun 20, 2018 at 11:56:05AM +0200, Jeroen Demeyer wrote: > [...] > > Since it makes sense to merge the classes "classmethod" and > >

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

I do think there is some merit in being able to as easily as possible transition from something being, say list-backed, to a domain specific data structure that's more efficient. If one wanted to go from a list to a minheap, it'd be nice just to change `x = []` to `x = Heap()` and have everything

Re: [Python-ideas] "Exposing" `__min__` and `__max__`

On Wed, Jun 20, 2018 at 07:05:19AM +0300, Serhiy Storchaka wrote: > 19.06.18 22:18, James Edwards пише: > >I've only recently looked for these special methods, so that in and of > >itself may be the reason these methods aren't exposed, but I could think > >of objects that may wish to implement

Re: [Python-ideas] Copy (and/or pickle) generators

On Wed, 20 Jun 2018 12:15:18 -0400 Yury Selivanov wrote: > > > Finally, another comment made the point that there wasn't a strong use case > > given for it. With the data science libraries that have sprung up around > > Python in the intervening years, I believe there now is one. > > As

Re: [Python-ideas] staticmethod and classmethod should be callable

On Wed, Jun 20, 2018 at 10:03 AM Serhiy Storchaka wrote: > 20.06.18 19:37, Guido van Rossum пише: > > On Wed, Jun 20, 2018 at 9:31 AM Serhiy Storchaka > > > > wrote: > > > > 20.06.18 19:20, Guido van Rossum пише: > > > +1 -- when we introduced these we

Re: [Python-ideas] staticmethod and classmethod should be callable

20.06.18 12:56, Jeroen Demeyer пише: Are there any reasons to *not* make staticmethod and classmethod callable? There were no reasons to make staticmethod and classmethod callable. Just "for consistency" is not considered a good reason. ___

Re: [Python-ideas] staticmethod and classmethod should be callable

20.06.18 20:07, Guido van Rossum пише: Maybe we're misunderstanding each other? I would think that calling the classmethod object directly would just call the underlying function, so this should have to call utility() with a single arg. This is really the only option, since the descriptor