Re: In code, list.clear doesn't throw error - it's just ignored
On 14/11/2022 12.12, DFS wrote: On 11/13/2022 5:20 PM, Jon Ribbens wrote: On 2022-11-13, DFS wrote: In code, list.clear is just ignored. At the terminal, list.clear shows in code: x = [1,2,3] x.clear print(len(x)) 3 at terminal: x = [1,2,3] x.clear print(len(x)) 3 Caused me an hour of frustration before I noticed list.clear() was what I needed. x = [1,2,3] x.clear() print(len(x)) 0 If you want to catch this sort of mistake automatically then you need a linter such as pylint: $ cat test.py """Create an array and print its length""" array = [1, 2, 3] array.clear print(len(array)) $ pylint -s n test.py * Module test test.py:4:0: W0104: Statement seems to have no effect (pointless-statement) Thanks, I should use linters more often. But why is it allowed in the first place? I stared at list.clear and surrounding code a dozen times and said "Looks right! Why isn't it clearing the list?!?!" 2 parens later and I'm golden! It looks 'right' because it is 'right'! However, compared with what was intended, it was 'wrong'! « I really hate this d***umb machine, I wish that they would sell it. It never does quite what I want, but only what I tell it! » Lifting some text from a recent PUG-meeting: «Distinguishing functions and their names: Please remind yourself that is_odd is the name of a function, whereas is_odd() calls the function and could thus be considered a 'label' for the returned-value – either approach could be used in different situations. » In this case, the subject is a method, and accordingly has a slightly different flavor. Rather than a return-value, the impact is an effect within the scope and/or to the state of the object. However, not materially-different from the OP's question. It is assumed that there is no difficulty related to calling the function, eg len( x ). So, why would we use the function/method by name instead of its asking for its return-value? (please remember that a Python function is a "first class" object) The (above) Challenge to PUG-members was to use code which produces the Fibonacci Sequence, and out of the first 16 values, return the number of Fibonacci-values which are also odd-numbers. We started with straight-line code which mixed-up these various steps in the process. As the challenge continued, such tangling made it very difficult to enable any variations. To illustrate the SRP and DIP (Single Responsibility and Dependency Inversion Principles of SOLID Architecture), we refactored and refactored, ending-up with: values_counted = sm.sequence_select_and_project( fg.fibonacci_generator, is_odd, limit, ) sequence_select_and_project is a for-loop spanning two if-statements which count or break fibonacci_generator is self-explanatory (hopefully) is_odd returns boolean advice limit is 16 Note how the first two arguments are [generator-]function names, cf function-calls! Now for 'the magic' of a dependency-inverted plug-in architecture:- If the 16 is changed to 32, we'll be comfortable with the idea that twice as many values will be generated and considered. So, think about changing the generator to produce (say) prime numbers. Alternately, alter the program to count only values divisible by two (perhaps using "is_even" as function-name). By 'plugging-in' a different function-name, the above control-routine can be used with any suitably-lengthy sequence as its data-source, and/or selection-criteria function! Accordingly, using the name of a function can be as useful as using the result of a function-call - even if the latter is far more common. -- -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On Mon, 14 Nov 2022 at 18:00, Greg Ewing wrote: > > On 14/11/22 3:13 pm, MRAB wrote: > > But if it's an expression where it's expecting a statement and it's not > > a call, then it's probably a bug. > > The key word there is "probably". If there's any chance it > could be not a bug, it can't be an error. At most it should > be a warning, and that's what linters are for. I wouldn't > like the core interpreter to be producing a bunch of warnings > for things like this. > Notably, linters can be taught about more complex idioms, like: try: raw_input except NameError: raw_input = input which is an easy way to make polyglot Py2/Py3 code that handles the presence/absence of a particular name. Or, similarly: try: os.sendfile except AttributeError: ... # cope with sendfile not being available When os.sendfile exists, it's a completely useless expression. When it doesn't, it's an error. But the difference between those two is crucial. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 14/11/22 3:13 pm, MRAB wrote: But if it's an expression where it's expecting a statement and it's not a call, then it's probably a bug. The key word there is "probably". If there's any chance it could be not a bug, it can't be an error. At most it should be a warning, and that's what linters are for. I wouldn't like the core interpreter to be producing a bunch of warnings for things like this. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
Python doesn't care what an expression returns. You've written an expression that returns the value of the 'clear' function that is bound to that particular list. The interpreter doesn't know or care if accessing that 'clear' attribute on the class returns a function or for some reason triggers a bunch of side effects that the author decided they wanted to use __getattr__ to trigger. 'list.clear' might be a perfectly reasonable expression in some library. I'd rather it not be, but hey, there are millions of python programmers making all kinds of code out there arbitrary expressions can have arbitrary effects. just because a value isn't assigned, returned or used as an argument to a function doesn't mean it isn't doing anything. you might then want python to inspect the result of the function, but how can python know if the author isn't purposely ignoring the return value of the expression? people can call functions that return values for only their side effects. if you can't tell by the form of the expression or the value it returns, what is the linter supposed to look for? what is the interpreter supposed to look for? if you want to avoid accidentally failing to clear a list during a function, you should write tests that check that various inputs to the function produce the expected outputs. 'unit tests' are a good place to make sure that code is acting as you want it to for one-off scripts, you should always make the thing dry-run or convert from an input to an output (rather than in-place) so you can rerun them a few times and make sure they're doing what you want. sometimes making sure things are right is just on you. there will always be the occasional silly error in a script that is hard to see until you step away for a moment. stepping away and coming back is a pretty good thing to do if you're stuck on something that feels impossible. On Sun, Nov 13, 2022 at 10:33 PM DFS wrote: > On 11/13/2022 9:11 PM, Chris Angelico wrote: > > On Mon, 14 Nov 2022 at 11:53, DFS wrote: > >> > >> On 11/13/2022 5:20 PM, Jon Ribbens wrote: > >>> On 2022-11-13, DFS wrote: > In code, list.clear is just ignored. > At the terminal, list.clear shows > > > > in code: > x = [1,2,3] > x.clear > print(len(x)) > 3 > > at terminal: > x = [1,2,3] > x.clear > > print(len(x)) > 3 > > > Caused me an hour of frustration before I noticed list.clear() was > what > I needed. > > x = [1,2,3] > x.clear() > print(len(x)) > 0 > >>> > >>> If you want to catch this sort of mistake automatically then you need > >>> a linter such as pylint: > >>> > >>> $ cat test.py > >>> """Create an array and print its length""" > >>> > >>> array = [1, 2, 3] > >>> array.clear > >>> print(len(array)) > >>> $ pylint -s n test.py > >>> * Module test > >>> test.py:4:0: W0104: Statement seems to have no effect > (pointless-statement) > >> > >> > >> Thanks, I should use linters more often. > >> > >> But why is it allowed in the first place? > >> > >> I stared at list.clear and surrounding code a dozen times and said > >> "Looks right! Why isn't it clearing the list?!?!" > >> > >> 2 parens later and I'm golden! > >> > > > > No part of it is invalid, so nothing causes a problem. For instance, > > you can write this: > > > If it wastes time like that it's invalid. > > This is an easy check for the interpreter to make. > > If I submit a suggestion to python-list@python.org will it just show up > here? Or do the actual Python devs intercept it? > > > > > > > 1 > > > > And you can write this: > > > 1 + 2 > > > > And you can write this: > > > print(1 + 2) > > > > But only one of those is useful in a script. Should the other two be > > errors? No. But linters WILL usually catch them, so if you have a good > > linter (especially built into your editor), you can notice these > > things. > > > ran pylint against it and got 0.0/10. > > > --disable= > invalid-name > multiple-statements > bad-indentation > line-too-long > trailing-whitespace > missing-module-docstring > missing-function-docstring > too-many-lines > fixme > > > and got 8.9/10. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 11/13/2022 9:11 PM, Chris Angelico wrote: On Mon, 14 Nov 2022 at 11:53, DFS wrote: On 11/13/2022 5:20 PM, Jon Ribbens wrote: On 2022-11-13, DFS wrote: In code, list.clear is just ignored. At the terminal, list.clear shows in code: x = [1,2,3] x.clear print(len(x)) 3 at terminal: x = [1,2,3] x.clear print(len(x)) 3 Caused me an hour of frustration before I noticed list.clear() was what I needed. x = [1,2,3] x.clear() print(len(x)) 0 If you want to catch this sort of mistake automatically then you need a linter such as pylint: $ cat test.py """Create an array and print its length""" array = [1, 2, 3] array.clear print(len(array)) $ pylint -s n test.py * Module test test.py:4:0: W0104: Statement seems to have no effect (pointless-statement) Thanks, I should use linters more often. But why is it allowed in the first place? I stared at list.clear and surrounding code a dozen times and said "Looks right! Why isn't it clearing the list?!?!" 2 parens later and I'm golden! No part of it is invalid, so nothing causes a problem. For instance, you can write this: If it wastes time like that it's invalid. This is an easy check for the interpreter to make. If I submit a suggestion to python-list@python.org will it just show up here? Or do the actual Python devs intercept it? 1 And you can write this: 1 + 2 And you can write this: print(1 + 2) But only one of those is useful in a script. Should the other two be errors? No. But linters WILL usually catch them, so if you have a good linter (especially built into your editor), you can notice these things. ran pylint against it and got 0.0/10. --disable= invalid-name multiple-statements bad-indentation line-too-long trailing-whitespace missing-module-docstring missing-function-docstring too-many-lines fixme and got 8.9/10. -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 2022-11-14, Greg Ewing wrote: > On 14/11/22 1:31 pm, Jon Ribbens wrote: >> On 2022-11-13, DFS wrote: >>> But why is it allowed in the first place? >> >> Because it's an expression, and you're allowed to execute expressions. > > To put it a bit more clearly, you're allowed to evaluate > an expression and ignore the result. ... because it may have side effects, and it's not possible to determine whether it will or not in advance. -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On Mon, 14 Nov 2022 at 13:18, MRAB wrote: > > On 2022-11-14 00:55, Greg Ewing wrote: > > On 14/11/22 1:31 pm, Jon Ribbens wrote: > >> On 2022-11-13, DFS wrote: > >>> But why is it allowed in the first place? > >> > >> Because it's an expression, and you're allowed to execute expressions. > > > > To put it a bit more clearly, you're allowed to evaluate > > an expression and ignore the result. > > > But if it's an expression where it's expecting a statement and it's not > a call, then it's probably a bug. Maybe, but I'd be dubious of making it that simplistic. For instance, which of these is more likely to be useless? spam or ham() spam() or ham Syntactically, both of them are 'or' expressions, but one of them is almost certainly unnecessary, while the other is just an oddly-written conditional statement and most definitely useful. In any case, this is the job of linters, NOT the language itself. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 2022-11-14 00:55, Greg Ewing wrote: On 14/11/22 1:31 pm, Jon Ribbens wrote: On 2022-11-13, DFS wrote: But why is it allowed in the first place? Because it's an expression, and you're allowed to execute expressions. To put it a bit more clearly, you're allowed to evaluate an expression and ignore the result. But if it's an expression where it's expecting a statement and it's not a call, then it's probably a bug. -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On Mon, 14 Nov 2022 at 11:53, DFS wrote: > > On 11/13/2022 5:20 PM, Jon Ribbens wrote: > > On 2022-11-13, DFS wrote: > >> In code, list.clear is just ignored. > >> At the terminal, list.clear shows > >> > >> > >> > >> in code: > >> x = [1,2,3] > >> x.clear > >> print(len(x)) > >> 3 > >> > >> at terminal: > >> x = [1,2,3] > >> x.clear > >> > >> print(len(x)) > >> 3 > >> > >> > >> Caused me an hour of frustration before I noticed list.clear() was what > >> I needed. > >> > >> x = [1,2,3] > >> x.clear() > >> print(len(x)) > >> 0 > > > > If you want to catch this sort of mistake automatically then you need > > a linter such as pylint: > > > >$ cat test.py > >"""Create an array and print its length""" > > > >array = [1, 2, 3] > >array.clear > >print(len(array)) > >$ pylint -s n test.py > >* Module test > >test.py:4:0: W0104: Statement seems to have no effect > > (pointless-statement) > > > Thanks, I should use linters more often. > > But why is it allowed in the first place? > > I stared at list.clear and surrounding code a dozen times and said > "Looks right! Why isn't it clearing the list?!?!" > > 2 parens later and I'm golden! > No part of it is invalid, so nothing causes a problem. For instance, you can write this: >>> 1 And you can write this: >>> 1 + 2 And you can write this: >>> print(1 + 2) But only one of those is useful in a script. Should the other two be errors? No. But linters WILL usually catch them, so if you have a good linter (especially built into your editor), you can notice these things. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 14/11/22 1:31 pm, Jon Ribbens wrote: On 2022-11-13, DFS wrote: But why is it allowed in the first place? Because it's an expression, and you're allowed to execute expressions. To put it a bit more clearly, you're allowed to evaluate an expression and ignore the result. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 2022-11-13, DFS wrote: > On 11/13/2022 5:20 PM, Jon Ribbens wrote: >> On 2022-11-13, DFS wrote: >>> In code, list.clear is just ignored. >>> At the terminal, list.clear shows >>> >>> >>> >>> in code: >>> x = [1,2,3] >>> x.clear >>> print(len(x)) >>> 3 >>> >>> at terminal: >>> x = [1,2,3] >>> x.clear >>> >>> print(len(x)) >>> 3 >>> >>> >>> Caused me an hour of frustration before I noticed list.clear() was what >>> I needed. >>> >>> x = [1,2,3] >>> x.clear() >>> print(len(x)) >>> 0 >> >> If you want to catch this sort of mistake automatically then you need >> a linter such as pylint: >> >>$ cat test.py >>"""Create an array and print its length""" >> >>array = [1, 2, 3] >>array.clear >>print(len(array)) >>$ pylint -s n test.py >>* Module test >>test.py:4:0: W0104: Statement seems to have no effect >> (pointless-statement) > > > Thanks, I should use linters more often. > > But why is it allowed in the first place? Because it's an expression, and you're allowed to execute expressions. -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 11/13/2022 5:20 PM, Jon Ribbens wrote: On 2022-11-13, DFS wrote: In code, list.clear is just ignored. At the terminal, list.clear shows in code: x = [1,2,3] x.clear print(len(x)) 3 at terminal: x = [1,2,3] x.clear print(len(x)) 3 Caused me an hour of frustration before I noticed list.clear() was what I needed. x = [1,2,3] x.clear() print(len(x)) 0 If you want to catch this sort of mistake automatically then you need a linter such as pylint: $ cat test.py """Create an array and print its length""" array = [1, 2, 3] array.clear print(len(array)) $ pylint -s n test.py * Module test test.py:4:0: W0104: Statement seems to have no effect (pointless-statement) Thanks, I should use linters more often. But why is it allowed in the first place? I stared at list.clear and surrounding code a dozen times and said "Looks right! Why isn't it clearing the list?!?!" 2 parens later and I'm golden! -- https://mail.python.org/mailman/listinfo/python-list
Re: In code, list.clear doesn't throw error - it's just ignored
On 2022-11-13, DFS wrote: > In code, list.clear is just ignored. > At the terminal, list.clear shows > > > > in code: > x = [1,2,3] > x.clear > print(len(x)) > 3 > > at terminal: > x = [1,2,3] > x.clear > > print(len(x)) > 3 > > > Caused me an hour of frustration before I noticed list.clear() was what > I needed. > > x = [1,2,3] > x.clear() > print(len(x)) > 0 If you want to catch this sort of mistake automatically then you need a linter such as pylint: $ cat test.py """Create an array and print its length""" array = [1, 2, 3] array.clear print(len(array)) $ pylint -s n test.py * Module test test.py:4:0: W0104: Statement seems to have no effect (pointless-statement) -- https://mail.python.org/mailman/listinfo/python-list
In code, list.clear doesn't throw error - it's just ignored
In code, list.clear is just ignored. At the terminal, list.clear shows in code: x = [1,2,3] x.clear print(len(x)) 3 at terminal: x = [1,2,3] x.clear print(len(x)) 3 Caused me an hour of frustration before I noticed list.clear() was what I needed. x = [1,2,3] x.clear() print(len(x)) 0 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?
On 11/13/22, Jessica Smith <12jessicasmit...@gmail.com> wrote:
> Consider the following code ran in Powershell or cmd.exe:
>
> $ python -c "print('└')"
> └
>
> $ python -c "print('└')" > test_file.txt
> Traceback (most recent call last):
> File "", line 1, in
> File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in
> encode
> return codecs.charmap_encode(input,self.errors,encoding_table)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
> position 0: character maps to
If your applications and existing data files are compatible with using
UTF-8, then in Windows 10+ you can modify the administrative regional
settings in the control panel to force using UTF-8. In this case,
GetACP() and GetOEMCP() will return CP_UTF8 (65001), and the reserved
code page constants CP_ACP (0), CP_OEMCP (1), CP_MACCP (2), and
CP_THREAD_ACP (3) will use CP_UTF8.
You can override this on a per-application basis via the
ActiveCodePage setting in the manifest:
https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activecodepage
In Windows 10, this setting only supports "UTF-8". In Windows 11, it
also supports "legacy" to allow old applications to run on a system
that's configured to use UTF-8. Setting an explicit locale is also
supported in Windows 11, such as "en-US", with fallback to UTF-8 if
the given locale has no legacy code page.
Note that setting the system to use UTF-8 also affects the host
process for console sessions (i.e. conhost.exe or openconsole.exe),
since it defaults to using the OEM code page (UTF-8 in this case).
Unfortunately, a legacy read from the console host does not support
reading non-ASCII text as UTF-8. For example:
>>> os.read(0, 6)
SPĀM
b'SP\x00M\r\n'
This is a trivial bug in the console host, which stems from the fact
that UTF-8 is a multibyte encoding (1-4 bytes per code), but for some
reason the console team at Microsoft still hasn't fixed it. You can
use chcp.com to set the console's input and output code pages to
something other than UTF-8 if you have to read non-ASCII input in a
legacy console app. By default, this problem doesn't affect Python's
sys.stdin, which internally uses wide-character ReadConsoleW() with
the system's native text encoding, UTF-16LE.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need max values in list of tuples, based on position
On 11/13/2022 7:37 AM, Pancho wrote: On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x: maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)] print(maxvals) [11,41,12] - So now the challenge is making it a one-liner! x = [(11,1,1),(1,41,2),(9,3,12)] print(functools.reduce( lambda a,b : [max(w,c) for w,c in zip(a,b)], x, [0]*len(x[0]))) noice! -- https://mail.python.org/mailman/listinfo/python-list
Re: Need max values in list of tuples, based on position
On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x: maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)] print(maxvals) [11,41,12] - So now the challenge is making it a one-liner! x = [(11,1,1),(1,41,2),(9,3,12)] print(functools.reduce( lambda a,b : [max(w,c) for w,c in zip(a,b)], x, [0]*len(x[0]))) -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange UnicodeEncodeError in Windows image on Azure DevOps and Github
On Fri, Nov 11, 2022 at 8:16 PM Eryk Sun wrote: > If sys.std* are console files, then in Python 3.6+, sys.std*.buffer.raw will > be _io._WindowsConsoleIO > io.TextIOWrapper uses locale.getpreferredencoding(False) as the default > encoding Thank you for your replies - checking the sys.stdout.buffer.raw value is what finally helped me understand. Turns out, the Windows agent is redirecting the output of all python commands to a file, so sys.stdout is a file using the locale encoding of cp1252, instead of being a stream using encoding utf8. I wrote up a gist with my findings to hopefully help out some other poor soul in the future: https://gist.github.com/NodeJSmith/e7e37f2d3f162456869f015f842bcf15 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?
On 11/13/2022 9:49 AM, Jessica Smith wrote:
Consider the following code ran in Powershell or cmd.exe:
$ python -c "print('└')"
└
$ python -c "print('└')" > test_file.txt
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
position 0: character maps to
Is this a known limitation of Windows + Unicode? I understand that
using -x utf8 would fix this, or modifying various environment
variables. But is this expected for a standard Python installation on
Windows?
Jessica
This also fails with the same error:
$ python -c "print('└')" |clip
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?
> On 13 Nov 2022, at 14:52, Jessica Smith <12jessicasmit...@gmail.com> wrote:
>
> Consider the following code ran in Powershell or cmd.exe:
>
> $ python -c "print('└')"
> └
>
> $ python -c "print('└')" > test_file.txt
> Traceback (most recent call last):
> File "", line 1, in
> File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
>return codecs.charmap_encode(input,self.errors,encoding_table)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
> position 0: character maps to
>
> Is this a known limitation of Windows + Unicode? I understand that
> using -x utf8 would fix this, or modifying various environment
> variables. But is this expected for a standard Python installation on
> Windows?
Your other thread has a reply that explained this.
It is a problem with windows and character sets.
You have to set things up to allow Unicode to work.
Barry
>
> Jessica
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?
Consider the following code ran in Powershell or cmd.exe:
$ python -c "print('└')"
└
$ python -c "print('└')" > test_file.txt
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
position 0: character maps to
Is this a known limitation of Windows + Unicode? I understand that
using -x utf8 would fix this, or modifying various environment
variables. But is this expected for a standard Python installation on
Windows?
Jessica
--
https://mail.python.org/mailman/listinfo/python-list
Re: Superclass static method name from subclass
On 11/11/2022 16:21, Ian Pilcher wrote:
Is it possible to access the name of a superclass static method, when
defining a subclass attribute, without specifically naming the super-
class?
Contrived example:
class SuperClass(object):
@staticmethod
def foo():
pass
class SubClass(SuperClass):
bar = SuperClass.foo
^^
Is there a way to do this without specifically naming 'SuperClass'?
There is, but it's weird. I constructed classes from yaml config so I
did not even know the name of super class but I wanted similar things
for my clabate templates and I implemented superattr() which works for me:
class BasePage:
body = 'Hello'
class MySpecificPage(BasePage):
body = superattr() + 'World'
Actually, it's suboptimally elegant code. Artistic code, to be clear, as
if you looked at modern art and thought: WTF? Also, it's specific for
templates only and supports only __add__.
But I think the approach can be extended to a general superclass() if
you log __getattr__ calls and apply them in __get__ method same way.
I realize this reply is not an immediate help and probably won't help,
but there's always a way out.
Axy.
Here's the code:
class superattr:
'''
This is a descriptor that allows extending attributes in a simple and
elegant way:
my_attr = superattr() + some_addition_to_my_attr
'''
def __init__(self):
self.additions = []
def __set_name__(self, owner, name):
print('__set_name__', name)
self.attr_name = name
def __get__(self, obj, objtype=None):
for cls in obj.__class__.__mro__[1:]:
try:
value = getattr(cls, self.attr_name)
except AttributeError:
continue
for a in self.additions:
value = value + a
return value
raise AttributeError(self.attr_name)
def __add__(self, other):
print('__add__:', other)
self.additions.append(other)
return self Full article:
https://declassed.art/en/blog/2022/07/02/a-note-on-multiple-inheritance-in-python
--
https://mail.python.org/mailman/listinfo/python-list
