Re: Is there a way to implement the ** operator on a custom object

On 09Feb2024 18:56, Left Right wrote: But, more to the point: extending collections.abc.Mapping may or may not be possible in OP's case. We don't yet know if that's what the OP had in mind yet, anyway. Also, if you are doing this through inheritance, this seems really convoluted: why not

Re: Is there a way to implement the ** operator on a custom object

> Looks like it can simply be done in Python, no tp_as_mapping needed. It's not that it isn't needed. You've just shown a way to add it using Python code. But, more to the point: extending collections.abc.Mapping may or may not be possible in OP's case. Also, if you are doing this through

Re: Is there a way to implement the ** operator on a custom object

Left Right via Python-list schreef op 9/02/2024 om 17:09: In order for the "splat" operator to work, the type of the object must populate slot `tp_as_mapping` with a struct of this type: https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and have some non-null imple

Re: Is there a way to implement the ** operator on a custom object

In order for the "splat" operator to work, the type of the object must populate slot `tp_as_mapping` with a struct of this type: https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and have some non-null implementations of the methods this struct is supposed to contain.

Re: Is there a way to implement the ** operator on a custom object

Chris Angelico writes: > On 08Feb2024 12:21, tony.fl...@btinternet.com wrote: > >I know that mappings by default support the ** operator, to unpack the > >mapping into key word arguments. > > > >Has it been considered implementing a dunder method for t

Re: Is there a way to implement the ** operator on a custom object

On Fri, 9 Feb 2024 at 17:03, Cameron Simpson via Python-list wrote: > > On 08Feb2024 12:21, tony.fl...@btinternet.com > wrote: > >I know that mappings by default support the ** operator, to unpack the > >mapping into key word arguments. > > > >Has it been consid

Re: Is there a way to implement the ** operator on a custom object

On 08Feb2024 12:21, tony.fl...@btinternet.com wrote: I know that mappings by default support the ** operator, to unpack the mapping into key word arguments. Has it been considered implementing a dunder method for the ** operator so you could unpack an object into a key word argument

Is there a way to implement the ** operator on a custom object

I know that mappings by default support the ** operator, to unpack the mapping into key word arguments. Has it been considered implementing a dunder method for the ** operator so you could unpack an object into a key word argument, and the developer could choose which keywords would

RE: extend behaviour of assignment operator

change the language so it pays attention to what it is giving a pointer too and then goes and tells ... -Original Message- From: Python-list On Behalf Of Guenther Sohler via Python-list Sent: Tuesday, January 9, 2024 2:15 AM To: python-list@python.org Subject: extend behaviour of assign

Re: extend behaviour of assignment operator

Guenther Sohler wrote at 2024-1-9 08:14 +0100: >when i run this code > >a = cube([10,1,1]) >b = a > >i'd like to extend the behaviour of the assignment operator >a shall not only contain the cube, but the cube shall also know which >variable name it >was assigned

extend behaviour of assignment operator

Hi, when i run this code a = cube([10,1,1]) b = a i'd like to extend the behaviour of the assignment operator a shall not only contain the cube, but the cube shall also know which variable name it was assigned to, lately. I'd like to use that for improved user interaction. effective code

Re: xor operator

In case someone is actually going to execute the code, there is a bug: `set` need to be wrapped in `len` for criteria args. > On 15 Nov 2023, at 20:13, Dom Grigonis wrote: > > > The specific situation was related to truth values and following out of that > my considerations regarding

Re: xor operator

