I wonder if The Fuck could be customize to handle these improved error
messages envisioned: https://github.com/nvbn/thefuck
It's a lovely tool. I don't mind the minor profanity, but when I teach I
add an alias of 'fix' for students to see instead.
On Sun, May 10, 2020 at 5:34 PM Christopher Bar
On Sun, May 10, 2020 at 2:17 PM Richard Damon
wrote:
> An error like character (whatever) is not a quote (or is not a minus+0060
> sign) seems similar. It is one thing to not recognize a funny character
> in the language, but to actually parse it well enough to give a message
> that says in effec
On Sun, May 10, 2020 at 4:03 AM Steven D'Aprano wrote:
> I think that David(?) may have a Vim or Emacs mode that allows him to
> use Unicode chars as syntax?
>
I use the vim-conceal plugin: https://github.com/khzaw/vim-conceal. I know
that something similar exists for Emacs, but don't remember
On Fri, May 8, 2020 at 11:39 PM Steven D'Aprano wrote:
> "More important" according to whose needs?
>
I dunno. To mine? To "beginner programmers"? To numeric computation?
I can weaken my 'note' to 'purport' if that helps.
(3) Whereas the proposed duck-typing sequence equality relies on
>
On Fri, May 8, 2020, 6:39 PM Steven D'Aprano
> So what? Why is this relevant? This is not a proposal for a generalised
> equivalence relation. If you want one of those feel free to propose a
> competing idea.
>
The OP, with a certain degree of support from you, is asking for changing
the meaning
On Fri, May 8, 2020 at 1:47 PM Steven D'Aprano wrote:
> All of which are red herrings that are completely off-topic for this
> proposal. This proposal has nothing to do with:
>
> > case_insensitive_eq(a, b)
> > same_json_representation(a, b)
> > allclose(a, b) # A version of this is in NumPy
> >
>
> 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'll go try it, but I won't be sure the answer for every
On Fri, May 8, 2020 at 1:06 PM Steven D'Aprano wrote:
> Whatever we might feel about equality and identity in the wider
> philosophical sense, in the *Python programming sense* the semantic
> meaning of the two operators are orthogonal:
>
> * some equal objects are not identical;
> * and some ide
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 function.
Many different notions of "equivalence for a particular purpose" have been
mentioned. We're not going to get a dozen differ
On Thu, May 7, 2020 at 4:42 AM Kirill Balunov
wrote:
> `chain(*iterable)` converts iterable into a tuple, concretizing it in
>> memory. chain.from_iterable(iterable) is lazy and goes through the elements
>> one a time, meaning iterable can be infinite.
>>
>
> "meaning iterable can be infinite" -
On Thu, May 7, 2020 at 1:26 AM Christopher Barker
wrote:
> > But wait a minute, zip isn't just a "callable", it's a class, and adding
> more methods to it seems perfectly natural, just like lots of other
> built-in classes.
>
>>
>> Zip is a class in CPython 3.8. it may or may not be in other
>> i
On Wed, May 6, 2020 at 10:26 PM Oscar Benjamin
wrote:
> > That's the point though. For *most* functions, the substitution
> principle is fine in Python. A whole lot of the time, numeric functions
> can take either an int or a float that are equal to each other and produce
> results that are equ
On Wed, May 6, 2020, 9:53 PM Eric Fahlgren wrote:
> On Wed, May 6, 2020 at 6:27 PM David Mertz wrote:
>
>> I don't think being a function versus a classmethod is important here.
>> Just that the underlying name is *callable*.
>>
>
> But wait a minute, zip is
On Wed, May 6, 2020, 9:46 PM Chris Angelico
> >> zip.shortest(...) # same as zip(...) / zip.longest(...) /
> zip.checksame(...)
> > If it's a very common pattern, do you know of any in the standard
> library beyond the one I mentioned? Not about bikeshedding the spelling of
> the different const
>> The only precedent that jumps out for me is itertools.chain() and
itertools.chain.from_iterable(). It's quite likely that something
>> I don't use much has used the same pattern though.
I think David is right: itertools.chain.from_iterable() is the only
> place I know of with an attribute on a
On Wed, May 6, 2020 at 8:37 PM Chris Angelico wrote:
> > The only precedent that jumps out for me is itertools.chain() and
> itertools.chain.from_iterable(). It's quite likely that something I don't
> use much has used the same pattern though.
>
> That's an example of a very common pattern of alt
I'm afraid, Oscar, that you seem to have painted yourself into a reductio
ad absurdum. We need a healthy dose of "practicality beats purity" thrown
in here.
What the substitution principle essentially says is
>if x == y then f(x) == f(y)
> for any function f such that f(x) is well defined.
>
The only precedent that jumps out for me is itertools.chain() and
itertools.chain.from_iterable(). It's quite likely that something I don't
use much has used the same pattern though.
On Wed, May 6, 2020, 8:17 PM Christopher Barker wrote:
> On Wed, May 6, 2020 at 10:31 AM Alex Hall wrote:
> zip.
I have no idea whether a flag on zip() or a function in itertools would get
MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for its
own sake though.
I'm +1 on a new function in itertools, maybe +0 or maybe -0 on a flag. But
I only want APPROPRIATE USE in any case. The API conv
Oops. I don't mean any(), but rather 'not all()'. Or alternatively, !=
instead of ==.
Same point though.
On Sun, May 3, 2020, 11:13 PM David Mertz wrote:
> > Here is a comparison of the current zip with more-itertools' zip_equal:
>
>> > So the Python ve
> Here is a comparison of the current zip with more-itertools' zip_equal:
> > So the Python version is about 13 times slower, and 10 million iterations
> > (quite plausible) adds about 2 seconds.
>
> Adds two seconds to *what* though? That's why I care more about
> benchmarks than micro benchmarks
Put this comparison in a function! The current behavior is what I wish '=='
to do, and what millions of lines of Python code assume. A tuple is not a
list is not an array. I don't want an equality comparison to lie to me.
You can write a few lines to implement 'has_same_items(a, b)' that will
beha
On Mon, Apr 27, 2020 at 4:39 PM Christopher Barker
wrote:
> Isn't there? There are many cases where you CANNOT (or don't want to, for
> performance reasons) "consume" the entirely of the inolut iterators, and
> many cases where it would be fine to do that. But are there many (any?)
> cases where
On Sun, Apr 26, 2020 at 11:56 PM Christopher Barker
wrote:
> > If I have two or more "sequences" there are basically two cases of that.
>
> so you need to write different code, depending on which case? that seems
> not very "there's only one way to do it" to me.
>
This difference is built into t
Let me try to explain why I believe that people who think they want
zip_strict() actually want zip_longest(). I've already mentioned that I
myself usually want what zip() does not (i.e. zip_shortest()) ... but
indeed not always.
If I have two or more "sequences" there are basically two cases of t
On Sun, Apr 26, 2020 at 4:42 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> You're missing the topic of the comparison. It is that we could have
>
> removeaffix(source, affix, suffix=True)
> strip(self, chars, where='both') # where in {both, left, right}
>
O
On Sat, Apr 25, 2020, 1:50 PM Kirill Balunov
wrote:
> Python uses such an approach (separate functions) because there are real
> flaws in the mode switching approach? Or just historically?
>
Well, I think I'd say "philosophically." It's not an historical curiosity
like some of the pass-through s
2020 at 10:11 AM David Mertz wrote:
>
>> I have no objection to adding a zip_strict() or zip_exact() to itertools.
>> I am used to the current behavior, and am apparently in minority in not
>> usually assuming common length iterators. Say +0 on a new function.
>>
>
I have no objection to adding a zip_strict() or zip_exact() to itertools. I
am used to the current behavior, and am apparently in minority in not
usually assuming common length iterators. Say +0 on a new function.
But I'm definitely -1 on adding a mode switch to the built-in. This is not
the way P
On Wed, Apr 22, 2020, 4:24 AM Antoine Pitrou
> But, as far as I'm concerned, the number of times where I took
> advantage of zip()'s current acceptance of heteregenously-sized inputs
> is extremely small. In most of my uses of zip(), a size difference
> would have been a logic error that deserves
The more I read the discussion, the more zip_strict() feels like an
anti-pattern to me.
I've used zip_longest occasionally, but never really hit a need for
zip_strict() ... which obviously I could have written in a few lines if I
wanted it.
Since I never know how many elements an iterator has let
On Sun, Apr 19, 2020 at 11:40 PM Steven D'Aprano
wrote:
def M(*vals):
# ... magic stuff ...
return dct
> py> alpha = 'something'
> py> M(alpha)
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 5, in M
> TypeError: 'NoneT
On Sun, Apr 19, 2020, 10:16 PM Steven D'Aprano 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
Nope, that's fine.
I reckon it's reasonable to call this inspecting the source code. I
thought from your GH issue that you meant you read in a whole module of
code.
I don't want my Q(), or M(), or whatever letter comes after that, in the
standard library. I don't even care about making a repo f
See this thread where I created M() as successor of Q(). It's really not
that hard, I don't think. Probably there are edge cars I haven't addressed,
but it's hardly intractable.
On Sun, Apr 19, 2020, 4:51 PM Alex Hall wrote:
> On Sun, Apr 19, 2020 at 5:59 PM David Me
On Sun, Apr 19, 2020 at 2:37 PM Eric V. Smith wrote:
> So, if M() existed, you could say:
>
> d = M(telephone, name)
> func(**d)
>
> or
>
> func(**M(telephone, name))
>
Per your wish, Eric, the glorious successor of Q() ... named M():
>>> def M(*vals):
... import sys
... import inspect
.
On Sun, Apr 19, 2020 at 11:54 AM Richard Damon
wrote:
> > When it comes time to refactor—now we need to rename 'telephone' as
> > 'home_phone' and add 'cell_phone'—finding all the locations to change
> > is a PITA. If only we could grep 'person_record' globally, it would
> > have been easy.
>
> M
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 want to go with. (And
> status quo is one such alternative, wi
On Sun, Apr 19, 2020, 7:24 AM Richard Damon
wrote:
> One of the key motivations of this proposal is to make nicer a call with a
> lot of key word arguments where the local variable name happens
> (intentionally) to match the keyword parameter name.
I think Stephen said that this "same name acro
> f(**{u, v})
> I think a fundamental point is that `**{identifier}` looks like
> you are applying `**` unpacking to a set, but you actually aren't, it is
> a special syntactic form. If that disturbs you, I'm not going to say you
> are wrong.
>
The special syntactic form doesn't bother me that mu
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 understand what the meaning of (2) would be. Currently it is a
TypeError... Is that "valid" beca
I gladly honor Stephen T, who understands many things, including timezones
better than I do.
On Sat, Apr 18, 2020, 12:35 AM Steven D'Aprano wrote:
> On Fri, Apr 17, 2020 at 03:33:56PM -0400, David Mertz wrote:
>
> > I think I'm the first person to mention Lisp symbols.
, Apr 17, 2020, 5:59 PM Andrew Barnert wrote:
> On Apr 17, 2020, at 13:12, David Mertz wrote:
> >
> > However, proposals for symbols in Python *do* pop
> > up from time to time, so this would perhaps make such a thing harder if
> > it ever becomes desired (which is unlik
st of the guesses I
would make if I had not seen this discussion... of course, if I was
suddenly given a copy of Python 5.2, transported from the distant
future, I would really just type it in the REPL and probably see a
representation that cued me in.
On Fri, Apr 17, 2020 at 3:59 PM David Mertz wrote:
&
I'm kinda leaning -0.5 even on the form that I think is least bad (the mode
switch approach).
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",
...
On Fri, Apr 17, 2020 at 2:22 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> What examples can you think of—in English, Python, other popular
> languages, math notation, whatever—where there’s an infix-operator-like
> thing and the right token is elided and inferred implicit
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, username=user["display_name"],
> channel, channelid, error,
Hmmm... I disagree with Chris.
I'm definitely -1 on a magic dangling 'foo=' after variable names. And
something less than -1 on the even more magic "Lisp symbol that isn't a
symbol" ':foo'.
Those are just ugly and mysterious.
However, I don't HATE the "mode switch" use of '*' or '**' in function
It sounds like you've entirely missed the point of Python exceptions. You
are right that they are a kind of dynamic scope. That's their entire reason
for existing, not a bug.
In Python, we can handle an exception at the particular scope in which it
is most appropriate and useful to handle it, and
- Backwards compatible all the way back to Python 1.5.
What!? It's not so recent as that:
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> stuff = [1, 2, 3]
>>> for element in stuff:
... if element > 2:
... print element
...
3
--
Keeping m
I have often wanted this! I use defaultdict only occasionally, and every
time I do, I start out thinking it behaves the way you describe
dynamicdict. Then I read the docs again and decide I didn't actually want
defaultdict to start with, and roll something different.
On Fri, Apr 10, 2020, 6:50 PM
On Fri, Apr 10, 2020 at 4:27 PM Elliott Dehnbostel
wrote:
> *Consider the following trivial for-loop:*
>
> chars = "abcaaabkjzhbjacvb"
> seek = {'a','b','c'}
> count = 0for a in chars:
> if a in seek:
> count += 1
>
>
I would definitely not write it that way. Instead I would write
It's weird, counterintuitive, unclear syntax to do something already
handled much better by simply subclassing exceptions. I reckon that's why
push-back.
On Fri, Apr 10, 2020, 8:59 AM Soni L. wrote:
>
>
> On 2020-04-10 9:40 a.m., Rhodri James wrote:
> > On 10/04/2020 12:43, Soni L. wrote:
> >> i
o. Maybe an ORDER BY. Etc. But if I'm sure
there won't be more than 6 such clauses to the query I'm building, so what?
Or probably likewise with bits of a file path, or a URL with optional
parameters, and a few other things.
On Mon, Mar 30, 2020 at 11:15 PM David Mertz wrote:
Does anyone know if any linters find and warn about the `string += word` in
a loop pattern? It feels like a linter would be the place to do that. I
don't think we could possibly make it an actual interpreter warning given
borderline OK uses (or possibly even preferred ones). But a little nagging
On Mon, Mar 16, 2020, 5:57 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> s/people/mathematicians/ and I'd agree with you. But I did write "people".
>
Are mathematicians not people? :-)
If they are, them "some mathematicians" implies "some people."
__
> Most real-world UNIX systems only support ASCII-compatible encodings.
> There's no reason not to solve the problem on such systems by using
> os.fsdecode().
>
Huh?!
Is my Ubuntu derivative not "real world"?
666-tmp % uname -a
Linux popkdm 5.3.0-7629-generic #31~1581628825~19.10~f90b7d5-Ubuntu
This isn't a terrible use of the walrus operator either.
if blue_20 := (color==BLUE and count==20) or red_5 := (color==RED and
count%5==0)
rotate_the_wheel() # Common to the two sub-conditions
if blue_20: # First sub-condition
set_signal()
if red_5: # Second sub-condition
On Wed, Mar 4, 2020 at 11:23 AM Mark Dickinson wrote:
> So Decimal is totally orderable to exactly the same extent that float is.
> (Though the behaviour with NaNs is a little more extreme, since comparisons
> involving sNaNs will raise rather than return False.) I'd argue that on a
> practicali
On Wed, Mar 4, 2020 at 10:22 AM Richard Damon
wrote:
> > But on one narrow point, I'm trying to think of everything in the
> standard library or builtins that actually forms a total order with
> elements of the same type.
> > * Not floats
> > * I think not strings with unicode canonical equivalen
This thread feels very much like a solution looking for a problem.
But on one narrow point, I'm trying to think of everything in the standard
library or builtins that actually forms a total order with elements of the
same type.
* Not floats
* I think not strings with unicode canonical equivalence
On Tue, Mar 3, 2020 at 5:35 PM Guido van Rossum wrote:
> But beware, IIRC there are pathological cases involving floats, (long)
> ints and rounding where transitivity may be violated in Python (though I
> believe only Tim Peters can produce an example :-). I'm honestly not sure
> that that's enou
(Un)Happily we have the keyword "as" already. They can make their own
aliases.
On Tue, Feb 25, 2020, 11:46 PM Steven D'Aprano wrote:
> On Tue, Feb 25, 2020 at 10:08:57PM -0500, David Mertz wrote:
>
> > >>> from statistics import stdev as σ
> > >&g
>
> For example, the function for calculating standard deviation is written
>
`statistics.stdev` not `σ`.
>
What do you mean?
>>> from statistics import stdev as σ
>>> σ([5, 6, 4, 6, 3, 7])
1.4719601443879744
:-)
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of
I can imagine the hypothetical binary tilde being pretty for some kind of
equivalence. This is definitely not enough to motivate me to actually want
to add it. But I think this would read OK as equivalent:
numpy.allclose(arr1, arr2)
arr1 ~ arr2
However, the problem is that there are lot
On Mon, Feb 24, 2020 at 4:08 PM Alex Hall wrote:
> Even when there is a wealth of code out there that will become broken
>> by this change?
>
>
> Not broken, just noisy.
>
Noisy *IS* broken!
In some ways it's one of the worst kinds of broken. Working with libraries
that import other libraries
I may have led in that direction, and I know R only passingly, not well.
But my understanding is that thinking of a data structure that gets parsed
by an evaluator, e.g. "do a linear regression with this structure (and a
DataFrame)" is better than a lambda.
I'm sure it's possible to describe this
Well... also, the meaning in R is quite a bit different from any of the
meanings suggested by Wolfram. In fact, although the most common use in R
is "depends on", it's technically just a generic delayed evaluation without
any inherent semantics at all. Or, that is to say, tilde is just a certain
On Mon, Feb 24, 2020, 9:27 AM Rhodri James wrote:
> On 23/02/2020 18:33, Steve Jorgensen wrote:
> > In many ways, a string is more useful to treat as a scalar than a
> collection, so drilling down into collections and ending up iterating
> individual characters as the leaves is often 1 step too f
In mathematics, in my recollection, the tilde is used for
1. Unary approximate number
2. Binary equivalence
3. Binary congruence/isomorphism
The last is more formally an equal sign with tilde on top: ≅. I think maybe
just simplified for chalk boards where context makes it clear. Those are
all aki
Aside from all the other problems, 'sim' (~) in LaTeX and mathematics means
something completely different than 'depends on' (~) in R. Trying to
overload those meaning makes everything harder.
I would recommend doing what NumPy did for many years for matrix multiply.
Use an existing operator. Yes
I have fairly frequently written some kind of recursive descent into
collections. Like many people, I've had to special case strings, which are
pseudo-scalar, and I don't want to descend into.
But one thing I don't think I've ever tripped over is descending into
single characters, but then wanting
Comprehension are very much based on the idea of *declarative* data
collections. That's their entire reason for being. In general, one expects
comprehension to be side-effect free and just build a collection according
to declared rules. Obviously I know many ways to smuggle in side effects,
but doi
-100. The weird block structures inside comprehension reads terribly even
in the trivial case shown, and looks worse the more structures are inside
it. We have functions. They are great. Let's use those.
On Sat, Feb 22, 2020, 2:01 AM Alex Hall wrote:
> > You might be able to avoid calling the me
OMG, please no! Please, for all that is decent, do not use an ORM in any
code I will ever need to look at!
The SQL injection attack is just silly if you don't run arbitrary strings.
Don't ever do that. But running a query that is hard coded as text, with
just a few parameters filled in (the DB-AP
On Fri, Feb 21, 2020 at 9:26 PM Steven D'Aprano wrote:
> > And what's so special about SQL over, say, regular expressions, XML,
> > JSON, YAML, Markdown, ReST, LaTeX, etc? I might want to use the s''
> > prefix for embedded Scheme code rather than SQL.
>
> Um, regular expressions are not precisel
This idea by jdveiga seems like a good one. It doesn't require any change
in Python, although conceivably an informational PEP could make some
specific convention a recommendation.
The thing is, SQL isn't THAT special. I use SQL a lot myself, so would
benefit from such support. But there are LO
This last is for discussion of changes to the Python language itself, in
particular the CPython reference implementation. Python-list or a Pandas
forum are appropriate for this question.
That said, it sounds like you want df.value_counts(). But if not, follow-up
in a more relevant place.
On Thu,
The OP's posts all seem to consist of:
1. This other thing is way better
2. I won't explain what it is, but Rust does it better
3. The other folks who have used Rust don't understand it either
4. You are all too dumb to understand this great thing
5. Python should change it's syntax to allow this
This looks like a very nice library to put on PyPI. But it's not an idea
for change to the Python language itself, so probably this is the wrong
forum. Python-list is closer.
... if it is a suggestion to change the standard library itself, I'm -1 on
the idea.
On Sat, Feb 8, 2020 at 6:11 PM Sean
Even apart from the long time delay, it seems clear that the Django
developers rejected 'raise from' for design reasons. That might be right or
wrong as a decision, but it's a separate project from Python itself.
Nothing in the issue even hints that they would have accepted it *if only*
the spelli
On Tue, Jan 21, 2020 at 12:15 PM Christopher Barker
wrote:
> You *may* be able to do something directly with strings, but most likely
> you'll pass it off to something else: a template renderer, JSON parser,
> what have you. And I can’t think of a single instance where you would just
> want the b
I should really upgrade to 1.02!
% python
Python 1.0.1 (Jul 15 2016)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
>>> def f():
... for i in range(5): i
...
>>> f()
0
1
2
3
4
On Sun, Jan 19, 2020 at 4:33 PM Tim Peters wrote:
> [Guido]
> > Sounds like a hallucination or fabri
On Sun, Jan 19, 2020 at 3:56 PM Steven D'Aprano wrote:
> > The "fluent interface" (https://en.wikipedia.org/wiki/Fluent_interface)
> is
> > popular in many programming languages, including in the sort of
> > "mini-language" Pandas, within portion.
>
> I can't speak about Pandas, but what the OP i
On Sun, Jan 19, 2020 at 2:57 PM Tim Peters wrote:
> [David Mertz ]
> > What we get instead is a clear divide between mutating methods
> > on collections that (almost) always return None, and functions
> > like sorted() and reversed() that return copies of the underlying
&g
The "fluent interface" (https://en.wikipedia.org/wiki/Fluent_interface) is
popular in many programming languages, including in the sort of
"mini-language" Pandas, within portion.
But it is definitely not Pythonic. The Wikipedia article even shows how you
*could* do it in Python, but mentions that
For what it's worth, after 20+ years of using Python, forgetting the colon
for blocks remains the most common error I make by a fairly wide margin.
Of course, once I see the error message—even being not all that descriptive
of the real issue—I immediately know what to fix too.
On Tue, Jan 14, 2020
"oh gawd please NO!"
On Tue, Jan 7, 2020, 9:40 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Juancarlo Añez writes:
>
> > Could we switch the email discussions to Discourse email? Has this been
> > considered earlier and rejected?
>
> Yes, of course we can. It has been
There have been a number of comments in this thread, and some slight
variations in the idea.
I'm afraid that it all looks awkward to me, so far. I understand trying to
work out the smallest change that would allow the style, but it just feels
"bolted on" in a bad way.
I believe that if Python get
>
>
> class MatchType(type):
> def __eq__(self, other):
> return self == type(other)
>
> Or I even want to match:
>
> type[int], y < 42, z = vec
>
> Well, I can’t think of a language where you can actually match that way.
> That doesn’t necessarily mean we should disallo
On Tue, Dec 31, 2019 at 8:23 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> > K = 42
> > x, K, z = vec
> Yes. I’m surveying the way other languages deal with this to try to figure
> out what might fit best for Python.
> Some languages use special syntax to mark either value
> if foo OR bar OR baz in foobar:
> pass
>
Someone else noted, and I agreed, that set intersection is already the
obvious way to do this. But yes, some things aren't hashable. So in concept
you could make a custom type that had some set-like behaviors, and so on.
But all of this is crazy work
I completely agree. All the variations suggested are unreadable mish-mash.
Set intersection exists already and it's completely clear.
On Tue, Dec 31, 2019, 12:05 PM Jonathan Crall wrote:
> For what its worth, I find the proposed syntax confusing and difficult to
> read. Conceptually it makes sen
> The order he generates is very close to the IEEE total order, the
difference are:
> > 1) It doesn't seperate -0 for +0, which shouldn't matter for most
> applications.
> > 2) It doesn't provide an order between NaNs, but unless you are taking
> special measures to distinguish the NaNs anyway, th
On Mon, Dec 30, 2019, 5:17 PM Andrew Barnert
> The fact that all three of the alternate orders anyone’s asked for or
> suggested turned out to be spurious, and nobody can think of a good use for
> a different one, that’s a pretty good argument that YAGNI.
>
I think everyone agrees that the only a
On Mon, Dec 30, 2019 at 12:37 PM Richard Damon
wrote:
> My preference is that the interpretation that NaN means Missing Data
> isn't appropriate for for the statistics module.
You need to tel the entire PyData ecosystem, the entire R ecosystem, and a
pretty much all of Data Science that they ar
On Mon, Dec 30, 2019 at 3:32 AM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Dec 29, 2019, at 23:50, Steven D'Aprano wrote:
> >
> > On Sun, Dec 29, 2019 at 06:23:03PM -0800, Andrew Barnert via
> Python-ideas wrote:
> >
> >> Likewise, it’s even easier to write ignore-nan
On Mon, Dec 30, 2019 at 2:58 AM Steven D'Aprano wrote:
> Can you explain the scenario where somebody using median will want
> negative NANs to sort to the beginning, below -INF, and positive NANs to
> sort to the end, above +INF?
>
I can kinda-sorta provide a case. But overall, despite my whims
What is it, 2**48-2 signaling NaNs and 2**48 quiet NaNs? Is my quick count
correct (in 64-bit)? Great opportunity for steganography, I reckon.
On Sun, Dec 29, 2019 at 11:51 PM Tim Peters wrote:
> [David]
> > Has anyone actually ever used those available bits for the zillions of
> NaNs for
> > a
On Sun, Dec 29, 2019 at 11:33 PM Andrew Barnert wrote:
> IEEE total order specifies a distinct order for every distinct bit
> pattern, and tries to do so in a way that makes sense.
>
Ok, ok... I've got "learned up" about this three times now :-). Given we
cannot control those bit patterns from
501 - 600 of 1177 matches
Mail list logo
