-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
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
>
> 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
I really am shocked by how many people seem to have broken ENTER keys on
their keyboards.
Let's just keep Python readable rather than see how much we can cram on a
line.
On Wed, Mar 2, 2022, 2:56 PM Jeremiah Paige wrote:
> I have on a few occasions wanted a for..in..if statement and if it
-1. Extra complexity for no benefit. Attractive nuisance to making overly
complex statement lines.
On Tue, Mar 1, 2022, 8:31 PM Svein Seldal wrote:
> I'm sorry for reposting, but this message got stuck in moderation
> approval for 5 days so I figured I should try again.
>
>
> I'd like to
"To table" is a contranym in both the US and the UK.
On Tue, Feb 22, 2022 at 9:53 AM MRAB wrote:
> On 2022-02-20 17:56, Stephen J. Turnbull wrote:
> > Gerrit Holl writes:
> >
> > > If voting is limited to a select group (which could be as small as
> > > Python core developers, or as large
I know this is probably too much self promotion, but I really enjoyed
writing this less than a year ago: https://gnosis.cx/regex/ (The Puzzling
Quirks of Regular Expressions).
It's like other puzzle books, but for programmers. You should certainly
still get Friedl's book if you don't have it. You
Don't forget leap seconds! :-)
On Thu, Feb 10, 2022, 11:45 AM Christopher Barker
wrote:
> Since a started this:-)
>
> 1) the complexities are exactly why this *might* be a candidate for the
> stdlib. Those are the things that someone is likely to get wrong, or not
> think of, when they write
This is `collections.Counter`.
On Sat, Feb 5, 2022, 3:19 PM Mirmojtaba Gharibi
wrote:
> Hello there,
>
> I have an idea for initializing a variable the first time it’s created; it
> can especially be helpful with containers, and dicts specifically. Let me
> demonstrate with some examples:
>
>
To do this EVERY object that you might list as alternatives would have to
support `__or__()` and `__ror__()`.
Moreover, for many types, `|` is defined with conflicting meaning. E.g. `3
| 5 | 11 == 15`. But of course 3, 5, 11 aren't the unique collection of
numbers that bitwise or to 15. At
On Tue, Jan 18, 2022, 5:46 PM Steven D'Aprano
> Okay. Without looking it up, how would *you* type ⟮ U+27EE "Mathematical
> Left Flattened Parentheses"? On your honour now, don't look it up.
>
You've kind of given away the game. I'd press "shift-ctrl-u 2 7 e e
". I'm not even at my computer, but
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:
>
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
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
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, 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
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?
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 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 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, 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 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, 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, 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 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 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
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 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 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 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 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
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
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
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, 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__().
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
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, 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 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, 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 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
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 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
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 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
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.
, 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
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
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
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, 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 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, 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
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 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, 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
>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,
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
] 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
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 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
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,
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 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
>
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
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 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
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
>
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
> 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
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
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, 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
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
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
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
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
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
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
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
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
"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 ==.
>
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,
I was thinking of the Cauchy distribution, with undefined variance. But
Augustin-Louis Cauchy had quite a few things named after him. I know best
Cauchy sequences as a construction of Real numbers.
On Sun, Aug 29, 2021, 2:36 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
&
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
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
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 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
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
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
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
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:
I frequently use each of namedtuples and data classes in contexts where the
other one would not be appropriate. Yes, I also sometimes use an object
where either would serve... In those cases, mostly SimpleNamespace would
likewise be fine. So would a one line class definition.
On Wed, Jul 28,
101 - 200 of 1105 matches
Mail list logo