[Python-ideas] Re: str.strip: argument maxstrip

On Tue, May 19, 2020 at 8:10 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > David (or somebody else) could you give us some, as real as possible, > examples? This will strengthen the case for it! > > I am confident they exist and are pretty plentiful but I myself am coming > up blank

[Python-ideas] Re: Ensuring asserts are always on in a file

On Mon, May 18, 2020 at 12:03 AM Richard Damon wrote: > On 5/17/20 5:04 PM, Alex Hall wrote: > > Some people (like myself, or the coworkers of [this person]( > https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > just like to u

[Python-ideas] Ensuring asserts are always on in a file

Some people (like myself, or the coworkers of [this person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) just like to use asserts as a convenient way to check things. We don't want asserts to ever be turned off. Maybe there could be som

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Sun, May 17, 2020 at 10:12 PM Ethan Furman wrote: > On 05/17/2020 10:18 AM, Alex Hall wrote: > > > But it's good that we have the assert statement, because it makes it > easy to write safe code and so people are encouraged to do so. > > I could not disagree more

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On Sun, May 17, 2020 at 6:22 PM Nathan Schneider wrote: > Let me attempt a metaphor, which won't be perfect but may help: > > The safety one gets from strictness is a bit like driving a car wearing a > seat belt. It is not fundamentally different from driving a car without a > seat belt, and in m

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat < thierry.parmente...@inria.fr> wrote: > well it’s all in the title > > the specific character that I am referring to is this one > > In [1]: print("\u2192”) > → > > https://unicode-table.com/en/2192/ > > —— > > just curious about how people woul

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

Steven D'Aprano wrote: > Proposal: > We should have a mechanism that collects the current function or > method's parameters into a dict, similar to the way locals() returns all > local variables. > This mechanism could be a new function,or it could even be a magic local > variable inside each funct

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Sat, May 16, 2020 at 10:07 PM Eric V. Smith wrote: > But my question is: If this technique has been available for 12 years, > why is it not more popular? > Because linters will not recognise a third party solution. Personally I've written code like: ``` def __init__(self, **kwargs): self

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Mon, May 11, 2020 at 12:50 AM Christopher Barker wrote: > I'm still confused what you mean by extend to all iterators? you mean that > you could use slice syntax with anything iterable> > > And where does this fit in to the iterable vs iterator continuum? > > iterables will return an iterator

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sun, May 10, 2020 at 8:20 PM Andrew Barnert wrote: > On May 10, 2020, at 02:42, Alex Hall wrote: > > > > - Handling negative indices for sequences (is there any reason we don't > have that now?) > > Presumably partly just to keep it minimal and simple. Itertool

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sun, May 10, 2020 at 5:00 AM Christopher Barker wrote: > On Sat, May 9, 2020 at 1:58 PM Alex Hall wrote: > >> I think this is a good idea. For sequences I'm not sure how big the >> benefit is - I get that it's more efficient, but I rarely care that much, >>

[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)

On Sat, May 9, 2020 at 9:41 PM Christopher Barker wrote: > Funny you should bring this up. > > I've been meaning, for literally years, to propose not quite this, but > adding a "slice iterator" to the sequence protocol. > > (though note that one alternative is adding slice syntax to > itertools.i

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 9, 2020 at 7:02 PM Ram Rachum wrote: > Hey, > > I just found a good example for the unpacking errors I suggested: > > > def topological_sort(graph: networkx.DiGraph) -> tuple: > try: > (zero_node,) = (node for node in graph if not > graph.neighbors(node)) >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > Trying to make it a flag (which will always be passed a constant value) is > a clever way to try to get the best of both worlds—and so is the > chain.from_iterable style. At this point it sounds l

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 8:38 PM Steven D'Aprano wrote: > On Fri, May 08, 2020 at 07:52:10PM +0200, Alex Hall wrote: > > > Would the proposal come with a new magic dunder method which can be > > overridden, or would it be like `is`? > > An excellent question! I do

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier wrote: > So as a practical step forward, what about providing a wrapper type > which performs all operations elementwise on the operands. So for example: > > if all(elementwise(chars) == string): > ... > > Here the `elementwise(chars

[Python-ideas] Re: islice with actual slices

On Sat, May 9, 2020 at 11:15 AM Ram Rachum wrote: > Here's an idea I've had. How about instead of this: > > itertools.islice(iterable, 7, 20) > > We'll just have: > > itertools.islice(iterable)[7:20] > > > Advantages: > 1. More familiar slicing syntax. > 2. No need to awkwardly use None when you'

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 7:52 PM David Mertz wrote: > Me: For non-singleton immutables, identity is not really a meaningful >> thing. I mean, other than in a debugger or code profiler, or something >> special like that. I honestly do not know whether, e.g. '(1, "a", 3.5) is >> (1, "a", 3.5)'. I'l

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 7:48 PM Steven D'Aprano wrote: > On Fri, May 08, 2020 at 01:00:48PM -0400, David Mertz wrote: > > > All the discussion following Steven's hypothetical .EQ. operator (yes, > not > > a possible spelling) just seems to drive home to me that what everyone > > wants is simply a

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 5:51 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > FYI, it does show in my version on gmail and on the mailman version. > > Weird, did Ethan's client cut

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 5:11 PM Ethan Furman wrote: > On 05/08/2020 07:50 AM, Alex Hall wrote: > > On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote: > >> On Fri, 8 May 2020 at 14:16, Steven D'Aprano <mailto:st...@pearwood.info>> wrote: > >> >

[Python-ideas] Re: Equality between some of the indexed collections

On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > On Fri, 8 May 2020 at 14:16, Steven D'Aprano wrote: > >> If you have ever written something like any of these: >> >> list(a) == list(b) >> tuple(a) == b >> ''.join(chars) == mystring >> all(x=

[Python-ideas] Re: Equality between some of the indexed collections

This reminded me of another recent message so I decided to find that and link it here: https://mail.python.org/archives/list/python-ideas@python.org/message/7ILSYYOFPQL5DVH5DGIGQSL6PYFYF7PC/ It seemed like a more useful thing to do before I discovered that you wrote that too... On Thu, May 7, 202

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Thu, May 7, 2020 at 9:48 AM Kirill Balunov wrote: > Sorry for off topic. Isn't this chain.from_iterable just a historical > legacy... now we have PEP 448 and I see no differences* between > chain(*iterable) vs chain.from_iterable(iterable). Are there? > > * chain.from_iterable is a little bit

[Python-ideas] Re: Equality between some of the indexed collections

On Thu, May 7, 2020 at 2:33 AM Oscar Benjamin wrote: > On Sat, 2 May 2020 at 20:50, Serhiy Storchaka wrote: > > > > 02.05.20 21:34, Ahmed Amr пише: > > > I see there are ways to compare them item-wise, I'm suggesting to bake > > > that functionality inside the core implementation of such indexed

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Wed, May 6, 2020 at 8:49 PM Ricky Teachey wrote: > >>> In the example above, self.b is assigned the value of b, not Enum(b). >>> And even if you called-- or gave the option to call-- func(*args, **kwargs) >>> first, autoassign still wouldn't know that you want to modify the supplied >>> parame

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Wed, May 6, 2020 at 8:08 PM Ricky Teachey wrote: > On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote: > >> I think this looks great, I can't think of anything wrong with it. >> >> Could we put this into the standard library, so that IDEs and linters are >> pr

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

I think this looks great, I can't think of anything wrong with it. Could we put this into the standard library, so that IDEs and linters are programmed to recognise it? On Wed, May 6, 2020 at 4:55 PM Joao S. O. Bueno wrote: > Here - with the current inspect.Signature, it is straightforward > t

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Wed, May 6, 2020 at 7:15 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Dominik Vilsmeier writes: > > > Or simply "samelength". > > If we're going to do this to the builtin (I'm still -1 on changing the > builtin FWIW), I'm persuaded by Chris Barkley's (somewhat differe

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

On Tue, May 5, 2020 at 3:14 PM Steven D'Aprano wrote: > On Tue, May 05, 2020 at 02:55:24PM +0200, Alex Hall wrote: > > > Perhaps we should take the energy that is going into this thread and > direct > > it towards supporting keyword-only arguments in dataclasses,

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

Perhaps we should take the energy that is going into this thread and direct it towards supporting keyword-only arguments in dataclasses, a discussion which is apparently struggling: https://github.com/python/cpython/pull/6238#issuecomment-584579729 On Mon, May 4, 2020 at 10:49 PM Lewis Ball wrote

[Python-ideas] Re: Equality between some of the indexed collections

On Tue, May 5, 2020 at 7:36 AM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > >> Isn't a tuple essentially just a frozenlist? I know the intended > >> semantics of tuples and lists tend to be different, but I'm not sure > that's > >> relevant. > > > In terms of API, it might look that w

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 9:18 PM Chris Angelico wrote: > On Tue, May 5, 2020 at 5:11 AM Alex Hall wrote: > > > > On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano > wrote: > >> Can we agree to meet half-way? > >> > >> - there are legitimate, genuin

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 2:33 AM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 07:43:44PM +0200, Alex Hall wrote: > > On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano > wrote: > > > > > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > > &g

[Python-ideas] Re: zip(x, y, z, strict=True)

On Mon, May 4, 2020 at 1:59 AM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 10:26:18PM +0200, Alex Hall wrote: > > > > If I know that consumers of my data truncate on the shortest input, > then > > > as the producer of data I don't have to care abo

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

If you use the word 'even' and tell me it has to do with lengths (or any number) I'm going to think of multiples of 2, not equality. On Mon, May 4, 2020 at 3:52 PM wrote: > Guido van Rossum wrote: > > I should really stay out of this (hundreds of messages and still > > bickering^Wbikeshedding :-

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 2, 2020 at 11:39 PM Richard Damon wrote: > Doesn't it also imply that ('a',) == 'a' and that you couldn't get a > dict to use both of these as keys? > ``` >>> {1.0: 2, 1: 3} {1.0: 3} ``` ___ Python-ideas mailing list -- python-ideas@python.

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 2, 2020 at 10:52 PM Dominik Vilsmeier wrote: > `frozenset` and `set` make a counterexample: > > >>> frozenset({1}) == {1} > True > Nice catch! That's really interesting. Is there reasoning behind `frozenset({1}) == {1}` but `[1] != (1,)`, or is it just an accident of history? Isn't a

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 2, 2020 at 10:36 PM Guido van Rossum wrote: > It does look like that would violate a basic property of `==` -- if two > values compare equal, they should be equally usable as dict keys. > It's certainly a reasonable property, but I don't think it's critical. By comparison, if it was

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 2, 2020 at 9:51 PM Serhiy Storchaka wrote: > 02.05.20 21:34, Ahmed Amr пише: > > I see there are ways to compare them item-wise, I'm suggesting to bake > > that functionality inside the core implementation of such indexed > > structures. > > Also those solutions are direct with tuples

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 5:10 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > > Adding a function to itertools will mostly solve that problem, but not > > entirely. Adding `strict=True` is so easy that people will be encouraged &g

[Python-ideas] Re: Equality between some of the indexed collections

On Sat, May 2, 2020 at 8:38 PM Ahmed Amr wrote: > I see there are ways to compare them item-wise, I'm suggesting to bake > that functionality inside the core implementation of such indexed > structures. > I'm sure there are times when I would also like this, and others too. But it would be a dis

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 6:09 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 04:58:43PM +0200, Alex Hall wrote: > > > I didn't think carefully about this implementation and thought that there > > was only a performance cost in the error case. That's obviousl

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 2:58 PM Alex Hall wrote: > On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano > wrote: > >> Rolling your own on top of >> > zip_longest is easy. It's half a dozen lines. It could be a recipe in >> itertools, or a function. > > &g

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 4:34 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote: > > > > > Yes? Is it our responsibility to put everything in builtins because > > > people might not think to look in math, or functools, or o

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote: > But I question whether *enough* people need it *often enough* to make it > a builtin, or to put a flag on plain zip. > It has taken years for it to be added to more-itertools, suggesting that > the real world need for this is small. > >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 1:19 PM Steven D'Aprano wrote: > On Sat, May 02, 2020 at 09:54:46AM +0200, Alex Hall wrote: > > > I would say that in pretty much all cases you wouldn't catch the > exception. > > It's the producer's responsibility to produce co

[Python-ideas] Re: Introduce 100 more built-in exceptions

On Sat, May 2, 2020 at 12:39 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > Of course, there are other ways of writing this code, but imagine this for > a database interface where a save normally returns the saved object > (inspired by Django) > > ``` > try: > x, y = Foo.save() >

[Python-ideas] Re: zip(x, y, z, strict=True)

On Sat, May 2, 2020 at 3:50 AM Steven D'Aprano wrote: > On Thu, Apr 30, 2020 at 07:58:16AM -0700, Christopher Barker wrote: > > > Imagine someone that uses zip() in code that works for a while, and then > > discovers a bug triggered by unequal length inputs. > > > > If it’s a flag, they look at t

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

D'Aprano wrote: > On Fri, May 01, 2020 at 11:30:17PM +0200, Alex Hall wrote: > > > Specifically the PEP says: > > > > > Another proposed idiom, per-module shadowing of the built-in zip with > some > > > subtly different variant from itertools, is an

[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip

On Fri, May 1, 2020 at 10:58 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > A separate function can be used in third-party libraries immediately, as > long as there’s an available backport (whether that’s more-iterools, or a > trivial zip39 or whatever) that they can requir

[Python-ideas] Re: Introduce 100 more built-in exceptions

Recent related discussion: https://mail.python.org/archives/list/python-ideas@python.org/thread/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/ On Fri, May 1, 2020 at 8:53 AM Ram Rachum wrote: > Hi, > > Here's something I wanted in Python for many years. If this has been > discussed in the past, please refer

[Python-ideas] Re: Adding a "once" function to functools

Some libraries implement a 'lazy object' which forwards all operations to a wrapped object, which gets lazily initialised once: https://github.com/ionelmc/python-lazy-object-proxy https://docs.djangoproject.com/en/3.0/_modules/django/utils/functional/ There's also a more general concept of proxyi

[Python-ideas] Re: Adding a "once" function to functools

On Sun, Apr 26, 2020 at 7:47 PM Eric Fahlgren wrote: > On Sun, Apr 26, 2020 at 9:46 AM Alex Hall wrote: > >> It's not clear to me why people prefer an extra function which would be >> exactly equivalent to lru_cache in the expected use case (i.e. decorating a >> fu

[Python-ideas] Re: Adding a "once" function to functools

On Sun, Apr 26, 2020 at 6:57 PM Tom Forbes wrote: > I agree, that was the topic of my original post to the python-ideas > discussion group[1]. I thought we should special-case `lru_cache()` to > account for this use case. > > The general consensus was that a `once()` decorator would be less > con

[Python-ideas] Re: Adding a "once" function to functools

It's not clear to me why people prefer an extra function which would be exactly equivalent to lru_cache in the expected use case (i.e. decorating a function without arguments). It seems like a good way to cause confusion, especially for beginners. Based on the Zen, there should be one obvious way t

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 11:01 AM M.-A. Lemburg wrote: > On 21.04.2020 10:07, Alex Hall wrote: > > > > > > On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg > <mailto:m...@egenix.com>> wrote: > > > > In the use case discussed here, that namespace wo

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 10:50 PM Alex Hall wrote: > On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote: > >> > I think you've missed on alternative. Well, it's a variation on "status >> quo": Use a silly magic helper function like my Q() or

[Python-ideas] Re: Keyword arguments self-assignment

On Tue, Apr 21, 2020 at 9:45 AM M.-A. Lemburg wrote: > In the use case discussed here, that namespace would be > locals(), so you could just as well write render_template(**locals()), > Doing that gets in the way of tools. At the very least it makes it impossible to highlight accidentally unused

[Python-ideas] Re: zip(x, y, z, strict=True)

> > x = iter(range(5)) > y = [0] > try: > zipped = zip(x, y, strict=True) > except ValueError: # assuming that’s the exception you want? > print(next(x)) > > Should this print 1 or 2 or raise StopIteration or be a don’t-care? Surely no exception is raised because

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 10:46 PM Christopher Barker wrote: > On Mon, Apr 20, 2020 at 1:35 PM Alex Hall wrote: > >> >> So let's assume that a beginner is likely to notice arguments out of >> order and think that something is wrong, and focus on what happens from &

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 7:37 PM Christopher Barker wrote: > On Sun, Apr 19, 2020 at 3:37 AM Alex Hall wrote: > >> ``` >> File "setup.py", line 2232 >> self.add(Extension('_decimal', >>include_dirs=inc

[Python-ideas] Re: Keyword arguments self-assignment

On Mon, Apr 20, 2020 at 5:04 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote: > > Sorry, what? How is there any doubt that the arguments being passed are > > dunder, invert, private, meta, and ignorecase? They're right there. > &g

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 12:57 PM Steven D'Aprano wrote: > On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote: > > On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano > wrote: > > > > > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > &g

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 02:10:21PM +0200, Alex Hall wrote: > > > > > > And notice that there is absolutely no difficulty with some future > > > enhancement to allow positional arguments after keyword arg

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:18 PM David Mertz wrote: > If this were in the library I or my project used, whatever limitations and > edge cases exist wouldn't really matter. If I REALLY cared about saving a > few duplicate names in function calls, I could easily include it with the > knowledge tha

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:00 PM David Mertz wrote: > See this thread where I created M() as successor of Q(). > >> I saw, and I mentioned it: I see you've tried while I wrote this, and it's pretty clear it's very far > from robust. It's really not that hard, I don't think. Probably there are

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > Per your wish, Eric, the glorious successor of Q() ... named M(): > > >>> def M(*vals): > ... import sys > ... import inspect > ... caller = sys._getframe(1) > ... call = inspect.stack()[1].code_context[0] > ... _, call = call.split('M(') > ... call = call.strip()[:-1] >

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 5:59 PM David Mertz wrote: > On Sun, Apr 19, 2020 at 7:00 AM Chris Angelico wrote: > >> Yes, exactly. One strike doesn't mean it's out, and with a proposal >> like this, it's a matter of looking at a whole lot of imperfect >> alternatives and seeing which tradeoffs we wan

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > So, if M() existed, you could say: > > d = M(telephone, name) > func(**d) > > or > > func(**M(telephone, name)) > > Or, you could just use "d" from the first example for your own purposes > unrelated to function calling. > My point is: We already have a way to pass the items in a dictionary as

[Python-ideas] Re: Keyword arguments self-assignment

On Sun, Apr 19, 2020 at 7:06 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > OK, that's fair. What about `{foo::}`? > > I don't like any of them. People who are going to use the syntax > should choose it, not t

[Python-ideas] Re: Keyword arguments self-assignment

> > >> function(*, dunder, invert, private, meta, ignorecase) > >> > > > > > > No reader will ever have to think about the difference. They will simply > > see the second version and know which arguments are being passed. > > I seem to be immune to this magical knowledge. > Sorry, what? How i

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > And notice that there is absolutely no difficulty with some future > enhancement to allow positional arguments after keyword arguments. > We've already discussed in this thread that we shouldn't fear conflicting with other (real or hypothetical) proposals, even if they're likely. As I see it,

[Python-ideas] Re: Keyword arguments self-assignment

On Sun, Apr 19, 2020 at 7:58 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > > And now Lisp bites me, because '::a' means ... > > > And a single colon also means something else in Lisp. > > Yeah,

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sun, Apr 19, 2020 at 11:49 AM Steven D'Aprano wrote: > On Sun, Apr 19, 2020 at 10:19:41AM +0200, Alex Hall wrote: > > > But the problem here is not that your proposal doesn't meet all the > > requirements, it's that you have different requirements from us. You

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

> > It would be good if we had something that was neither excessive verbose > nor painfully terse, required nothing but ASCII, that was similar enough > to dict unpacking to suggest a connection, but without being confusable > to anything else even to newbies, was self-descriptive without needing >

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On Sat, Apr 18, 2020 at 5:03 PM Steven D'Aprano wrote: > On Sat, Apr 18, 2020 at 02:13:51PM +0200, Alex Hall wrote: > > > My issue with this, and maybe it's what Andrew is also trying to say, is > > that it breaks our usual assumptions about composing expressions. `{u

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

nvented the syntax -- I think it might have been > Alex Hall?) > lol everyone thinks I invented things I didn't... The idea was first suggested by Dominik: https://mail.python.org/archives/list/python-ideas@python.org/message/S44VDMZ4AFBSGIQEVWMKKWOW4P6WRVXY/ I just suggested mak

[Python-ideas] Re: Keyword arguments self-assignment

> > And now Lisp bites me, because '::a' means ... > And a single colon also means something else in Lisp. Does it matter much what that notation means in a different language? Python will struggle to evolve if it can't conflict with other languages. I myself am rarely annoyed by this issue, with

[Python-ideas] Re: Keyword arguments self-assignment

> > If typing the same variable from the caller to use in the parameter is > really too much repetition, you could maybe just do this: > > >>> render_template("index.html", > ... username="display_name", > ... setups="setups", > ... **Q("x y z")) > ('index.html',) > {'username': 'displa

[Python-ideas] Re: Keyword arguments self-assignment

I also find the example with :keyword a bit jarring at first glance, so I propose a double colon to alleviate the problem if we go in that direction. Compare: { :a, "b": x, :c } { ::a, "b": x, ::c } On Fri, Apr 17, 2020 at 10:05 PM Rhodri James wrote: > On 17/04/2020 19:21, Andrew Barn

[Python-ideas] Re: Keyword arguments self-assignment

h), lineno), end="") print() main() ``` On Fri, Apr 17, 2020 at 8:40 PM Paul Svensson wrote: > On Fri, 17 Apr 2020, Alex Hall wrote: > > >Perhaps an easier next step would be to get better data about people's > opinions with a simple poll? Is there a stan

[Python-ideas] Re: Keyword arguments self-assignment

Perhaps an easier next step would be to get better data about people's opinions with a simple poll? Is there a standard way to vote on things in this list? I say we do a simple approval vote. Everyone ticks all the syntaxes that they think would be acceptable to include in the language. It's not v

[Python-ideas] Re: Keyword arguments self-assignment

On Fri, Apr 17, 2020 at 6:09 PM David Mertz wrote: > On Fri, Apr 17, 2020 at 9:57 AM wrote: > >> The mode-switch proposal though would not impede one to mix shorthand and >> longhand forms. This should be valid syntax: >> >> ```python >> return render_template("index.html", *, >> twitter, us

[Python-ideas] Re: Keyword arguments self-assignment

> > But this means the reader could miss the star, especially with a very > large function call over multiple lines, and if that reader happens to use > that particular function A LOT and know the parameter order without having > to look they would pretty easily believe the arguments are doing some

[Python-ideas] Re: Keyword arguments self-assignment

On Fri, Apr 17, 2020 at 11:57 AM Steven D'Aprano wrote: > On Fri, Apr 17, 2020 at 11:25:15AM +0200, Alex Hall wrote: > > > I don't think you really need to know what it means to read the code for > > most purposes. > > *blink* > > > You look at t

[Python-ideas] Re: Keyword arguments self-assignment

On Fri, Apr 17, 2020 at 5:08 AM Steven D'Aprano wrote: > On Thu, Apr 16, 2020 at 07:50:30PM +0200, Alex Hall wrote: > > > > > > And what would you do if you wanted to call: > > > > > > self.do_something(positional, keyword=keyword, key

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 10:47 PM Dominik Vilsmeier wrote: > > On 16.04.20 22:28, Alex Hall wrote: > > On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote: > >> Dominik Vilsmeier wrote: >> > I'm not sure if this is doable from the compiler perspective, but wh

[Python-ideas] Re: Keyword arguments self-assignment

On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley wrote: > Dominik Vilsmeier wrote: > > I'm not sure if this is doable from the compiler perspective, but what > > about allowing tuples after `**` unpacking: > > > > requests.post(url, **(data, params)) > > > > # similar to > > requests.

[Python-ideas] Re: Keyword arguments self-assignment

> > I’m not sure if this would work out the same way or not. And even if it > does, that hurdle of describing the syntax in a way that people won’t get > confused the way they do when they first learn the feature in C++ might be > hard to overcome. But it’s at least plausible that it could be reada

[Python-ideas] Re: Keyword arguments self-assignment

> > And what would you do if you wanted to call: > > self.do_something(positional, keyword=keyword, keyword1=somethingelse, > keyword2=keyword2) > > ? > > Eric > I think this is still pretty clear: self.do_something(positional, *, keyword, keyword1=somethingelse, keyword2) but if you don't like

[Python-ideas] Re: Keyword arguments self-assignment

> > I beg to differ. I do find "def foo(a, *, b)" gets in the way of > readability. > > -- > Rhodri James *-* Kynesim Ltd > In what way? In any case, focusing on the calling syntax being proposed, is there anything unreadable about: foo(a, *, b) compared to foo(a, b=b) ? I think in the propo

[Python-ideas] Re: Keyword arguments self-assignment

Here's a similar thread: https://mail.python.org/archives/list/python-ideas@python.org/thread/SQKZ273MYAY5WNIQRGEDLYTKVORVKNEZ/#LXMU22F63VPCF7CMQ4OQRH2CG6H7WCQ6 Personally I write code like this all the time and would love this feature, but I can see how it would be a mess for beginners to learn.

[Python-ideas] Re: collections.UpdateDict, collections.InsertDict, collections.InsertOrIgnoreDict

I just tried playing with this idea: from collections import UserDict class InsertOrIgnoreDict(UserDict): __setitem__ = UserDict.setdefault print(InsertOrIgnoreDict([(1, 2), (3, 4)])) It caused an infinite chain of exceptions: Traceback (most recent call last): File "/home/alex/.pyenv/

[Python-ideas] Re: Range of Indexes

range(len(x)) is actually not that important. You probably need to be using enumerate() more often. On Fri, Apr 10, 2020 at 9:44 PM Chamoun Saoma wrote: > I have an idea to improve the python language through the creation of a > new and very readable function. > > > # > def ranle

[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 value

[Python-ideas] Re: New explicit methods to trim strings

I think I'm missing something, why is case insensitivity a mess? On Mon, Mar 23, 2020 at 9:32 AM Chris Angelico wrote: > On Mon, Mar 23, 2020 at 5:06 PM Steve Barnes > wrote: > > > > I personally think that there is a better case for an ignore_case flag – > the number of times that I have been

[Python-ideas] Re: decorator vs. 'with' analogy [was: Syntax for loop invariants]

Yes https://docs.python.org/3/library/contextlib.html#contextlib.ContextDecorator On Thu, Mar 19, 2020 at 3:26 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Andrew Barnert via Python-ideas writes: > > > [A] context manager seems perfect. It allows you to hint any > > st

[Python-ideas] Re: New explicit methods to trim strings

wrote: > Well, str.replace has a count parameter. Presumably people use it (even > if by accidentally discovering that without it, it replaces all occurrences > when they only wanted one replaced). > On 18/03/2020 18:44, Alex Hall wrote: > > Just the first occurrence. The vast major

[Python-ideas] Re: New explicit methods to trim strings

Just the first occurrence. The vast majority of the time, that's what people want to do, and they will usually forget to add a 'count' parameter. Many people probably wouldn't even know it exists. It would be disastrous if code did the correct thing 99.9% of the time but occasionally silently mutil

<    1   2   3   >