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
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
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
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
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
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 -
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
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)`
>
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
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
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
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
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
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
>
> 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:
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
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
>
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
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
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
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
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
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
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
> 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
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
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
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
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)
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
