It was written:
> How is `int(string, 16)` "inverting"?
It's the inverse of f"{number:x}", of course. Mappings between types
are ubiquitous, and (more or less) invertible ones are not uncommon.
It's an honest question, but I suggest we let slightly odd usage,
especially in scare quotes, pass.
On Wed, Oct 13, 2021 at 12:05:35AM -, MarylandBall Productions wrote:
> I would think `~string` could be good for a shorthand way to convert a
> string to an integer, considering you’re “inverting” the string to
> another type
How is `int(string, 16)` "inverting"?
Inverting means to flip o
On Tue, Oct 12, 2021 at 11:50:27PM -, Jeremiah Vivian wrote:
> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these implementations:
Did you actuall
On Tue, Oct 12, 2021 at 5:21 PM Jeremiah Vivian <
nohackingofkrow...@gmail.com> wrote:
> So I guess I'll just have to keep this to myself.
>
I know this is disappointing, but in this case I agree with Jelle -- this
particular idea does not fit well in Python's design, it looks like an
attempt at
> "inverting" the string to another type
...That doesn't make any sense.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
On Wed, Oct 13, 2021 at 11:21 AM MarylandBall Productions
wrote:
>
> I would think `~string` could be good for a shorthand way to convert a string
> to an integer, considering you’re “inverting” the string to another type,
> though a downside to this would be that explicit is always better than
So I guess I'll just have to keep this to myself.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
h
I would think `~string` could be good for a shorthand way to convert a string
to an integer, considering you’re “inverting” the string to another type,
though a downside to this would be that explicit is always better than implicit
and ~string will be a confusing operation to many users.
___
El mar, 12 oct 2021 a las 16:51, Jeremiah Vivian (<
nohackingofkrow...@gmail.com>) escribió:
> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these impleme
On Wed, Oct 13, 2021 at 10:53 AM Jeremiah Vivian
wrote:
>
> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these implementations:
> > +string - `int(stri
On Wed, Oct 13, 2021 at 10:02 AM Steven D'Aprano wrote:
>
> On Wed, Oct 13, 2021 at 09:22:09AM +1100, Chris Angelico wrote:
>
> > Mathematicians and programmers both extend
> > operators to new meanings, but only where it makes sense.
>
> In fairness, mathematicians typically just invent new symbo
I posted a previous thread about overloading the unary `+` operator in strings
with `ord`, and that expanded to more than just the unary `+` operator. So I'm
saying now, there should be these implementations:
> +string - `int(string, 10)` (or just `int(string)`)
> -string - `int(string, 8)`
> ~st
On 2021-10-12 23:57, Steven D'Aprano wrote:
On Wed, Oct 13, 2021 at 09:22:09AM +1100, Chris Angelico wrote:
Mathematicians and programmers both extend
operators to new meanings, but only where it makes sense.
In fairness, mathematicians typically just invent new symbols, when
they're not repu
So I'll post another thread about unary operators for strings. Everything
expanded from just unary positive to all unary operators.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
htt
On Wed, Oct 13, 2021 at 09:22:09AM +1100, Chris Angelico wrote:
> Mathematicians and programmers both extend
> operators to new meanings, but only where it makes sense.
In fairness, mathematicians typically just invent new symbols, when
they're not repurposing existing symbols for totally unrela
On Wed, Oct 13, 2021 at 9:15 AM Jeremiah Vivian
wrote:
>
> Using the caret as a prefix unary operator would require changes in python
> grammar. For now, stick to implementing existing operators. But the rest of
> the ideas are good though.
>
You may need to get your sensors tuned up, as not on
Using the caret as a prefix unary operator would require changes in python
grammar. For now, stick to implementing existing operators. But the rest of the
ideas are good though.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe sen
You all have been giving pretty great ideas. But this is the one I'm
considering the most:
On 2021-10-12 13:49, Steven D'Aprano wrote:
> On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
>> You haven't given any reason why unary plus should imply ord().
> I think the question Chris i
>
> If one DID write a first() function, it maybe or maybe not should raise a
> different exception, but it should certainly provide a better error message
For reference, the more-itertools package on PyPI has `first()` and
`last()` functions:
https://more-itertools.readthedocs.io/en/stable/_modu
On Mon, Oct 11, 2021 at 8:08 PM Steven D'Aprano wrote:
> I assume you're not just extracting the first value for the LOLs, you
> must have some reason for it. It is *that reason* which counts as a
> use-case.
>
I dug through our application code base (500k lines) and found just one use
case of t
On Wed, Oct 13, 2021 at 2:39 AM Christopher Barker wrote:
>
> On Tue, Oct 12, 2021 at 4:51 AM Chris Angelico wrote:
>>
>> > Exactly: simple usage of next is often a bug. We need to be careful about
>> > this every time someone suggests that it's straight-forward to do
>> > next(iter(obj)).
>
>
On Tue, Oct 12, 2021 at 4:51 AM Chris Angelico wrote:
> > Exactly: simple usage of next is often a bug. We need to be careful
> about this every time someone suggests that it's straight-forward to do
> next(iter(obj)).
>
> Please give a real example of where calling first() and getting
> ValueE
On Tue, Oct 12, 2021 at 9:40 AM MRAB wrote:
> On 2021-10-12 13:49, Steven D'Aprano wrote:
> > On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
> >
> >> You haven't given any reason why unary plus should imply ord().
> >
> > I think the question Chris is really asking is why should
On 2021-10-12 13:49, Steven D'Aprano wrote:
On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
You haven't given any reason why unary plus should imply ord().
I think the question Chris is really asking is why should unary plus
return ord() rather than any other function or metho
On 2021-10-12 13:36, Chris Angelico wrote:
On Tue, Oct 12, 2021 at 11:27 PM Jeremiah Vivian
wrote:
> -1. It's unnecessary optimization for an uncommon case, abuse of syntax
Good point. But what else can the unary positive do? I'm just trying to add a
use for it.
> illogical - why should +"a"
On Tue, Oct 12, 2021 at 11:47 PM Steven D'Aprano wrote:
>
> Shouldn't your safe_map raise RuntimeError rather than ValueError?
> That's what PEP 479 does *wink*
>
> https://www.python.org/dev/peps/pep-0479/
>
If I'm explicitly choosing the exception to raise, ValueError seems
better, although I'd
On 2021-10-12 13:25, Jeremiah Vivian wrote:
-1. It's unnecessary optimization for an uncommon case, abuse of syntax
Good point. But what else can the unary positive do? I'm just trying to add a
use for it.
illogical - why should +"a" be the integer 97?
Because `ord("a")` is `97`. Have you rea
On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
> You haven't given any reason why unary plus should imply ord().
I think the question Chris is really asking is why should unary plus
return ord() rather than any other function or method.
We could make unary plus of a string equa
Shouldn't your safe_map raise RuntimeError rather than ValueError?
That's what PEP 479 does *wink*
https://www.python.org/dev/peps/pep-0479/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@pyt
On Tue, Oct 12, 2021 at 11:27 PM Jeremiah Vivian
wrote:
>
> > -1. It's unnecessary optimization for an uncommon case, abuse of syntax
> Good point. But what else can the unary positive do? I'm just trying to add a
> use for it.
> > illogical - why should +"a" be the integer 97?
> Because `ord("a"
the unary `+` for a string doesn't really exist.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
ht
> And also, the unary `+` of
> strings only copies strings, which should be redundant in most cases.
Oh yeah. I got this from the behavour of the unary `+` of an `int`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email
On Tue, Oct 12, 2021 at 06:34:06AM -, Jeremiah Vivian wrote:
> So `ord` is already a really fast function with (last check before
> this thread was posted) 166 nsec per loop. But I'm wondering... doing
> `ord(a)` produces this bytecode:
>
> > 2 4 LOAD_NAME1 (ord)
>
> -1. It's unnecessary optimization for an uncommon case, abuse of syntax
Good point. But what else can the unary positive do? I'm just trying to add a
use for it.
> illogical - why should +"a" be the integer 97?
Because `ord("a")` is `97`. Have you read the last question at the end of the
post?
On Tue, Oct 12, 2021 at 10:41 PM Jeremiah Vivian
wrote:
>
> So `ord` is already a really fast function with (last check before this
> thread was posted) 166 nsec per loop. But I'm wondering... doing `ord(a)`
> produces this bytecode:
> > 2 4 LOAD_NAME1 (ord)
> >
On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
wrote:
>
>
> On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
>>
>> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
>> wrote:
>> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
>> > attempted to solve this by turning S
So `ord` is already a really fast function with (last check before this thread
was posted) 166 nsec per loop. But I'm wondering... doing `ord(a)` produces
this bytecode:
> 2 4 LOAD_NAME1 (ord)
> 6 LOAD_NAME0 (a)
> 8 CALL_FUNCTIO
On Tue, 12 Oct 2021 at 11:48, Chris Angelico wrote:
> On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
> wrote:
> > A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it
> gets caught in a generator but t
On Tue, Oct 12, 2021 at 8:43 PM Oscar Benjamin
wrote:
> A leaky StopIteration can wreak all sorts of havoc. There was a PEP that
> attempted to solve this by turning StopIteration into RuntimeError if it gets
> caught in a generator but that PEP (which was rushed through very quickly
> IIRC) mi
On Sun, 10 Oct 2021 at 04:56, Steven D'Aprano wrote:
> On Fri, Oct 08, 2021 at 01:42:35PM -0700, Christopher Barker wrote:
>
> > Anyway, I do see the benefit of adding first() to itertools -- there
> really
> > is a key problem with:
> >
> > next(iter(an_iterable))
> >
> > for newbies -- you can
40 matches
Mail list logo
