Stéfane Fermigier wrote:
> On Wed, Mar 4, 2020 at 8:24 AM Steve Jorgensen [email protected] wrote:
> > Chris Angelico wrote:
> > On Wed, Mar 4, 2020 at 6:04 PM Steve Jorgensen
> > [email protected] wrote:
> >
> > https://en.wikipedia.org/wiki/Partially_ordered_set
> > "Partially ordered" means
On Mar 3, 2020, at 23:11, Steven D'Aprano wrote:
>
> But for stability reasons (what if the error messages are localised, or
> change in the future?), we could give the exception a "reason"
> attribute, with a documented stable ID, and make that the official way
> to programmatically distingui
>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered — not even having a full complement of rich comparison oper
On Mar 4, 2020, at 00:07, Steve Jorgensen wrote:
>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered — not
On Wed, Mar 4, 2020 at 9:22 AM Andrew Barnert via Python-ideas <
[email protected]> wrote:
> Is there any commonly used or even imaginable useful type that uses them
> in weirder ways than set and float (which are both partially ordered) [...]
Nitpick: why do you say "partially ordered" fo
Hi
The present behaviour is:
>>> len()
TypeError: len() takes exactly one argument (0 given)
>>> len(1, 2)
TypeError: len() takes exactly one argument (2 given)
This is nothing special about built-ins. The same goes for:
>>> def f(): pass
>>> f(1)
TypeError: f() takes
Can you explain where `except ParameterError` would produce better code
than the best current alternative? It seems to me that using this is like
stating "this code might be wrong" and would generally produce bad code.
For example if I wanted to use math.gcd on multiple values but I need to
support
Postscript: Things are not as clean as I have hoped and said. However, I
don't think this changes the general form of the conclusion. Just that a
little more work is needed to achieve the goal.
Python 3.7 and 3.8:
>>> def f(x): pass
>>> f()
TypeError: f() missing 1 required positional
>
> Is there any commonly used or even imaginable useful type that uses them
> in weirder ways than set and float (which are both partially ordered) or
> np.array (where they aren’t even Boolean-values)? In particular,
> transitivity keeps coming up, but all of those examples are transitive
> (it’s
On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote:
> I liked everything up to using magic numbers like this.
I'm not wedded to the idea of error number. I chose them because I
expect there will only be a few of them (three?) and the majority
of the time you won't bother to check th
Steven D'Aprano wrote:
Another alternative is to testing for key phrases in the exception
> message:
>
> if "too few arguments" in err.args[0]: ...
>
> but that's fragile and only works until the message gets changed to say
> "not enough arguments". (The error message is not part of the API, s
On Wed, Mar 4, 2020 at 9:58 PM Steven D'Aprano wrote:
>
> The important thing is to be able to programmatically
> distinguish the case where arguments don't match the parameters from the
> case where an argument is the wrong type.
>
Or where you're trying to call something that isn't callable. Th
04.03.20 09:06, Steven D'Aprano пише:
Proposal: add a new exception, ParameterError, for parameter errors. For
backwards compatibility it would have to be a subclass of TypeError.
If add such exception, ArgumentError looks more appropriate name.
Where the interpreter now raises TypeError for
On Wed, Mar 04, 2020 at 10:12:34AM +, Jonathan Fine wrote:
> I find this behaviour perfectly satisfactory. The OP's problem can be
> resolved by looking at the exception, whose type is TypeError.
>
> For this to be completely reliable, certain aspects the exception message
> need to be stable
On Wed, Mar 04, 2020 at 11:10:15AM +, Jonathan Fine wrote:
> We are talking here about an exception message that is generated by core
> Python. So there would be some warning of change, namely the review process
> for core Python.
You can't call the error message a stable part of the language
On Wed, Mar 04, 2020 at 02:09:00PM +0200, Serhiy Storchaka wrote:
> If add such exception, ArgumentError looks more appropriate name.
Thanks Serhiy, I considered that but thought that ArgumentError was
likely to be used in third-party libraries.
A quick google shows that argparse and Boost both
On Wed, Mar 04, 2020 at 12:19:25PM +0200, Alex Hall wrote:
> Can you explain where `except ParameterError` would produce better code
> than the best current alternative?
Serhiy came up with a good use-case that I hadn't considered: functions
which take arbitrary callback functions as argument, e.
On Wed, Mar 4, 2020 at 2:58 AM Steven D'Aprano wrote:
> I don't know enough about the Python internals to give a definitive
> answer, but I'm assuming/hoping that there is a single, or at most a
> few, places in the interpreter that matches up arguments to formal
> parameters, and if there's a di
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
> Both of these calls raise TypeError, but for different reasons:
> # right number of arguments passed to the key function,
> # but the wrong argument type
> sorted([3, 5, 1], key=len)
>
> # wrong number of arguments passed to the key function
> sorted([3, 5, 1], key=isinstance)
>
> It might be
> On Mar 4, 2020, at 10:09 AM, David Mertz wrote:
>
>
> 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.
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
On Wed, Mar 4, 2020 at 4:08 PM David Mertz wrote:
>
> And I'm also fudging the Decimal question too. The relationship between
> *expressions* can vary by decimal context. But not of a value named by a
> single variable.
>
Right: Decimal objects don't know anything about context, and comparison
On Wed, Mar 04, 2020 at 04:21:46PM +, Mark Dickinson wrote:
> I'd argue that on a practicality-beats-purity basis, it wouldn't be
> unreasonable to register both `Decimal` and `float` as implementing
> `TotalOrdering` (or whatever the ABC ends up being called).
And that seems perfectly practi
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
Andrew Barnert wrote:
> On Mar 4, 2020, at 00:07, Steve Jorgensen [email protected] wrote:
> > Taking one step back out of the realm of mathematical
> > definition, however, the original idea was simply to distinguish what I now
> > understand to
> > be "totally ordered" types from other types, b
On Mar 4, 2020, at 03:00, Steven D'Aprano wrote:
>
> On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote:
>
>> I liked everything up to using magic numbers like this.
>
> I'm not wedded to the idea of error number. I chose them because I
> expect there will only be a few of them (t
On Mar 4, 2020, at 01:56, Mark Dickinson wrote:
>
>> On Wed, Mar 4, 2020 at 9:22 AM Andrew Barnert via Python-ideas
>> wrote:
>
>> Is there any commonly used or even imaginable useful type that uses them in
>> weirder ways than set and float (which are both partially ordered) [...]
>
> Nitpi
On 03Apr2019 14:54, Steven D'Aprano wrote:
Now imagine it's five years from now, and you're using Python 3.11, and
you came across code somebody (possibly even you!) wrote:
ifname = ifname.cutsuffix(':')
Would you say "Damn, I wish that method had never been added!" and
replace it with the
Steven D'Aprano writes:
> Proposal: add a new exception, ParameterError, for parameter
> errors. For backwards compatibility it would have to be a subclass
> of TypeError.
To me, that name evokes all kinds of things that linters and mypy do,
but the Python interpreter can't or shouldn't.
Func
Andrew Barnert via Python-ideas writes:
> Is there any commonly used or even imaginable useful type that uses
> them in weirder ways than set and float (which are both partially
> ordered) or np.array (where they aren’t even Boolean-values)?
I've had occasion (a class for outcomes in two-playe
Thanks. I was wondering what happened to that idea.
I’d like to see it revived, it seems a perfectly reasonable addition to the
string object to me.
And now you’ve written a prototype, there’s a straightforward proposal.
-CHB
On Wed, Mar 4, 2020 at 4:54 PM Cameron Simpson wrote:
> On 03Apr201
On 3/4/20 11:43 AM, Steven D'Aprano wrote:
On Wed, Mar 04, 2020 at 04:21:46PM +, Mark Dickinson wrote:
I'd argue that on a practicality-beats-purity basis, it wouldn't be
unreasonable to register both `Decimal` and `float` as implementing
`TotalOrdering` (or whatever the ABC ends up being c
>
>
> > Is there any commonly used or even imaginable useful type that uses
> > them in weirder ways than set and float
I don’t think this is relevant— Python is very dynamic, operator
overloading is a way to make your custom classes work
With the operators. There is no guarantee at all that a
On Mar 30, 2019, at 12:30, MRAB wrote:
>
> I'd much prefer .lcut/.rcut to .cut_prefix/.cut_suffix, to match
> .lstrip/.rstrip.
I agree that we should use either l/r or something to do with start/end. We
already have two different ways to say left/start and right/end on the str
methods; addin
On Mar 4, 2020, at 19:12, Richard Damon wrote:
>
> Yes, because of the NaN issue, you sort of need an 'Almost Total Order' and
> 'Really Truly a Total Order', the first allowing the small exception of a
> very limited (maybe only one) special value that breaks the true definition
> of Total Or
Sorry, I thought I was replying to something from today, not a year ago. My
mail client decided that all old messages I didn’t read at the time were
suddenly brand new additions to the thread, and I didn’t look at the dates. :)
Sent from my iPhone
> On Mar 4, 2020, at 19:21, Andrew Barnert via
On 5/03/20 4:08 pm, Richard Damon wrote:
Sometimes I wonder if
since Python supports dynamic typing of results, might not do better by
removing the NaN value from Floats and Decimals, and make the operations
that generate the NaN generate an object of a special NaN type.
I don't see what prob
38 matches
Mail list logo
