On Thu, May 07, 2020 at 10:44:01PM +1200, Greg Ewing wrote:
> On 7/05/20 9:11 pm, Steven D'Aprano wrote:
> >I'm initially going to use the ancient 1960s
> >Fortran syntax and spell it `.EQ.`.
> >
> >I know that syntax will not work in Python
> >because it will be
On Thu, May 07, 2020 at 06:04:13AM -0400, Dan Sommers wrote:
> On Thu, 7 May 2020 19:11:43 +1000
> Steven D'Aprano wrote:
>
> > We could define this .EQ. operate as *sequence equality*, defined very
> > roughly as:
> >
> > def .EQ. (a, b):
> >
On Wed, May 06, 2020 at 08:48:51AM -0700, Christopher Barker wrote:
[I asked]
> > A ternary flag of strict = True, False or what?
> >
>
> Come on:
>
> ternary: having three elements, parts, or divisions (
> https://www.merriam-webster.com/dictionary/ternary)
>
> did you really not know that?
On Wed, May 06, 2020 at 09:17:15PM -0400, Eric V. Smith wrote:
> I think David is right: itertools.chain.from_iterable() is the only
> place I know of with an attribute on a function that's another function.
Functions decorated with `functools.wrap` have an attribute that gives
the original
On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
> Currently, when comparing a list of items to an array of the same
> items for equality (==) it returns False, I'm thinking that it would
> make sense to return True in that context, as we're comparing item
> values and we have the
On Wed, May 06, 2020 at 07:15:22PM +1200, Greg Ewing wrote:
> On 6/05/20 6:12 pm, Steven D'Aprano wrote:
>
> >https://mathworld.wolfram.com/n-Tuple.html
> >https://mathworld.wolfram.com/List.html
> >https://mathworld.wolfram.com/Sequence.html
>
> I get the feeling
On Tue, May 05, 2020 at 12:49:05PM -0700, Christopher Barker wrote:
> Agreed, but discoverability is still something to be considered in the API.
> ANd it seems that there are folks arguing that we specifically want this to
> be less discoveble due to concerns of overuse. Which does not seem like
On Wed, May 06, 2020 at 02:58:01AM +0100, Henk-Jaap Wagenaar wrote:
> I don't think that is accurate to represent as a representation of "a
> mathematician". The top voted answer here disagrees:
> https://math.stackexchange.com/questions/122595/whats-the-difference-between-tuples-and-sequences
>
On Wed, May 06, 2020 at 12:39:30PM +1200, Greg Ewing wrote:
> On 6/05/20 2:22 am, jdve...@gmail.com wrote:
> >However, if sets and frozensets are "are considered to be
> >fundamentally the same kind of thing differentiated by mutability",
> >as you said, why not tuples and lists?
>
> I think that
Christopher's quoting is kinda messed up and I can't be bothered fixing
it, sorry, so you'll just have to guess who said what :-)
On Tue, May 05, 2020 at 01:03:30PM -0700, Christopher Barker wrote:
> "If its builtin people will be more likely to use it, so we need to make
> > it builtin."
> >
On Tue, May 05, 2020 at 05:28:08PM +0100, Henk-Jaap Wagenaar wrote:
> But you care about your input, you can do so by setting strict=True (if
> that's the road we go down), and unlike what others have said, the IDE I
> use (pycharm) would tell me that flag exists as I type "zip" and so I'd be
>
On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote:
> This is a straw man in regards to backwards compatibility. This particular
> (sub)thread is about whether if this zip-is-strict either as a separate
> name or a Boolean flag or some other flag of zip should be a built-in or be
Here is a quick and dirty proof of concept:
from inspect import stack, Signature
def parameters():
caller = stack()[2][0].f_globals[stack()[1][3]]
sig = Signature.from_callable(caller)
vars = stack()[1][0].f_locals
return sig.bind(**vars).arguments
On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote:
> Can you think of a single case where a zip_equal() (either pre-exisiting or
> roll your own) would not work, but the concretizing version would?
That's easy: if the body of your zip-handling function has side-effects
which
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, a discussion
> which is apparently struggling:
Why? How are dataclasses relevant (don't assume
On Tue, May 05, 2020 at 04:05:20AM -, Brandt Bucher wrote:
> > 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.
>
> Maybe I'm missing something here, but how about... `locals`?
On Tue, May 05, 2020 at 09:34:28AM -, jdve...@gmail.com wrote:
> `(frozenset() == set()) is True` shocked me.
>
> According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics):
> "equality is a relationship between two quantities or, more generally two
> mathematical
On Mon, May 04, 2020 at 09:20:28PM +0200, Alex Hall wrote:
> > Seriously, if some object defines a weird `__eq__` then half the
> > standard library, including builtins, stops working "correctly". See for
> > example the behaviour of float NANs in lists.
> >
> > My care factor for this is
On Mon, May 04, 2020 at 07:01:03PM +0100, Lewis Ball wrote:
> Hi All,
>
> First of all, if this is something which has been discussed in the past the
> please point me in the right direction.
It certainly has been, but with no conclusion one way or another. I
think people agree that it is a
On Mon, May 04, 2020 at 02:18:15PM -, jdve...@gmail.com wrote:
> Ok,`even`is one of those scarce polysemic words in English ;-)
>
> Meaning depends on context and message receiver's expectations, of course.
>
> But... "add an even mixture of milk and cream" and "the curtain rod
> and the
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
> On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
>
> > > > map(func, x, y, strict=True) # ?
> > > >
> > > > Admittedly the word "strict" in th
On Sun, May 03, 2020 at 11:13:58PM -0400, David Mertz wrote:
> It seems to me that a Python implementation of zip_equals() shouldn't do
> the check in a loop like a version shows (I guess from more-itertools).
> More obvious is the following, and this has only a small constant speed
> penalty.
>
On Sat, May 02, 2020 at 11:01:21PM +0200, Alex Hall wrote:
> 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
>
On Sun, May 03, 2020 at 04:09:21PM -0700, Christopher Barker wrote:
> > map(func, x, y, strict=True) # ?
> >
> > Admittedly the word "strict" in the context of `map` would be rather
> > confusing.
> >
>
> This a really good argument for "equal" rather than "strict".
Sorry, I'm not seeing
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:
> >
> > > I didn't think carefully about this implementation and thought that there
&
On Sat, May 02, 2020 at 02:58:57PM +0200, Alex Hall wrote:
> I'm not sure what the point of this long spiel about floats and str.upper
> was.
Half a dozen short paragraphs is a long spiel? Sorry, this isn't
Twitter, and sorry for not discussing complicated technical debates
using a maximum of
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 about making them equal. I
> > can say:
> >
> > process_user_ids(usernames, generate_user_ids())
> >
> > and
On Sat, May 02, 2020 at 03:39:50PM -0300, Soni L. wrote:
> def foo():
> yield from ()
> raise ValueError
def foo():
yield from ()
raise ValueUnpackingError
Does that help?
--
Steven
___
Python-ideas mailing list --
On Sat, May 02, 2020 at 01:20:01PM -0300, Soni L. wrote:
>
>
> On 2020-05-02 1:07 p.m., Steven D'Aprano wrote:
> >On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:
> >
> >> how about:
> >>
> >> result = Foo.save()
> >>
On Sat, May 02, 2020 at 12:50:19PM -0300, Soni L. wrote:
> how about:
>
> result = Foo.save()
> try:
> x, y = result
> except ValueUnpackingError:
> return ...
If you do that, what benefit is ValueUnpackingError over just
ValueError?
--
Steven
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 obviously not true -
> there's an `if` statement executed in Python for every item in every
> iterable.
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 to
> use it often and keep their code safe. That to me is the biggest argument
> for this
On Sat, May 02, 2020 at 04:40:49PM +0200, Alex Hall wrote:
> 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 be
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 os, or sys?
> >
>
> Putting math.sin or whatever in builtins makes builtins bigger. Adding a
> flag to
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 correct inputs, and if they
> don't, tell them that they failed in their responsibility.
>
> The underlying
On Fri, May 01, 2020 at 07:41:57PM -0700, Andrew Barnert wrote:
> The most obvious way to do it is borrowing straight out of Haskell, so this:
>
> x `spam` y
>
> … compiles to exactly the same code as this:
>
> spam(x, y)
I really, really want to like that syntax, but I can't. The
On Fri, May 01, 2020 at 09:23:20AM -0700, Christopher Barker wrote:
> I'm not sure how this could reasonably work, but maybe we could standardize
> that all Exceptions have an .errno attribute, and a standard mapping
> between the errorno and a message, or,
>
> Even if most Exceptions would
On Fri, May 01, 2020 at 06:59:01PM -0700, Andrew Barnert wrote:
> >> For example, in 2.x, to get the filename that failed to open, you had
> >> to regex .args[0], and that sucked.
> >
> > Why would you parse the error message when you already have the
> > file name?
> >
> > try:
> >f
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 the zip docstring, and find the flag, and
> their problem is
On Tue, Apr 28, 2020 at 02:46:35PM -, Brandt Bucher wrote:
> Over the course of the last week, it has become surprisingly clear
> that this change is controversial enough to require a PEP.
I cannot imagine why you were surprised about that. Did you already
forget about the experience of
On Fri, May 01, 2020 at 12:28:02PM -0700, Andrew Barnert via Python-ideas wrote:
> On May 1, 2020, at 09:24, Christopher Barker wrote:
> >
> > Maybe it's too late for this, but I would love it if ".errno or similar"
> > were more standardized. As it is, every exception may have it's own way to
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 anti-pattern that shouldn't
> > be encouraged.
> >
>
> I think the PEP is
On Fri, May 01, 2020 at 05:16:00PM -0300, Soni L. wrote:
> >I say again, YAGNI. Give an actual use-case for the excessive
> >generality of your proposal - namely, the ability to provide a custom
> >function. And show that it's better with zip than just with a custom
> >generator function.
>
> we
Hi Gavin,
You have Reply To set to your personal email address instead of allowing
replies to go to the list for everyone to contribute to the discussion.
Was that intentional?
On Fri, May 01, 2020 at 04:53:31PM -, gbs--- via Python-ideas wrote:
> In cases where it makes sense to do
On Fri, May 01, 2020 at 11:36:40AM +0300, Ram Rachum wrote:
> I thought of a third advantage to this approach: Except clauses will be
> easier to understand.
>
> If I'm reading someone's code and I see `except ValueError`, I'm gonna have
> to do a bit of thinking to figure out what exactly
Is "100 more exceptions" hyperbole? Or do you actually mean precisely
one hundred more exceptions?
On Fri, May 01, 2020 at 09:48:21AM +0300, Ram Rachum wrote:
[...]
> I know it'll raise a ValueError, because I've memorized that, but it did
> take me a few years to remember where I should
On Wed, Apr 29, 2020 at 01:42:05PM +0300, Ram Rachum wrote:
> I was iterating through items of a deque, and in some cases I wanted to
> delete an item that I've found.
Deleting items from a container while iterating through it is an
anti-pattern, easy to get wrong, prone to bugs, and in a
On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote:
> It seems like you would get just about everything you want with one line:
>
> once = lru_cache(maxsize=None)
But is it thread-safe? If you have a "once"ed expensive function with
side-effects, and a second thread calls
On Mon, Apr 27, 2020 at 09:21:41AM -0700, Andrew Barnert wrote:
> But this doesn’t do what the OP suggested; it’s a completely different
> proposal. They wanted to write this:
>
> zipped = zip(xs, ys).skip()
>
> … and you’re offering this:
>
> zipped = zip.skip(xs, ys)
>
> That’s a
On Sun, Apr 26, 2020 at 09:58:46PM -0400, Dan Sommers wrote:
> > How many beginners do you know who even know what a LRU cache is?
>
> The same number of beginners who know to look in functools for a
> decorator called once?
Look in *functools* at all? Probably not that many.
Google for "how
On Tue, Apr 28, 2020 at 12:40:34PM +1200, Greg Ewing wrote:
> I don't think "once" is a bad name, but we shouldn't kid
> ourselves that it will be intuitive or discoverable to
> anyone who isn't familiar with Eiffel.
I'm not particularly wedded to "once" specifically, but honestly I think
that
On Mon, Apr 27, 2020 at 07:58:54AM -0700, Ethan Furman wrote:
> On 04/27/2020 05:09 AM, Steven D'Aprano wrote:
> >On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
>
> >>How many beginners know they want to call a function only once?
> >
> >More t
On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote:
> >How many beginners do you know who even know what a LRU cache is?
>
> How many beginners know they want to call a function only once?
More than the number who know about LRU caches.
Ethan, are you objecting to a self-descriptive
On Sun, Apr 26, 2020 at 06:43:06PM +0200, 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
> function without arguments). It seems like a good way to cause confusion,
>
On Sun, Apr 26, 2020 at 05:31:22PM +0100, Tom Forbes wrote:
> > What if the functions requires arguments? How to cache calls with
> > different arguments? What if some arguments are not hashable?
>
> Then I think lru_cache is perfectly suitable for that use case. `once()`
> would only be useful
On Sun, Apr 26, 2020 at 04:13:27PM -0700, Andrew Barnert via Python-ideas wrote:
> But if we add methods on zip objects, and then we add a new skip()
> method in 3.10, how does the backport work? It can’t monkeypatch the
> zip type (unless we both make the type public and specifically design
>
On Sun, Apr 26, 2020 at 10:34:27PM +0100, Daniel Moisset wrote:
>- we could add methods to the zip() type that provide different
>behaviours. That way you could use zip(seq, seq2).shortest(), zip(seq1,
>seq2).equal(), zip(seq1, seq2).longer(filler="foo") ; zip(...).shortest()
>
On Sat, Apr 25, 2020 at 09:39:14AM -0700, Christopher Barker wrote:
[...]
> > File handling code ought to be resilient in the face of such meaningless
> > differences,
>
> sure. But what difference is "meaningless" depends on the use case. For
> instance, comments or blank lines in the middle of
On Fri, Apr 24, 2020 at 06:07:06PM -, Brandt Bucher wrote:
> 1. Likely the most common case, for me, is when I have some data and
> want to iterate over both it and a calculated pairing:
>
> >>> x = ["a", "b", "c", "d"]
> >>> y = iter_apply_some_transformation(x)
> >>> for a, b in zip(x,
On Thu, Apr 23, 2020 at 09:10:16PM -0400, Nathan Schneider wrote:
> How, for example, to collate lines from 3 potentially large files while
> ensuring they match in length (without an external dependency)? The best I
> can think of is rather ugly:
>
> with open('a.txt') as a, open('b.txt') as b,
On Thu, Apr 23, 2020 at 04:24:18PM -0400, Dan Sommers wrote:
> On Thu, 23 Apr 2020 14:47:48 -0400
> Kyle Lahnakoski wrote:
> > Many of the function keyword parameters I deal with are data property
> > names; so it makes sense that the data has the same name throughout the
> > codebase. The
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> I've
> recently posted my code on this list, something about a class
> LogAndCompare[1]. it's horrible. a bit of zip and it could be a bit
> nicer. but I need those partial results.
>
> [1]
>
On Wed, Apr 22, 2020 at 01:26:02PM -0700, Andrew Barnert wrote:
> > On Apr 21, 2020, at 16:02, Steven D'Aprano wrote:
> >
> > On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas
> > wrote:
> >>> On Apr 21, 2020, at 01:36, Serhiy Storch
On Wed, Apr 22, 2020 at 10:33:24AM -0700, Andrew Barnert via Python-ideas wrote:
> If that is your long-term goal, I think you could do it in three steps.
I think the first step is a PEP. This is not a small change that can be
just done on a whim.
> And of course after the first two steps you
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> are there *any* solutions for getting partial results out of zip with
> different-length iterators of unknown origin?
No. If you want to continue getting results even when one or more of
the iterators is exhausted, `zip` is the wrong
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
> You can basically use the code from this StackOverflow answer (code
> attached below) to cache the last object yielded by each iterator:
> https://stackoverflow.com/a/61126744
Caching the result of iterators is unsafe if the
On Wed, Apr 22, 2020 at 01:07:07AM +0200, Antoine Pitrou wrote:
> On Wed, 22 Apr 2020 08:34:56 +1000
> Steven D'Aprano wrote:
> > On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
> > > 21.04.20 11:15, Antoine Pitrou пише:
> > > >Of course, t
On Mon, Apr 20, 2020 at 07:47:51PM -0700, Andrew Barnert wrote:
> >> counter = itertools.count()
> >> yield from zip(counter, itertools.chain(headers, [''], body, [''])
> >> lines = next(counter)
> >
> > That gives you one more than the number of lines yielded.
>
> Yeah, I screwed that up in
On Tue, Apr 21, 2020 at 02:33:04PM -, Brandt Bucher wrote:
> > Sure, but I think cases where you want that assumption _checked_ are a lot
> > less common. There are lots of postconditions that you assume just as often
> > as “x, y, and z are fully consumed” and just as rarely want to check,
On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas wrote:
> On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
> >
> >except ValueError: # assuming that’s the exception you want?
>
> For what it’s worth, more_itertools.zip_equal raises an
> UnequalIterablesError,
On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
> 21.04.20 11:15, Antoine Pitrou пише:
> >Of course, the fact that zip() is the shorter form that everyone is
> >used to means that, even if a `strict` argument is added, few people
> >will bother adding it.
>
> The possible
On Wed, Apr 22, 2020 at 01:25:14AM +1000, Chris Angelico wrote:
> That'd make it show up as the exception's 'value', not in its args. If
> indeed there's no guarantee, then I would fully support this change -
> should be a non-breaking change and could be convenient.
Convenient for what?
--
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where they
> brought up the lack of peekable/unput iterators in the context of
> getting a count out of an iterator.
I've seen it, as far as I can tell there are already good
On Mon, Apr 20, 2020 at 10:23:29PM +0200, Alex Hall wrote:
> 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
> > >
On Mon, Apr 20, 2020 at 08:42:00PM +0300, Ram Rachum wrote:
> Here's something that would have saved me some debugging yesterday:
>
> >>> zipped = zip(x, y, z, strict=True)
>
> I suggest that `strict=True` would ensure that all the iterables have been
> exhausted, raising an exception
On Mon, Apr 20, 2020 at 03:28:09PM -0700, Andrew Barnert via Python-ideas wrote:
> Admittedly, such cases are almost surely not that common, but I
> actually have some line-numbering code that did something like this
> (simplified a bit from real code):
>
> yield from
On Mon, Apr 20, 2020 at 10:03:50AM +0200, M.-A. Lemburg wrote:
> Guys, is it really worth saving a few hits on the auto-complete key
> by adding even more mysterious twists to the existing Python function
> call syntax ?
>
> The current version already strikes me as way too complex.
> It's by far
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:
> > > >
> > > > And notice that there is absolutely no difficulty with some
On Sun, Apr 19, 2020 at 10:50:55PM +0200, Alex Hall wrote:
> I think I'm uniquely qualified to say with certainty that this is 100% not
> true. A basic version like Q("email firstname lastname") like you wrote is
> indeed easy to do correctly, but I've said why I wouldn't want to use it
> and I
On Sun, Apr 19, 2020 at 04:14:51PM -0400, David Mertz wrote:
> 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]
> ...
On Sun, Apr 19, 2020 at 06:06:50PM +0200, Alex Hall wrote:
> >
> > >> 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
On Sun, Apr 19, 2020 at 02:34:35PM -0400, Eric V. Smith wrote:
> I'd be only -0.5 on any proposal from this thread (as opposed to -1000
> as I am now) if it were more general purpose than just function calls.
[...]
> My point is: We already have a way to pass the items in a dictionary as
>
On Sun, Apr 19, 2020 at 11:58:01AM -0400, David Mertz wrote:
> Understand that I'm not really advocating for a magic function like Q(). I
> think it's important to keep in mind that anyone COULD create such a thing
> for 20 years, and very few people bothered to.
You don't really know how many
On Mon, Apr 20, 2020 at 02:50:53AM +1200, Greg Ewing wrote:
> On 19/04/20 6:58 pm, Steven D'Aprano wrote:
> >There are three tokens there: `**{`, an identifier, and `}`. Adding an
> >optional comma makes four.
> >
> >If this is your idea of "complicated syntax&qu
On Sun, Apr 19, 2020 at 09:28:28AM -0400, Eric V. Smith wrote:
[...]
> >This will cause a slight reduction in readability of code, as cases of
> >foo = phoo, start to stand out and get changed to just foo (by renaming
> >the variable phoo). It is a natural outcome of you get what you make
>
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 arguments.
> >
>
> We've already discussed in this thread that we shouldn't fear conflicting
> with
On Sun, Apr 19, 2020 at 12:09:54PM +0200, Alex Hall wrote:
> > Please read what I said again, because that's a mischaracterisation of
> > what I said.
>
> I don't think it is. You said 'it ought to be something "like" an
> expression', and then that actually being an expression is not essential.
On Sat, Apr 18, 2020 at 09:13:44PM +0200, Dominik Vilsmeier wrote:
>
> func(foo, **, bar) vs. func(foo, **{bar})
>
> It's still a mode switch, only the beginning and end markers have
> changed. Instead of `**,` (or `**mapping,`) we then have `**{` as the
> opening marker
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 are
> requiring something that looks like an expression even if it isn't.
Please read what I
On Sun, Apr 19, 2020 at 01:24:14AM +1000, Chris Angelico wrote:
[...]
> Alex referred to refactoring "text that looks like an expression", and
> on that point, I absolutely agree with Steven here: there are MANY
> places where "text that looks like an expression" can have vastly
> different
On Sun, Apr 19, 2020 at 02:30:21PM +1200, Greg Ewing wrote:
> On 19/04/20 7:17 am, Alex Hall wrote:
> >there
> >is something about all these examples (plausibility?) that feels
> >distinctly different from your proposal.
>
> To me it seems like an unnecessarily complicated syntax that goes
>
On Sat, Apr 18, 2020 at 12:19:30PM -0400, David Mertz wrote:
> On Sat, Apr 18, 2020, 8:15 AM Alex Hall wrote:
>
> > Under your proposal, these two programs are both valid syntax with
> > different meanings:
> >
> > (1)
> >
> f(**{u, v})
> >
> > (2)
> >
> x = {u, v}
> > f(**x)
> >
>
> I don't
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, v}`
> is an expression, it represents a set, and it always represents that
> wherever you
On Sat, Apr 18, 2020 at 12:42:10AM -0700, Andrew Barnert wrote:
> > Inside function calls, the syntax
> >
> > **{identifier [, ...]}
> >
> > expands to a set of `identifier=identifier` argument bindings.
> >
> > This will be legal anywhere inside a function call that keyword
> > unpacking
On Fri, Apr 17, 2020 at 11:21:39AM -0700, Andrew Barnert wrote:
> > On Apr 17, 2020, at 01:58, Steven D'Aprano wrote:
[...]
> > After saving this draft, closing the email, then reopening it, I read
> > the proposed dict the same way. So I don't think it was just a momentary
On Fri, Apr 17, 2020 at 11:39:41PM -0700, Andrew Barnert wrote:
> On Apr 17, 2020, at 21:01, Steven D'Aprano wrote:
> >
> > On Sat, Apr 18, 2020 at 10:23:59AM +1200, Greg Ewing wrote:
> >
> >> Think football pass, not quiz show pass.
> >
> > That a
On Sat, Apr 18, 2020 at 10:21:46AM +1200, Greg Ewing wrote:
> On 18/04/20 1:56 am, oliveira.rodrig...@gmail.com wrote:
> >This should be valid syntax:
> >
> >```python
> >return render_template("index.html", *,
> > twitter, username=user["display_name"],
> > channel, channelid, error,
> >
This proposal is an alternative to Rodrigo's "Keyword arguments
self-assignment" thread.
Rodrigo, please feel free to mine this for useful nuggets in your PEP.
(I don't claim to have invented the syntax -- I think it might have been
Alex Hall?)
Keyword Unpacking Shortcut
On Fri, Apr 17, 2020 at 03:33:56PM -0400, David Mertz wrote:
> I think I'm the first person to mention Lisp symbols. Maybe not
> though.
I know it's not a competition, but I think Stephen Turnbull beat you by
five hours :-)
(At least if I can do timezone calculations correctly.)
--
On Sat, Apr 18, 2020 at 10:23:59AM +1200, Greg Ewing wrote:
> On 18/04/20 1:53 am, Steven D'Aprano wrote:
> >On Sat, Apr 18, 2020 at 12:22:36AM +1200, Greg Ewing wrote:
> >>Here's another idea for the bikeshed:
> >>
> >>f(spam, pass eggs, ham)
>
1201 - 1300 of 2842 matches
Mail list logo