The specific situation was related to truth values and following out of that my considerations regarding equivalent of all and any for counting `truths`. So one of the specific examples: class Publisher: def __init__(self): self.subscribers = dict() def subscribe(self, sub,

Re: xor operator

On 2023-11-15 12:26:32 +0200, Dom Grigonis wrote: > > Thank you, > > > test2 = [True] * 100 + [False] * 2 > test2i = list(range(100)) > > %timeit len(set(test2i)) == 1 # 1.6 µs ± 63.6 ns per loop (mean ± std. dev. > of 7 runs, 1,000,000 loops each) > %timeit all(test2) # 386 ns

Re: xor operator

Thank you, test2 = [True] * 100 + [False] * 2 test2i = list(range(100)) %timeit len(set(test2i)) == 1 # 1.6 µs ± 63.6 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each) %timeit all(test2) # 386 ns ± 9.58 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Re: xor operator

On 2023-11-14 00:11:30 +0200, Dom Grigonis via Python-list wrote: > Benchmarks: > test1 = [False] * 100 + [True] * 2 > test2 = [True] * 100 + [False] * 2 > > TIMER.repeat([ > lambda: xor(test1), # 0.0168 > lambda: xor(test2), # 0.0172 > lambda: xor_ss(test1), # 0.1392 >

Re: xor operator (DEPRECATED)

r the >> non-standard evaluation in R where you can arrange for lots of your data to >> not be interpreted till absolutely needed. >> -Original Message- >> From: Dom Grigonis >> Sent: Monday, November 13, 2023 10:12 PM >> To: avi.e.gr...@gmail.com >>

Re: xor operator (DEPRECATED)

n R where you can arrange for lots of your data to not be interpreted till absolutely needed. -Original Message- From: Dom Grigonis Sent: Monday, November 13, 2023 10:12 PM To: avi.e.gr...@gmail.com Cc: Grant Edwards ; Python Subject: Re: xor operator (DEPRECATED) Fair point. Ho

RE: xor operator (DEPRECATED)

ubject: Re: xor operator (DEPRECATED) Fair point. However, I gave it a shot for the following reason: I couldn’t find a way to make such performant function. Using python builtin components still ends up several times slower than builtin `all`. Cython or numba or similar is not an option

Re: xor operator (DEPRECATED)

e up with an amazing number of ideas including for > "useful" functions or features but I find the vast majority would rarely be > used as nobody remembers it is available and some fairly simple method using > other functions can easily be cobbled together. > > -Original Message

RE: xor operator

other functions can easily be cobbled together. -Original Message- From: Python-list On Behalf Of Grant Edwards via Python-list Sent: Monday, November 13, 2023 8:19 PM To: python-list@python.org Subject: Re: xor operator On 2023-11-14, Dom Grigonis via Python-list wrote: > >> Exc

Re: xor operator

On 2023-11-14, Dom Grigonis via Python-list wrote: > >> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise >> or and and applided to many bits. To do something "in line" with that >> using the 'xor' operator would return True for an odd num

Re: xor operator

On Tue, 14 Nov 2023 at 11:40, Chris Angelico wrote: > Here's a couple of excellent videos on error correction, and you'll > see XOR showing up as a crucial feature: > > https://www.youtube.com/watch?v=X8jsijhllIA > https://www.youtube.com/watch?v=h0jloehRKas > I just flipped through that

Re: xor operator

On 14/11/2023 00:33, Mats Wichmann via Python-list wrote: > Hardware and software people may have somewhat different views of xor I've come at it from both sides. I started life as a telecomms technician and we learned about xor in the context of switching and relays and xor was a wiring

Re: xor operator

On Tue, 14 Nov 2023 at 12:02, Dom Grigonis via Python-list wrote: > As I am here, I will dare to ask if there is no way that `sign` function is > going to be added to `math` or `builtins`. > https://docs.python.org/3/library/math.html#math.copysign ChrisA --

Re: xor operator

I agree, from perspective of standard `all` and `any` use cases this does not seem very useful. However, in my experience it has its usages. E.g.: * If sum(map(bool, iterable) [> | <] n can be useful. Counting dead processes and similar, optimisation problems where need to re-initialise if less

Re: xor operator

On Tue, 14 Nov 2023 at 11:29, Dom Grigonis via Python-list wrote: > > > > Except the 'any' and 'all' builtins are _exactly_ the same as bitwise > > or and and applided to many bits. To do something "in line" with that > > using the 'xor' operator would ret

Re: xor operator

oth of the items is true. OP then generalized this to is exclusively one of any number of these options are true, which is different than the repetitious binary operator application, certainly, but is still very much an 'or' that excludes the case of other options being true. OP then generali

Re: xor operator

On 11/13/23 16:24, Dom Grigonis via Python-list wrote: I am not arguing that it is a generalised xor. I don’t want anything, I am just gauging if it is specialised or if there is a need for it. So just thought could suggest it as I have encountered such need several times already. It is

Re: xor operator

> Except the 'any' and 'all' builtins are _exactly_ the same as bitwise > or and and applided to many bits. To do something "in line" with that > using the 'xor' operator would return True for an odd number of True > values and False for an even Number of True values. Fair

Re: xor operator

s. This is more in line > with cases that `any` and `all` builtins are used. Except the 'any' and 'all' builtins are _exactly_ the same as bitwise or and and applided to many bits. To do something "in line" with that using the 'xor' operator would return True for an odd number of Tru

Re: xor operator

I am not arguing that it is a generalised xor. I don’t want anything, I am just gauging if it is specialised or if there is a need for it. So just thought could suggest it as I have encountered such need several times already. It is fairly clear by now that it is not a common one given it took

Re: xor operator

On Tue, 14 Nov 2023 at 10:00, Dom Grigonis via Python-list wrote: > > I am not asking. Just inquiring if the function that I described could be > useful for more people. > > Which is: a function with API that of `all` and `any` and returns `True` if > specified number of elements is True. > >

Re: xor operator

I am not asking. Just inquiring if the function that I described could be useful for more people. Which is: a function with API that of `all` and `any` and returns `True` if specified number of elements is True. It is not a generalised `xor` in strict programatic space. I.e. NOT bitwise xor

Re: xor operator

On 2023-11-13, Dom Grigonis via Python-list wrote: > Hi All, > > I think it could be useful to have `xor` builtin, which has API similar to > the one of `any` and `all`. > > * Also, it could have optional second argument `n=1`, which > * indicates how many positives indicates `True` return. For

Re: xor operator

Benchmarks: test1 = [False] * 100 + [True] * 2 test2 = [True] * 100 + [False] * 2 TIMER.repeat([ lambda: xor(test1), # 0.0168 lambda: xor(test2), # 0.0172 lambda: xor_ss(test1), # 0.1392 lambda: xor_ss(test2), # 0.0084 lambda: xor_new(test1), # 0.0116 lambda:

Re: xor operator

On Tue, 14 Nov 2023 at 08:57, Axel Reichert via Python-list wrote: > > Barry writes: > > > I do not understand how xor(iterator) works. > > I thought xor takes exactly 2 args. > > See > > https://mathworld.wolfram.com/XOR.html > > for some background (I was not aware of any generalizations for

Re: xor operator

Barry writes: > I do not understand how xor(iterator) works. > I thought xor takes exactly 2 args. See https://mathworld.wolfram.com/XOR.html for some background (I was not aware of any generalizations for more than 2 arguments either). > I also do not understand how xor can be short

Re: xor operator

xor([True, False, False, False], n=1) xor([False, False, False, True], n=1) Both of the above would evaluate to true. Well, it depends how you interpret it. In binary case it reads: “exclusively one positive bit or the other, but not both” In this case one could read: “exclusively one positive

Re: xor operator

On 2023-11-13 21:03, Barry via Python-list wrote: On 13 Nov 2023, at 17:48, Dom Grigonis wrote: Short circuiting happens, when: xor([True, True, False, False], n=1) At index 1 it is clear that the answer is false. Can you share an example with 4 values that is true? And explain why it is

Re: xor operator

I don't think an exclusive-or/truthy-entries-count-checker needs to be a builtin by any stretch. >>> def xor( iterable, n = 1 ): ... return sum( map( bool, iterable ) ) == n Or if you insist on short circuiting: >>> def xor_ss( iterable, n = 1 ): ... for intermediate in

Re: xor operator

> On 13 Nov 2023, at 17:48, Dom Grigonis wrote: > > Short circuiting happens, when: > xor([True, True, False, False], n=1) > At index 1 it is clear that the answer is false. Can you share an example with 4 values that is true? And explain why it is xor. Barry --

Re: xor operator

Well yes, I don’t think naming is very accurate. If iterable has 2 elements, then it is `xor`, otherwise it is something else - it checks the number of truth values in iterable. Short circuiting happens, when: xor([True, True, False, False], n=1) At index 1 it is clear that the answer is false.

Re: xor operator

> On 13 Nov 2023, at 15:16, Dom Grigonis via Python-list > wrote: > > I think it could be useful to have `xor` builtin, which has API similar to > the one of `any` and `all`. I do not understand how xor(iterator) works. I thought xor takes exactly 2 args. I also do not understand how xor

xor operator

Hi All, I think it could be useful to have `xor` builtin, which has API similar to the one of `any` and `all`. * Also, it could have optional second argument `n=1`, which indicates how many positives indicates `True` return. * For complete flexibility 3rd argument could indicate if `the

Re: Fallback for operator and other dunder methods

The issue was more of a wrapping around numpy array. Found the solution already. Unfortunately, there is no equivalent to __getattr__, the only way is to dynamically define them from meta. It seems it’s pretty standard to just have a collection of special method names and using them for similar

Re: Fallback for operator and other dunder methods

Il giorno mercoledì 26 luglio 2023 alle 20:35:53 UTC+2 Dom Grigonis ha scritto: > Tried exactly that and didn’t work. Neither __getattr__, nor __getattribute__ > of meta is being invoked. > > On 26 Jul 2023, at 10:01, Chris Angelico via Python-list > > wrote: > > > > On Wed, 26 Jul 2023 at

Re: Fallback for operator and other dunder methods

Tried exactly that and didn’t work. Neither __getattr__, nor __getattribute__ of meta is being invoked. > On 26 Jul 2023, at 10:01, Chris Angelico via Python-list > wrote: > > On Wed, 26 Jul 2023 at 16:52, Dom Grigonis wrote: >> >> Could you give an example? Something isn’t working for me.

Re: Fallback for operator and other dunder methods

Dom Grigonis wrote at 2023-7-26 05:22 +0300: > ... >Is there a way to achieve it without actually implementing operators? >I have looked at Proxy objects, but they do not seem suited to achieve this. Proxying is a good approach: you might have a look at `dm.reuse.proxy.OverridingProxy` (-->

Re: Fallback for operator and other dunder methods

On Wed, 26 Jul 2023 at 16:52, Dom Grigonis wrote: > > Could you give an example? Something isn’t working for me. > This is a metaclass: class Meta(type): ... class Demo(metaclass=Meta): ... In order to catch those kinds of attribute lookups, you'll need the metaclass to hook them. And

Re: Fallback for operator and other dunder methods

Could you give an example? Something isn’t working for me. > On 26 Jul 2023, at 09:40, Chris Angelico via Python-list > wrote: > > On Wed, 26 Jul 2023 at 12:23, Dom Grigonis via Python-list > wrote: >> print(a + 1)# TypeError: unsupported operand type(s) for +: 'A' >> and 'int'

Re: Fallback for operator and other dunder methods

On Wed, 26 Jul 2023 at 12:23, Dom Grigonis via Python-list wrote: > print(a + 1)# TypeError: unsupported operand type(s) for +: 'A' > and 'int' > > Is there a way to achieve it without actually implementing operators? > I have looked at Proxy objects, but they do not seem suited to

Fallback for operator and other dunder methods

To illustrate what I was trying to achieve: class A: def __init__(self, arr): self.arr = arr def __getattr__(self, name): arr_method = getattr(self.arr, name) def wrapper(*args, **kwargs): new_arr = arr_method(*args, **kwargs) return

Re: OT: Addition of a .= operator

On Wed, May 24, 2023 at 05:18:52PM +1200, dn via Python-list wrote: Note that the line numbers correctly show the true cause of the problem, despite both of them being ValueErrors. So if you have to debug this sort of thing, make sure the key parts are on separate lines (even if they're all one

Re: OT: Addition of a .= operator

On 2023-05-24 12:10:09 +1200, dn via Python-list wrote: > Perhaps more psychology rather than coding? Both. As they say, coding means writing for other people first, for the computer second. So that means anticipating what will be least confusing for that other person[1] who's going to read that

Re: Addition of a .= operator

riable name for every intermediate result, but of course > > that backfired because in this case you don't need a variable name at > > all. I should have used regular function calls ... > > > > In the context of a .= operator, though, that is *in itself* an > interesting

RE: OT: Addition of a .= operator

-list On Behalf Of dn via Python-list Sent: Wednesday, May 24, 2023 1:19 AM To: python-list@python.org Subject: Re: OT: Addition of a .= operator On 24/05/2023 12.27, Chris Angelico wrote: > On Wed, 24 May 2023 at 10:12, dn via Python-list wrote: >> However, (continuing @Pete

Re: OT: Addition of a .= operator

On 24/05/2023 12.27, Chris Angelico wrote: On Wed, 24 May 2023 at 10:12, dn via Python-list wrote: However, (continuing @Peter's theme) such confuses things when something goes wrong - was the error in the input() or in the float()? - particularly for 'beginners' - and yes, we can expand the

Re: OT: Addition of a .= operator

On Wed, 24 May 2023 at 10:12, dn via Python-list wrote: > However, (continuing @Peter's theme) such confuses things when something > goes wrong - was the error in the input() or in the float()? > - particularly for 'beginners' > - and yes, we can expand the above discussion to talk about >

OT: Addition of a .= operator

On 24/05/2023 10.21, Rob Cliffe via Python-list wrote: This sort of code might be better as a single expression. For example: user = ( request.GET["user"] .decode("utf-8") .strip() .lower() ) user = orm.user.get(name=user) LOL.  And I thought I was the one with a

Re: Addition of a .= operator

On 23/05/2023 22:03, Peter J. Holzer wrote: On 2023-05-21 20:30:45 +0100, Rob Cliffe via Python-list wrote: On 20/05/2023 18:54, Alex Jando wrote: So what I'm suggesting is something like this: hash = hashlib.sha256(b'word')

Re: Addition of a .= operator

On Wed, 24 May 2023 at 08:57, Rob Cliffe wrote: > > Do you mean "ASCII or UTF-8"? Because decoding as UTF-8 is fine with > > ASCII (it's a superset). You should always consistently get the same > > data type (bytes or text) based on the library you're using. > > > > ChrisA > OK, bad example. The

Re: Addition of a .= operator

here to make my point that you don't have to > invent a new variable name for every intermediate result, but of course > that backfired because in this case you don't need a variable name at > all. I should have used regular function calls ... > In the context of a .= operator, though, that is *in itself* an interesting data point: in order to find an example wherein the .= operator would be plausible, you had to make the .= operator unnecessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Addition of a .= operator

On 2023-05-24 07:12:32 +1000, Chris Angelico wrote: > On Wed, 24 May 2023 at 07:04, Peter J. Holzer wrote: > > But I find it easier to read if I just reuse the same variable name: > > > > user = request.GET["user"] > > user = str(user, encoding="utf-8") > > user = user.strip() > >

Re: Addition of a .= operator

This sort of code might be better as a single expression. For example: user = ( request.GET["user"] .decode("utf-8") .strip() .lower() ) user = orm.user.get(name=user) LOL.  And I thought I was the one with a (self-confessed) tendency to write too slick, dense,

Re: Addition of a .= operator

On Wed, 24 May 2023 at 08:22, Rob Cliffe wrote: > > > > This sort of code might be better as a single expression. For example: > > > > user = ( > > request.GET["user"] > > .decode("utf-8") > > .strip() > > .lower() > > ) > > user = orm.user.get(name=user) > > > > > LOL. And I

Re: Addition of a .= operator

On Wed, 24 May 2023 at 07:04, Peter J. Holzer wrote: > But I find it easier to read if I just reuse the same variable name: > > user = request.GET["user"] > user = str(user, encoding="utf-8") > user = user.strip() > user = user.lower() > user = orm.user.get(name=user) > > Each

Re: Addition of a .= operator

On 2023-05-21 20:30:45 +0100, Rob Cliffe via Python-list wrote: > On 20/05/2023 18:54, Alex Jando wrote: > > So what I'm suggesting is something like this: > > > > > > hash = hashlib.sha256(b'word') > > hash.=hexdigest() > >

Re: Addition of a .= operator

On 20/05/2023 18:54, Alex Jando wrote: I have many times had situations where I had a variable of a certain type, all I cared about it was one of it's methods. For example: import hashlib hash = hashlib.sha256(b'word') hash =

Re: Addition of a .= operator

On 21/05/23 9:18 am, Richard Damon wrote: This just can't happen (as far as I can figure) for .= unless the object is defining something weird for the inplace version of the operation, Indeed. There are clear use cases for overriding +=, but it's hard to think of one for this. So it would

Re: Addition of a .= operator

On 21/05/23 5:54 am, Alex Jando wrote: hash.=hexdigest() That would be a very strange and unprecedented syntax that munges together an attribute lookup and a call. Keep in mind that a method call in Python is actually two separate things: y = x.m() is equivalent to f = x.m y = f() But it

Re: Addition of a .= operator

operator, then using the op= version doesn't bind the name to a new object but mutates the object to a new value. This just can't happen (as far as I can figure) for .= unless the object is defining something weird for the inplace version of the operation, which is probably best to not actually

Re: Addition of a .= operator

On 2023-05-20 10:54:59 -0700, Alex Jando wrote: > I have many times had situations where I had a variable of a certain > type, all I cared about it was one of it's methods. > > For example: > > > hash = hash.hexdigest() >

RE: Addition of a .= operator

I would suggest thinking carefully about ramifications as well as any benefits of adding some or .=operator. It sounds substantially different than the whole slew of +=, *= and so on types of operators. The goal some would say of those is to either allow the interpreter optimize

Re: Addition of a .= operator

following examples? # example 1 hash = hashlib.sha256(b'word') f(hash.hexdigest()) # call f with hash's hexdigest # example 2 hash = hashlib.sha256(b'word') hash = hash.hexdigest() # extract hash's hexdigest f(hash) # call f wi

Re: Addition of a .= operator

On 21/05/2023 05.54, Alex Jando wrote: I have many times had situations where I had a variable of a certain type, all I cared about it was one of it's methods. For example: import hashlib hash = hashlib.sha256(b'word') hash =

Addition of a .= operator

I have many times had situations where I had a variable of a certain type, all I cared about it was one of it's methods. For example: import hashlib hash = hashlib.sha256(b'word') hash = hash.hexdigest()

Re: What is the reason from different output generate using logical 'and' and 'or' operator in Python 3.10.8

On Tuesday, 8 November 2022 at 05:36:49 UTC+5:30, David wrote: > On Tue, 8 Nov 2022 at 03:08, ICT Ezy wrote: > > > Please explain how to generate different output in following logical > > operations > > > >>> 0 and True > > 0 > > >>> 0 or True > > True > > >>> 1 and True > > True > >

Re: What is the reason from different output generate using logical 'and' and 'or' operator in Python 3.10.8

On Tue, 8 Nov 2022 at 03:08, ICT Ezy wrote: > Please explain how to generate different output in following logical > operations > >>> 0 and True > 0 > >>> 0 or True > True > >>> 1 and True > True > >>> 1 or True > 1 Hi, The exact explanation of how 'and' and 'or' behave can be read here:

What is the reason from different output generate using logical 'and' and 'or' operator in Python 3.10.8

Please explain how to generate different output in following logical operations >>> 0 and True 0 >>> 0 or True True >>> 1 and True True >>> 1 or True 1 -- https://mail.python.org/mailman/listinfo/python-list

Re: Operator: inappropriate wording?

Le vendredi 4 novembre 2022 à 16:29:34 UTC+1, Chris Angelico a écrit : > Yep. The word "operator" is incorrect when referring to Python's comma > (in contrast to, say, C, where the comma actually *is* an operator); > and from my understanding, the docs have already

Re: Operator: inappropriate wording?

for example omit the incorrect term "operator" while remaining > unambiguous. This would give: Yep. The word "operator" is incorrect when referring to Python's comma (in contrast to, say, C, where the comma actually *is* an operator); and from my understanding, the docs hav

Re: Operator: inappropriate wording?

Le lundi 31 octobre 2022 à 22:18:57 UTC+1, Chris Angelico a ecrit : > Wording is hard. Just ask the SQL standard whether NULL is a value. > Indeed, but I think our problem here is simpler ;) One could for example omit the incorrect term "operator" while remaining unambiguous.

Re: Operator: inappropriate wording?

On Tue, 1 Nov 2022 at 08:15, elas tica wrote: > > Le mercredi 26 octobre 2022 à 22:12:59 UTC+2, Weatherby,Gerard a ecrit : > > No. If the docs say in one place a comma is not an operator, they shouldn’t > > call it an operator in another place. > > > > I’ve

Re: Operator: inappropriate wording?

Le mercredi 26 octobre 2022 à 22:12:59 UTC+2, Weatherby,Gerard a ecrit : > No. If the docs say in one place a comma is not an operator, they shouldn’t > call it an operator in another place. > > I’ve submitted a pull request https://github.com/python/cpython/pull/98736 -- > we

Re: Operator: inappropriate wording?

No. If the docs say in one place a comma is not an operator, they shouldn’t call it an operator in another place. I’ve submitted a pull request https://github.com/python/cpython/pull/98736 -- we’ll have to see what The Powers That Be think. From: Python-list on behalf of elas tica Date

Re: Operator: inappropriate wording?

elas tica schreef op 26/10/2022 om 21:01: Quotes from The Python Language Reference, Release 3.10.8: - Note that tuples are not formed by the parentheses, but rather by use of the comma operator (p. 66) - Note: If the object is a class instance and the attribute reference occurs on both

Operator: inappropriate wording?

Quotes from The Python Language Reference, Release 3.10.8: - Note that tuples are not formed by the parentheses, but rather by use of the comma operator (p. 66) - Note: If the object is a class instance and the attribute reference occurs on both sides of the assignment operator (p. 86

Re: Typing: Is there a "cast operator"?

On 24/10/2022 05:19, Chris Angelico wrote: On Mon, 24 Oct 2022 at 14:15, Dan Stromberg wrote: I've found that mypy understands simple assert statements. So if you: if f is not None: assert f is not None os.write(f, ...) You might be in good shape. Why can't it simply

Re: Typing: Is there a "cast operator"?

On 10/23/2022 11:14 PM, Dan Stromberg wrote: On Sun, Oct 23, 2022 at 2:11 PM Paulo da Silva < p_d_a_s_i_l_v_a...@nonetnoaddress.pt> wrote: Hello! I am in the process of "typing" of some of my scripts. Using it should help a lot to avoid some errors. But this is new for me and I'm facing some

Re: Typing: Is there a "cast operator"?

On Mon, 24 Oct 2022 at 14:15, Dan Stromberg wrote: > I've found that mypy understands simple assert statements. > > So if you: > if f is not None: > assert f is not None > os.write(f, ...) > > You might be in good shape. Why can't it simply understand the if statement? I'm not a

Re: Typing: Is there a "cast operator"?

On Sun, Oct 23, 2022 at 2:11 PM Paulo da Silva < p_d_a_s_i_l_v_a...@nonetnoaddress.pt> wrote: > Hello! > > I am in the process of "typing" of some of my scripts. > Using it should help a lot to avoid some errors. > But this is new for me and I'm facing some problems. > > Let's I have the

Re: Typing: Is there a "cast operator"?

Às 23:56 de 23/10/22, Cameron Simpson escreveu: On 23Oct2022 21:36, Paulo da Silva wrote: I am in the process of "typing" of some of my scripts. Using it should help a lot to avoid some errors. But this is new for me and I'm facing some problems. Let's I have the following code (please don't

Re: Typing: Is there a "cast operator"? [RESOLVED]

e type "Optional[int]"; expected "int" Argument 1 to "close" has incompatible type "Optional[int]"; expected "int" How to solve this? Is there a way to specify that when calling os.open f is an int only? And yes there is! Exactly the "cast" op

Re: Typing: Is there a "cast operator"?

On 23Oct2022 21:36, Paulo da Silva wrote: I am in the process of "typing" of some of my scripts. Using it should help a lot to avoid some errors. But this is new for me and I'm facing some problems. Let's I have the following code (please don't look at the program content): f=None # mypy

Typing: Is there a "cast operator"?

Hello! I am in the process of "typing" of some of my scripts. Using it should help a lot to avoid some errors. But this is new for me and I'm facing some problems. Let's I have the following code (please don't look at the program content): f=None # mypy naturally assumes Optional(int) because

[issue228830] re is greedy with non-greedy operator

Change by admin : -- github: None -> 33719 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue221207] % operator on strings not documented

Change by admin : -- github: None -> 33443 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue471202] bit shift operator << precedence

Change by admin : -- github: None -> 35327 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue519230] hook method for 'is' operator

Change by admin : -- github: None -> 36121 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   3   4   5   6   7   8   9   10   >