Everyone in this thread should absolutely read Lewis Caroll's delightful
and "What the Tortoise Said to Achilles." It's a very short 3-page story
that addressed exactly this topic in 1895... even before Guido's Time
Machine.
One free copy of the public domain work is at:
We had this discussion about a year and a half ago, in which I strongly
advocated exactly this keyword argument to median*().
As before, I don't care about the default if there is an option. I don't
even really care about the exception case, but don't object to it.
On Mon, Aug 23, 2021 at 11:55
On Thu, Aug 26, 2021, 6:46 AM Marc-Andre Lemburg
> Fair enough. Would it then make sense to at least have all possible NAN
> objects compare equal, treating the extra error information as an attribute
> value rather than a distinct value and perhaps exposing this as such ?
>
No, no, no!
Almost
On Sat, Aug 28, 2021, 8:34 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> David Mertz, Ph.D. writes:
> > > NANs do not necessarily represent missing data.
>
> > I think in the context of `stats` they do. But this is color of
> bikeshed, and I defer
There doesn't SEEM to be any way to get a non-singleton None in Python 1.0
% python
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> x = None
>>> type(x)
>>> id(None)
6587488
>>> y = None
>>> x is y
1
>>> id(x)
6587488
Restarting the interpreter, I
If it is not 100% obvious, I would strongly advice any IDE or linter
against disabling E711 as a default.
I'm not a contributors to any of those, so it's not my decision. But were
anyone to ask me...
Moreover, I would strongly discourage any instructor from papering over the
difference between
On Wed, Sep 1, 2021, 11:55 AM Christopher Barker
wrote:
> Can you redefine the name, “None” in ancient Python?
>
I didn't show it in my earlier post, but in Python 1.0.1, you an indeed
rebind the name None (much as you could True/False until 2.4 or
something... I probably have the version wrong
specialized to the purpose at hand.
On Tue, Aug 24, 2021, 6:14 PM David Mertz, Ph.D.
wrote:
> This is easy enough to put in your own toolkit:
>
> >>> is_empty = bool
>
> All done!
>
> On Tue, Aug 24, 2021, 6:04 PM Tim Hoffmann via Python-ideas <
> python-ideas
This is easy enough to put in your own toolkit:
>>> is_empty = bool
All done!
On Tue, Aug 24, 2021, 6:04 PM Tim Hoffmann via Python-ideas <
python-ideas@python.org> wrote:
> I also have the feeling that this is going round in circles. So let me get
> back to the core question:
>
> **How do you
I wanted to do a survey of various "aggregates" in Python to see if any
stand out as making the usual `if stuff: ...` troublesome. I wrote a
little script at
https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
.
I'm being deliberately vague about an "aggregate." It
gt; David Mertz, Ph.D. writes:
>
> > > I have a distribution for you: Cauchy. :-)
> > >
> >
> > Oh? Because NaN is the *result* of `stats.variance(cauchy)`?
> >
> > It still seems like as INPUTS to a stats function NaN ~= missing.
>
> Well, th
It really feels now like you are TRYING to miss the point of equality and
identity, and why 'is None' checks are the correct approach to recommend.
Here's a slightly contrived, but not absurd function. I've certainly
written a great many that follow this general form.
>>> def
EVERY line you found would behave incorrectly if changed to "x == None".
Admittedly, doing so would require setting the various variables and
attributes to somewhat uncommon objects that act "funny" when comparing to
None. Or when doing equality comparisons in general.
As others have said,
"is" don't exist - if someone is coding up
> something where detecting if something is a copy is needed, then "is" is
> the way. However, requiring "is" for None and False and all these other
> super-common singletons .. I don't see why we can't just let them use ==.
>
Nick. I think you should realize that I—and a number of the other people
who dislike your elliding the difference between equality and identity—also
teach beginning programmers.
> 1. You could use "is", and say "It's most proper to use "is" when
> comparing to certain values, including None
Most Pandas read methods take either a path-like argument or a file-like
argument, and figure out which it is by introspection when called.
Actually, most of them even accept a URL-like argument as well
I don't think this is a terrible approach. It doesn't make things quite as
explicit as the
On Wed, Sep 1, 2021 at 12:45 PM Kevin Mills
wrote:
> d = {1: {2: {3: 4}}}
> keys= 1,2,3
> print(d[*keys]) # Meaning: d[1][2][3]
> d[*keys] = None
> print(d)
This is a bad idea for a couple reasons.
One reason MRAB points to. The `*keys` syntax is more-or-less equivalent
to "substitute a
Honestly, the construct of `lambda x=x: stuff(x)` in a loop or
comprehension isn't that hard to learn.
Yes, I've also forgotten it and tripped over that. But then, I've also
banged my head on the wall when I use a language with block scope and
forget that variables won't be available after the
As I wrote before, I think a multi-getter FUNCTION is a useful thing. In
fact, I linked to several libraries that provide variations on the idea.
But there are a number of choice to make about the behavior of that, and
absolutely no reason it needs to be in the standard library, let alone a
> Except that it would still be the case that
> >
> > >>> factorial(23) == factorial(23.0)
> > False
>
> Sure, but if simple type dispatch (generic functions) was built into the
> language, people would be perfectly comfortable with the idea that two
> functions with the same name but accepting
This feature request comes about 196 days to early.
It is perhaps worth considering on April 1, but not in September.
On Fri, Sep 17, 2021 at 8:59 AM Jeremiah Vivian <
nohackingofkrow...@gmail.com> wrote:
> NEW_FEATURE = "remove_barry_from_BDFL" or
>
On Tue, Sep 14, 2021, 11:17 PM Finn Mason wrote:
> I disagree. The way I see it, `pathlib` is home of *Path(). No functions.
> Just *Path(). Then again, I didn't write pathlib. I could be
> misunderstanding the intent.
>
When I wrote "in" I was thinking more of a method than a function. E.g.
I think this would be convenient.
And yes, it's not thread safe. But neither is os.chdir() to start with.
Someone whose script, or library, wants to chdir can already shoot
themselves in the foot. This makes that slightly less likely, not more.
In terms of the bikeshed color, I think putting
I've never used compress() either. But I probably HAVE selected only the
"truthy" elements of an iterable. The obvious way to do that is:
it = (x for x in it if x)
It feels like changing compress() would just be more obscure, but not add
to clarity.
On Mon, Sep 13, 2021, 5:07 PM Rob Cliffe via
On Sat, Sep 11, 2021 at 9:20 AM Juancarlo Añez wrote:
> I'm happy about dropping the DBC theme and rebooting to make *assert* easier
> to use so it gets used more.
>
I agree with Steven, Marc-Andé, and others in seeing "using assertions
more" as an anti-goal.
This isn't to say that a given
those go away with just a "-O".
>
> I won't vouch for an *"invariant"* statement, because that's probably too
> much to ask for.
>
> So I'll just use *"if"* to assert more invariants in the code I write.
>
> Cheers,
>
> On Sat, Sep 11, 2021 at 2
On Sat, Oct 9, 2021, 10:44 PM Steven D'Aprano
> Apart from a programming exercise and teaching moment, why would you want
> to get a random key and value from a dict? In 25-ish years of using Python,
> I think that the number of times I've needed to do that is zero. A random
> item from a list,
I've known and relied on the behavior since Python 1.4. I mean, not often,
but it's been consistent.
In the case where I want to loop over what the loop was at start, rather
than what it might become, a slice comes in handy:
for item in mylist[:]:
# do stuff, maybe mutate list
On Sat, Oct
] Re: Semi-proposal: Tagged None
To: Python-Dev
On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
wrote:
>
> On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano
wrote:
>>
>> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
>> > None and its ilk often
This is indeed largely the same motivation as PEP 661, which I supported
when raised, but got no clear consensus.
"Missing" is definitely a family of related sentinels, although sentinels
are more general.
On Thu, Oct 21, 2021, 10:15 PM Doug Swarin wrote:
> I think this is a really good and
On Sat, Oct 16, 2021, 12:08 PM Steven D'Aprano
> unpacking in *comprehensions*.
>
> # not currently permitted
> [*s for s in ["abc", "def", "ghi"]]
>
> > Moreover, it is an anti-pattern to create large and indefinite
> sized tuples,
>
> Is it? In what way?
>
As mentioned, I clipped the
On Mon, Oct 18, 2021 at 6:15 PM Matt del Valle wrote:
> I think what's being discussed in this thread is variations on the fluent
> interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface).
>
> with Schedule(...) as schedule:
>
>
What you want was popular in Cobol. That language has generally lost favor
for current development, but lots of it is still around.
Still, I don't want Python to try to be Cobol. I think the intellectual
argument for "English syntax" failed, notwithstanding installed base.
On Mon, Oct 18, 2021,
What you are describing is very, very dissimilar to currying. It's simply
multi-argument functions with a different call syntax.
Moreover, this hypothetical syntax would make no sense at all for 99% of
the functions I write or call. There are a very small number of functions
where a conceivable
POn Sat, Oct 16, 2021, 10:10 AM Erik Demaine
> (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> [*it1, *it2, *it3] # list with the concatenation of three iterables
> {*it1, *it2, *it3} # set with the union of three iterables
> {**dict1, **dict2, **dict3} # dict with the
On Sat, Oct 16, 2021, 11:42 AM Erik Demaine
> > But the first one is much more suggestive of a generator comprehension. I
> > would want/expect it to be equivalent to itertools.chain(), not create a
> > tuple.
>
> I guess you were referring to `(*it for it in its)` (proposed notation)
> rather
>
I find myself using exactly that "picture of the data" approach informally
for code I don't plan on formally type checking (but want to show intent).
E.g.
def myfun(data: {str: [CustomType]}) -> [(int, OtherType)]: ...
Maybe it's a bad habit, but it feels easier to parse visually than the real
On Sat, Oct 2, 2021, 10:58 AM Guido van Rossum wrote:
> Are you actually observing that people are doing this with regular lists?
> Don't people working with Big Data usually use Pandas, which is built on
> NumPy arrays and custom data structures?
>
Basically, Guido is right. Big data lives in
On Sun, Oct 3, 2021, 1:46 AM Christopher Barker
> The if __name__ block is only required for a Python file to be both a
> module and a script.
> That’s actually a pretty uncommon thing— if it’s a module to be imported
> by other modules, then it probably should be part of a package, and if the
>
I like the statsmodels spelling better: missing : str; Available options
are ‘none’, ‘drop’, and ‘raise’
But this is bikeshed painting if the options exist.
However, I WOULD urge the argument to take EITHER a string OR an enum. I
don't think any other libraries mentioned do that, but it would
On Sat, Aug 28, 2021, 1:58 AM Steven D'Aprano wrote:
> On Sat, Aug 28, 2021 at 01:36:33AM -0400, David Mertz, Ph.D. wrote:
>
> > I like the statsmodels spelling better: missing : str; Available options
> > are ‘none’, ‘drop’, and ‘raise’
>
> NANs do not necessarily repr
On Sun, Oct 24, 2021, 12:25 AM Guido van Rossum
> I am worried that this side-thread about dynamic scopes (which are a
> ridiculous idea IMO) will derail the decent proposal of the PEP.
>
It's really not a suggestion about dynamic scoping but about more
generalized deferred computation.
This
narrow use.
On Sun, Oct 24, 2021, 9:59 AM Steven D'Aprano wrote:
> On Sun, Oct 24, 2021 at 09:39:27AM -0400, David Mertz, Ph.D. wrote:
>
> > This has been a topic of other threads over the years, and something I've
> > wanted at least since I first worked with Dask's 'd
On Sun, Oct 24, 2021, 12:20 AM Chris Angelico
> How would it know to look for a and b inside fn2's scope, instead of
> looking for x inside fn2's scope?
>
The same way 'eval("a+b")' knows to look in the local scope when evaluated.
I mean, of course 'x' could be rebound in some scope before it
On Sun, Oct 24, 2021, 10:11 AM Chris Angelico
> Not sure I understand. Your example was something like:
>
> def fn2(thing):
> a, b = 13, 21
> x = 5
> print("Thing is:", thing)
>
> def f(x=defer: a + b):
> a, b = 3, 5
> fn2(defer: x)
> return x
>
> So inside f(), "defer: a
On Sat, Dec 4, 2021, 11:13 PM Chris Angelico
> Not sure I'm understanding you correctly; in what way are named parameters
> relevant here?
>
def add(a, b):
return a+b
How could you write that differently with your PEP (which only pertains to
named parameters, not positional)?
>
On Sat, Dec 4, 2021 at 11:25 PM Chris Angelico wrote:
> > def add(a, b):
> > return a+b
> > How could you write that differently with your PEP
>
> I wouldn't. There are no default arguments, and nothing needs to be
> changed.
>
I do recognize that I *could* call that with named arguments.
On Sat, Dec 4, 2021, 10:14 PM Rob Cliffe via Python-ideas
> The designers of 12 languages have chosen to provide late binding; those
> of 3 or 4 have provided early binding.
> I think this is at least tenuous evidence in favour of my belief that late
> binding is more useful than early binding.
>
On Tue, Dec 28, 2021 at 1:15 AM Christopher Barker
wrote:
> On Mon, Dec 27, 2021 at 4:07 PM Steven D'Aprano
>
>> Julia (if I recall correctly) has a nice syntax for automatically
>> turning any function or method into an element-wise function:
>
>
> And numpy has an even easier one:
>
d you call `bar := Bar()` if not "an iterator?!
On Sun, 2021-11-28 at 22:02 -0500, David Mertz, Ph.D. wrote:
>
> On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano
>
> To be an iterator, your object needs:
>
> 1. a `__next__` method which returns the next value;
> 2. and an `__iter
On Sun, Nov 28, 2021, 7:49 PM Christopher Barker
> One example was a proposal a while back on this list for a "groupby" in
> itertools (it kind of withered on the vine, like many good ideas here), I
> suggested that it be made comprehension friendly, and some others including
> the OP) didn't see
On Sun, Nov 28, 2021, 8:59 PM Steven D'Aprano
> To be an iterator, your object needs:
>
> 1. a `__next__` method which returns the next value;
> 2. and an `__iter__` method which returns self.
>
That's not quite right.
An iterator only needs .__next__(), and an iterable only needs .__iter__().
nd Bar classes are slightly contrived, but I've written production
code where e.g. `iter(thing)` returns a new `thing.__class__` instance
rather than self.
> On Mon, 2021-11-29 at 00:11 -0500, David Mertz, Ph.D. wrote:
>
> On Sun, Nov 28, 2021, 11:43 PM Paul Bryan wrote:
>
&g
quot;return self" is *usually* a
perfectly good implementation.
> On Mon, 2021-11-29 at 00:22 -0500, David Mertz, Ph.D. wrote:
>
> On Mon, Nov 29, 2021, 12:16 AM Paul Bryan wrote:
>
> And the second link?
>
>
> Same comments, basically. But the more germane thing is th
On Mon, Nov 29, 2021 at 5:15 AM Steven D'Aprano wrote:
> - the method modifies the object in place, and returns self;
> - versus the method returns a new, modified, copy of the object.
> Pandas uses the first style (I think; corrections welcome). Strings use
> the second, because they have no
On Sat, Oct 30, 2021, 6:29 PM Chris Angelico wrote:
> > At first I thought it might be harmless, but nothing I really care
> about. After the discussion, I think the PEP would be actively harmful to
> future Python features.
>
It's nothing more than an implementation detail. If you want to
On Sat, Oct 30, 2021, 11:03 PM Chris Angelico
> That's if you were to create a deferred *type*. An object which can be
> evaluated later. My proposal is NOT doing that, because there is no object
> that represents the unevaluated expression. You can't pull that expression
> out and evaluate it
I'm -100 now on "deferred evaluation, but contorted to be useless outside
of argument declarations."
At first I thought it might be harmless, but nothing I really care about.
After the discussion, I think the PEP would be actively harmful to future
Python features.
On Sat, Oct 30, 2021, 3:57 PM
On Sat, Oct 30, 2021, 9:40 PM Chris Angelico wrote:
> > I'm not sure what I think of a general statement like:
> >
> > @do_later = fun1(data) + fun2(data)
> >
> > I.e. we expect to evaluate the first class object `do_later` in some
> other context, but only if requested within a program
On Tue, Oct 26, 2021, 1:08 PM Chris Angelico wrote:
> No, I agree. We have to still be able to introspect them.
>
> At the moment, when you look at a function's defaults, they are all
> values. With this change, some would be values and some would be markers
> saying that code would be executed.
On Tue, Oct 26, 2021, 7:20 PM Chris Angelico
> The truth is that there is no value that can be a truly universal
> representation of absence, so it *always* has to be specific to each API.
>
That's a fact about Python rather than a fact of programming in general.
For example, R has a NULL that
My "vote" if one has to be chosen:
#1: x=defer default
#2: @x=default
#3: x=@default
#4: x=>default
#5:. *x=default
Explicit is better than implicit.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On Wed, Nov 3, 2021, 9:19 PM Rob Cliffe via Python-ideas
> Some people clearly need it, viz. those who use a default such as `[]` and
> then ask on Stack Overflow why they get surprising results.
This is silly. All those folks on StackOverflow are told "use a sentinel."
The fact beginners can
On Sun, Oct 31, 2021, 8:59 AM Chris Angelico
> def foo1(a=>[1,2,3], b=>len(a)):
> a.append(4)
> print(b)
>
> And what is the correct behaviour here?
>
> def foo2(a=defer [1,2,3], b=defer len(a)):
> a.append(4)
> print(b)
>
This is a nice example. I agree they are different in the
On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas
> PEP 671 will be USEFUL to Python programmers. We want it! (When do we
> want it? Now!)
>
This feels dishonest. I believe I qualify as a Python programmer. I started
using Python 1.4 in 1998. The large majority of my work life since
On Sun, Oct 31, 2021, 6:11 PM Chris Angelico
> On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D.
> wrote:
> > I am not on the SC, so indeed I won't make the decision. But I *will*
> continue to teach Python. New syntax adds a burden to learners, and it
> should not be
On Mon, Oct 25, 2021, 8:20 AM Marc-Andre Lemburg
> If I instead write:
>
> def process_files(processor, files=deferred(os.listdir(DEFAULT_DIR))):
>
> it is pretty clear that something is happening at a different time than
> function definition time :-)
>
> Even better: the deferred() object can
I like this. I think explicitly discussing order of inclusion would be
worthwhile. I know it's implied by the approximate equivalents, but
actually stating it would improve the PEP, IMO.
For example:
nums = [(1, 2, 3), (1.0, 2.0, 3.0)]
nset = {*n for n in nums}
Does 'nset' wind up containing
, Oct 25, 2021, 10:22 PM Chris Angelico wrote:
> On Tue, Oct 26, 2021 at 1:10 PM David Mertz, Ph.D.
> wrote:
> >
> > I like this. I think explicitly discussing order of inclusion would be
> worthwhile. I know it's implied by the approximate equivalents, but
> actually stat
>From what I've seen so far, I'm -0 on this.
I understand the pattern it addresses, but it doesn't feel all that common,
nor that hard to address with the existing sentinel-check pattern alien in
the PEP draft.
This just doesn't feel big enough to merit it's own syntax.
... On the other hand,
On Sat, Oct 23, 2021, 10:58 PM Steven D'Aprano
> > ... On the other hand, if this could express a much more general
> deferred computation, I'd be really enthusiastic (subject to syntax and
> behavioral details).
> >
> > However, I recognize that a new general "dynamically scoped lambda"
> would
On Sat, Oct 23, 2021, 11:28 PM Chris Angelico wrote:
> > So stawman proposal:
> >
> > def fun(seq, low=0, high=defer: len(seq)):
> > assert low < high
> > # other stuff...
> >
> > Where the implication here is that the "defer expression" creates a
> dynamic scope.
>
> At what point
On Sat, Oct 23, 2021, 11:46 PM David Mertz, Ph.D.
> def f(x=defer: a + b):
>> a, b = 3, 5
>> return x
>>
>> Would this return 8, or a defer-expression? If 8, then the scope isn't
>> truly dynamic, since there's no way to keep it deferred until it mo
On Thu, Dec 2, 2021 at 2:40 PM Chris Angelico wrote:
> How is a late-bound default different from half of a conditional
> expression?
>
> def f(lst=>[], n=>len(lst)):
> def f(*args):
> lst = args[0] if len(args) > 0 else []
> n = args[1] if len(args) > 1 else len(lst)
>
Although
On Wed, Dec 1, 2021 at 9:24 AM Paul Moore wrote:
> I think that the only
> thing I might use it for is to make it easier to annotate defaults (as
> f(a: list[int] => []) rather than as f(a: list[int] | None = None).
>
Why not `f(a: Optional[list[int]] = None)`?
I'm not counting characters, but
On Wed, Dec 1, 2021 at 10:12 AM Chris Angelico wrote:
> On Thu, Dec 2, 2021 at 12:42 AM David Mertz, Ph.D.
> wrote:
> >> 4) If "no" to question 1, is there some other spelling or other small
> >> change that WOULD mean you would use it? (Some examples in the
On Wed, Dec 1, 2021 at 1:18 AM Chris Angelico wrote:
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
>
No.
... except in the sense that as I trainer I have to teach the warts in
Python, and would need to warn students they might see that.
> 2)
On Wed, Dec 1, 2021, 10:38 PM Steven D'Aprano
> "If param is missing **or None**, the default if blah..."
> I reject Chris' characterisation of this as a hack. There are function
> parameters where None will *never* in any conceivable circumstances become
> a valid argument value, and it is safe
On Sun, Dec 5, 2021, 12:33 PM Chris Angelico
> And quite frankly, the tone of this list is sounding like "shut up, go
> away, don't do anything, because there are other proposals that nobody can
> be bothered writing up, but if they existed, they'd be way better than what
> you're doing". Not
On Sun, Dec 5, 2021, 1:48 PM Chris Angelico
> You: "Keep the status quo, all done"
> Also you: "Let's wait for something better"
>
Now is better than never.
Although never is often better than *right* now.
___
Python-ideas mailing list --
On Sun, Dec 5, 2021 at 6:44 PM Steven D'Aprano wrote:
> How do you get nine in the first place? Putting aside *args and
> **kwargs, the existing parameter matrix is either 3x2 or 3x2x∞ depending
> on whether you include types as part of the matrix.
> which makes 3x2 = 6, not 9. Adding a
On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas
> But AIUI (i.e. practically not at all) Dask is about parallel computing,
> which is not the same thing as deferred evaluation, though doubtless they
> overlap. Again AIUI, parallel computing is mainly useful when you have
> multiple
via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 08/12/2021 23:09, David Mertz, Ph.D. wrote:
>
> On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas
>
>> But AIUI (i.e. practically not at all) Dask is about parallel computing,
>> which is not
On Wed, Dec 8, 2021, 1:09 PM Chris Angelico
> Please explain to me *exactly* what your arguments against the current
> proposal are. At the moment, I am extremely confused as to what people
> actually object to,
Cognitive burden ≫ potential benefit.
On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas
> On 08/12/2021 19:27, Paul Moore wrote:
> > The reason deferred objects keep coming up is because they *do* have a
> much more compelling benefit - they help in a much broader range of cases.
>
Can anyone provide some realistic use cases?
it is that it is a much worse way of writing an
existing sentinel check.
On Wed, Dec 8, 2021, 9:09 PM Chris Angelico wrote:
> On Thu, Dec 9, 2021 at 11:47 AM David Mertz, Ph.D.
> wrote:
> >
> > There are tens of concrete examples at the link I gave, and hundreds
> more you can fin
Easy! Look at EVERY Python function that uses a sentinel. They all get a
little bit worse under your proposal.
On Wed, Dec 8, 2021, 9:54 PM Chris Angelico
> > An obvious reason to oppose it is that it is a much worse way of writing
> an existing sentinel check.
> This is what I want to see an
On Thu, Dec 2, 2021 at 3:33 AM Chris Angelico wrote:
> > But it IS stored! There is no way for it to be evaluated
> without it
> > being stored!
> >
> I'm not sure I understand you here. How is the late-bound default
> "stored" when one side of a ternary is "not stored"?
>
This seems
>
> Earlier on the thread, I made a similar point that it would be nice to
> have a way to filter without the redundant for x in x. Though I can’t think
> of a really good way to express it. But as for filtered for loops:
>
> "for thing in
> (x for x in collection if is_interesting(x))"
>
It's
-1
Not every one line function needs to be a method on a built-in type.
I like that tuples have extremely limited methods. Following the iterable
protocol seems fine (also indexable).
If I were forced to endorse one new method for tuples, I doubt `.replace()`
would be in my top five
On Fri, Mar 11, 2022, 2:39 PM wfdc wrote:
> > Not every one line function needs to be a method on a built-in type.
>
> Not every one line function needs to *not* be a method on a built-in type.
> See tuple's count method for an example.
>
Again, if users find themselves re-implementing the same
gt; ------- Original Message ---
> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <
> david.me...@gmail.com> wrote:
>
> On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas <
> python-ideas@python.org> wrote:
>
>> > why haven't you used a list
>>
On Fri, Mar 11, 2022, 4:16 PM wfdc via Python-ideas
wrote:
> > why haven't you used a list
> 2. I don't want to modify the original sequence.
>
There's a really easy solution for you that will even be more perfomant.
Use a list and DON'T modify the original!
This is ABSOLUTELY an
*
> immutability. Otherwise, why aren't you proposing getting rid of the tuple
> type entirely?
>
> --- Original Message ---
> On Friday, March 11th, 2022 at 4:29 PM, David Mertz, Ph.D. <
> david.me...@gmail.com> wrote:
>
> On Fri, Mar 11, 2022, 4:16 PM wfdc via
On Mon, Mar 14, 2022 at 8:33 AM wrote:
> Possible solution:
> s = {} # new empty set
> d = {:} # new empty dictionary (the ":" is a reference to key-value pairs)
>
I have suggested over the years—as have probably dozens of other people
(maybe thousands)—that that would be a great spelling if
On Fri, Mar 11, 2022, 6:19 PM wfdc wrote:
> > Likewise this which you wrote in another post: "Do you see why it's
> useful to have immutability?"
>
> That's not insulting at all. It's a perfectly valid question to address to
> a post that seems to be contesting the purpose of immutable types in
I just do this myself in my text editor (vim):
[image: sets-py.png]
But this is just cosmetic because I like to look at it this way. The
actual file on disk contains `set()`, `<=`, `in`, `not in` and wouldn't be
a problem for anyone without the same fonts installed, or require anyone to
know odd
On Mon, Mar 14, 2022, 7:52 PM Steven D'Aprano
> I got "No results matched your query" on the second URL, at which point I
> didn't bother with the first.
>
Hmm... while I don't support the proposal, I saw results at both links.
Those links were the first good faith comments I saw from OP.
A
Are you speaking of how to generalize modulo to negative numbers (about
which programming languages vary)?
The bar for adding new syntax to Python is VERY high. Probably easier is
getting a function in the `math` module. But even there, you'll need to
explain what behavior you want AND why that
As someone else noted, few of the ideas originating on typing-sig are for
syntax changes.
One might argue that some are "abuse of notation." Generally they are of
the sort "let's support indexing or bitwise operators on some more types"
or let's let more builtin things act as types in
1 - 100 of 199 matches
Mail list logo
