Re: In code, list.clear doesn't throw error - it's just ignored

2022-11-13 Thread dn

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

2022-11-13 Thread Chris Angelico
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

2022-11-13 Thread Greg Ewing

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

2022-11-13 Thread Michael Speer
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

2022-11-13 Thread DFS

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

2022-11-13 Thread Jon Ribbens via Python-list
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

2022-11-13 Thread Chris Angelico
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

2022-11-13 Thread MRAB

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

2022-11-13 Thread Chris Angelico
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

2022-11-13 Thread Greg Ewing

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

2022-11-13 Thread Jon Ribbens via Python-list
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

2022-11-13 Thread DFS

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

2022-11-13 Thread Jon Ribbens via Python-list
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

2022-11-13 Thread DFS

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?

2022-11-13 Thread Eryk Sun
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

2022-11-13 Thread DFS

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

2022-11-13 Thread Pancho via Python-list

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

2022-11-13 Thread Jessica Smith
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?

2022-11-13 Thread Thomas Passin

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?

2022-11-13 Thread Barry


> 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?

2022-11-13 Thread Jessica Smith
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

2022-11-13 Thread Axy via Python-list

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