Re: Changing filenames from Greeklish => Greek (subprocess complain)

[Roel Schroeven]

Νικόλαος Κούρας schreef:

Session settings afaik is for putty to remember hosts to connect to,
not terminal options. I might be worng though. No matter how many times
i change its options next time i run it always defaults back.


Putty can most definitely remember its settings:
- Start PuTTY; you should get the "PuTTY Configuration" window
- Select a session in the list of sessions
- Click Load
- Change any setting you want to change
- Go back to Session in the Category treeview
- Click Save

HTH

--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Split a list into two parts based on a filter?

[Roel Schroeven]

Roy Smith schreef:

I have a list, songs, which I want to divide into two groups.
Essentially, I want:

new_songs = [s for s in songs if s.is_new()]
old_songs = [s for s in songs if not s.is_new()]

but I don't want to make two passes over the list.  I could do:

new_songs = []
old_songs = []
for s in songs:
if s.is_new():
new_songs.append(s)
else:
old_songs.append(s)

Which works, but is klunky compared to the two-liner above.  This
seems like a common enough thing that I was expecting to find
something in itertools which did this.  I'm thinking something along
the lines of:

matches, non_matches = isplit(lambda s: s.is_new, songs)

Does such a thing exist?


You could do something like:

new_songs, old_songs = [], []
[(new_songs if s.is_new() else old_songs).append(s) for s in songs]

But I'm not sure that that's any better than the long version.

--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Split a list into two parts based on a filter?

[Roel Schroeven]

Peter Otten schreef:

Fábio Santos wrote:


On 10 Jun 2013 23:54, "Roel Schroeven"  wrote:

You could do something like:

new_songs, old_songs = [], []
[(new_songs if s.is_new() else old_songs).append(s) for s in songs]

But I'm not sure that that's any better than the long version.

This is so beautiful!


It makes me cringe. 

This code does spurious work to turn what is naturally written as a for loop 
into a list comprehension that is thrown away immediately. 


I agree. I see two problems with it: it's not very readable or pythonic, 
and it creates a list that is not needed and is immediately thrown away.


I wrote that code just to see if I could make it work that way. In real 
code I would never write it that way, let's make that clear :)



--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Roel Schroeven]

Νίκος schreef:

Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:

Names are *always* linked to objects, not to other names.

a = []
b = a  # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before


I see, thank you Steven.

But since this is a fact how do you create complicated data structures 
that rely on various variables pointing one to another liek we did in 
C++(cannot recall their names) ?


You almost never need to do that in Python. But if you really want to, 
out of curiosity, you can. For example, you could create a simple singly 
linked list like this:


>>> class Node(object):
def __init__(self, value):
self.value = value
self.next = None


>>> first = Node(1)
>>> second = Node(2)
>>> first.next = second

You could iterate over it like this:

>>> def iterate_linked_list(node):
while node:
yield node.value
node = node.next


>>> for v in iterate_linked_list(first):
print v


--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: PySerial could not open port COM4: [Error 5] Access is denied - please help

[Roel Schroeven]

Temia Eszteri schreef:

Actually, I believe someone in an earlier thread in the newsgroup or
elsewhere pointed out that serial ports automatically open under
Windows. I'd have to look it back up when I have the time, which I
don't have at the moment, unfortunately.


That doesn't have anything to do with Windows, but with how pySerial 
works. See the documentation for __init__():


"The port is immediately opened on object creation, when a port is 
given. It is not opened when port is None and a successive call to 
open() will be needed."


So if your script does something like

prt = serial.Serial('COM4')

then pySerial automatically opens the port, and you shouldn't call 
prt.open() anymore.


If, on the contrary, you do something like

prt = serial.Serial()
prt.port = 'COM4'

then pySerial doesn't open the port, and you have to call prt.open() to 
do it.


PySerial has this same behavior on both Windows and Linux. The 
difference might be that on Linux it is possible to open serial ports 
more than once, while that doesn't work on Windows.


Best regards,
Roel

--
http://mail.python.org/mailman/listinfo/python-list

Re: Slow output

[Roel Schroeven]

subhabangal...@gmail.com schreef:

Dear Group,
I am Sri Subhabrata Banerjee writing from India. I am running a small
program which exploits around 12 1 to 2 KB .txt files. I am using MS
Windows XP Service Pack 3 and Python 2.6 where IDLE is GUI. The text
is plain ASCII text. The RAM of the machine is around 2 GB. To run
the program the machine is becoming dead slow and it is executing
only after several minutes. I am shocked as I have run hugely loaded
Statistical Learning stuff only on 516MB RAM on Python using Windows
XP only. And that too on a laptop. I am not getting. I discussed the
issue with my system administrator and he increased the RAM to 8GB
result improved by 30% but not satisfactory speed. May any one
suggest me what may be the likely issue?


Does the program generate a lot of text? Do you run the program in IDLE? 
IDLE gets very slow when it has to show a lot of text. Try running the 
program from the command line to see if that offers any improvement.


Best regards,
Roel

--
http://mail.python.org/mailman/listinfo/python-list

Re: Basic JSON question: Do I really need the quotes

[Roel Schroeven]

moo...@yahoo.co.uk schreef:

Hi,
I need to define some configuration in a file that will be manually created.
Internally, the data will be stored as a dict, which contains various 
properties related to a design
e.g. Design Name, dependencies, lists of files (and associated libraries).
json seemed a quick an easy way of achieving this
Anyway, in simple terms my question - if I know everything is a string, how can 
I omit the quotation marks?

The problem is that I don't want to make users have to type redundant 
characters.
Is it possible?


Not in JSON. Maybe you could try YAML?

--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: readline trick needed

[Roel Schroeven]

Etienne Robillard schreef:

On Sun, 14 Oct 2012 00:47:52 +1100
Chris Angelico  wrote:


Excuse me?

I'm not overly familiar with readline, so perhaps there is a really
obvious way to do what Steven's trying to do, but this post does not
appear to be the result of a lack of thinking.

If it really IS that obvious to you, post a link to appropriate
documentation without the rudeness... that way it'll be useful to
everyone, not just cathartic to you.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list


whatever. i don't feel much like replying to idiots today


Then simply don't. Much better then replying in such a rude way.

I leave the question of who is being an idiot here as an exercise to the 
reader.


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Roel Schroeven]

Zero Piraeus schreef:

:

Not sure exactly how to put this ...

I'm a mostly passive subscriber to this list - my posts here over the
years could probably be counted without having to take my socks off -
so perhaps I have no right to comment, but I've noticed a marked
increase in aggressive language here lately, so I'm putting my head
above the parapet to say that I don't appreciate it.


Same here. I've been lurking here for a number of years, and I've always 
regarded this list as an example of friendly civilized behavior, quite 
exceptional on the Internet. I also have the impression that situation 
is changing for the worse, and it worries me too.


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Feedback on my python framework I'm building.

[Roel Schroeven]

MRAB schreef:

On 2012-10-14 23:38, Dave Angel wrote:

On 10/14/2012 08:48 AM, Roy Smith wrote:

In article <507a3365$0$6574$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:


Remember using PEEK and POKE commands with BASIC back in
1978? Pretty much impossible in Python.

But, trivial to implement as an extension :-)

PEEK and POKE were intended to be used with memory mapped devices.
Simplest example is the 6502 chip, which had no I/O bus -- it was all
memory mapped.  Want to change baud rate?  poke a byte somewhere.

These days, the only device I can think of that's usually memory mapped
is the video.  And few programs talk to it that way.

Now, INP and OUT (or various similar names) were for doing port I/o.
But I suspect that modern systems aren't going to let you do much of
that either.


It depends on the CPU. Some have specialised instructions for I/O,
others don't.


I think Roy Smith meant that the OS on modern systems generally prevents 
direct access from user space to either memory mapped I/O or port mapped 
I/O. Embedded systems might allow direct access, but AFAIK Python 
doesn't run on those.


Best regards,
Roel

--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

r...@roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with time.time() standing still

[Roel Schroeven]

Hi Bob,

This reminds of a problem we had at work some years ago. I've followed
the thread from the beginning, but I hadn't a clue about what could
possibly cause the problem until you said:

Bob Cowdery schreef:
Hopefully somebody can add the last piece of this puzzle. My code didn't 
work because I did make a silly mistake. The number of seconds since 
EPOC is a large number but it also needs a high precision. Attempting to 
put this value into a 32 bit float corrupts the least significant part 
because 24 bits  cannot hold that precision. Now Python floats are C 
doubles and the calculation in timemodule.c is in doubles right back to 
Python. Normally this retains the precision. For some inexplicable 
reason when I make certain calls into this vendors SDK, ftime()  is 
getting precision problems and appears to be frozen as a result.


Our problem turned out to be caused by a loss of precision in an
application of ours, caused by Direct3D. The solution for us was to
include the flag D3DCREATE_FPU_PRESERVE in CreateDevice(). The
documentation seems to imply that the lower precision only has effect in
the Direct3D code, but in reality it lowers precision in the rest of the
code too (the whole process or the whole thread, I'm not sure).

In your case it seems harder to solve: as far as I understand, the
trigger is somewhere in the vendors SDK, which you have no control over.
I'm afraid I don't know what you can do about that.

Best regards,
Roel

--
"The reasonable man adapts himself to the world. The unreasonable
man persists in trying to adapt the world to himself. Therefore,
all progress depends on the unreasonable man."
-- George Bernard Shaw

r...@roelschroeven.net
http://roelschroeven.net

--
http://mail.python.org/mailman/listinfo/python-list

Re: Addition problems

[Roel Schroeven]

Op 2011-04-01 16:04, vm schreef:
> I'm analyzing some data in python. I have stumbled across unusual problem:
> 
> I have the function...
> 
> def fun1(params_used_below_except_lk_and_lk2):
> lk = 0.0
> lk2 = 0.0
> for raw_data, hist, freq in raw_data_hist_list:
> lk2 = lk2 + fun2(some_constants_and_params_from_this_scope)
> q = fun2(same_args_as_before)
> lk = lk + q
> print lk, lk2
> 
> For some set of input parameters, This function with specific input 
> prints out the same constant twice (as expected):
> 
> 15377.7424582 15377.7424582 (twice the same value)
> 
> If I comment out lines q = fun2 and lk = lk + q, fun1, with the same 
> parameters, prints:
> 
> 0.0 3.3469936856
> 
> First value is expected, but I cannot understand how come the second 
> value is different in these two cases!

Let's have a look at your source:

> fun1 source:
> 
> def process_measurements_beta_lk(x, raw_data_hist_list):
> lk = 0.0
> lk2 = 0.0
> (p,q,loc,scale) = x
> for raw_data, hist, freq in raw_data_hist_list:
> lk2 =   lk2 + get_beta_func_fit_quality_hist_lk('beta',
> (p,q,loc,scale), raw_data, hist)
> #q = get_beta_func_fit_quality_hist_lk('beta',(p,q,loc,scale), 
> raw_data, hist)
> # lk = lk + q
> print lk, lk2
> retrun lk

The lie with "lk2 = " uses the value of q. In the version with commented
lines, that value is never changed, while it is changed each iteration
in the version with the lines uncommented.

-- 
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Roel Schroeven]

Steve D'Aprano schreef op 17/09/2017 3:09:

On Sun, 17 Sep 2017 04:00 am, Stefan Ram wrote:


Steve D'Aprano  writes:

"Hi, I've been programming in Python for what seems like days now, and here's
all the things that you guys are doing wrong.

  I never ever have written a line of Python 2. I started with
  Python 3.6.0. Yet a very frequent mistake of mine is the
  imission of parentheses after »print«.


That's remarkable.

Do you also forget the parentheses around `len`, and `iter`, and `math.sin()`?
If not, what's so special about print?


I don't know, but I also frequently forget the parentheses around 
`print`. I do have Python 2 experience so maybe it's just a habit that 
I've been unable to grow out of yet. OTOH I also regulary use `printf()` 
and friends in C and C++ and sometimes even PHP, and there I never 
forget the parentheses. I don't know how, I don't know why, it just happens.


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Roel Schroeven]

Steve D'Aprano schreef op 17/09/2017 20:49:

On Mon, 18 Sep 2017 04:09 am, Tim Chase wrote:
So, you don't like the extra parentheses with print. But you don't mind the
parentheses in sys.stderr.write (16 chars, versus five for print) or having to
manually concatenate the strings and manually add a newline at the end. Because
apparently using print and sys.stderr.write is simpler than print with parens.


Actually I think Tim has a point. I did the same in Python 2: use simple 
easy-to-use `print` for the simple cases, and `sys.stdout.write()` or 
sometimes `sys.stderr.write()` when simple `print` wasn't enough.


I do prefer Python 3's print-as-a-function because "special cases aren't 
special enough to break the rules", but I feel there's a case to be made 
 for Python 2's print-as-a-statement because "(although) practicality 
beats purity" sometimes.



--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Spacing conventions

[Roel Schroeven]

Steve D'Aprano schreef op 28/09/2017 3:45:

One of Raymond Hettinger's videos talks about writing beautiful Python code, and
how slavishly obeying PEP 8 is not really productive. I'll try to find a link
later and post it.


That would be

Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful 
intelligible code - PyCon 2015

https://www.youtube.com/watch?v=wf-BqAjZb8M

probably. Or otherwise maybe

Transforming Code into Beautiful, Idiomatic Python
https://www.youtube.com/watch?v=OSGv2VnC0go

Both very interesting, though I enjoyed the first one more.


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: OT I before E [was Re: Lies in education [was Re: The "loop and a half"]]

[Roel Schroeven]

Thomas Jollans schreef op 5/10/2017 10:30:

On 2017-10-05 06:47, Steve D'Aprano wrote:

On Thu, 5 Oct 2017 02:54 pm, Chris Angelico wrote:

(There are exceptions even to the longer form of the rule, but only a
handful. English isn't a tidy language.)

Even with the longer version of the rule, there are so few applicable cases,
and enough difficulty in applying the rule correctly, that the rule is not
worth the breath it takes to say it.


Maybe we should just all switch to Dutch on this list. Might be easier.
Certainly more consistent.


Although that way may not be obvious at first unless you're Dutch. (or 
Flemish)


There are a lot of exceptions, weird rules and other difficulties in 
Dutch as well; we native speakers just don't notice them that much.



--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Does anyone know ni?

[Roel Schroeven]

I'm having a look at py-iso8211 from 
https://sourceforge.net/projects/py-iso8211/ to see if I can get it to 
work without too much work. It uses a module 'ni', for example in 
__init__.py:



"""
...
"""

# Make the above more easily available - if you do:
#
# import ni
# ni.ni() # (currently needed (in Python 1.3) to start "ni" up)
# import iso8211
# print  iso8211.Intro
#
# then you should get the sensible result...

Intro   = __doc__


Is it something that was needed in very old Python versions to get 
access to the docstring?


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Does anyone know ni?

[Roel Schroeven]

Ian Kelly schreef op 6/02/2018 21:43:

It was used for package support and is no longer needed from Python
1.5. http://legacy.python.org/doc/essays/packages.html


Thanks!

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

How to work on a package

[Roel Schroeven]

I'm fairly comfortable writing Python code, but I only have experience 
writing scripts with perhaps a few supporting modules. Now I want to 
start writing a package, and I'm feeling a bit helpless: I'm not sure 
how to organize my work.


In my way of thinking, I would have a working tree for the package (or 
even more than one), and also an installed version (once version 0.1 or 
so is ready).


For example, let's say I'm working on luaparser 
(https://github.com/boolangery/py-lua-parser). There are tests in 
directory luaparser/tests, and I want to execute those tests. So I 
execute, for example:


$ python3 -m unittest test_ast.py

But that doesn't work:

E
==
ERROR: test_ast (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_ast
Traceback (most recent call last):
  File "/usr/lib/python3.5/unittest/loader.py", line 153, in 
loadTestsFromName

module = __import__(module_name)
  File "/home/roel/temp/py-lua-parser/luaparser/tests/test_ast.py", 
line 1, in 

from luaparser.utils  import tests
ImportError: No module named 'luaparser'


The test tries to import the global luaparser package (beause they use 
absoluate imports, which is the recommended way if I understand 
correctly), but that's not what I want: I want to test the local version 
in my working tree.


I guess I could use something like

$ PYTHONPATH=../.. python3 -m unittest test_ast.py

but it feels like there should be a better way than manually specifying 
the module search path.


How do people usually do this? Is there maybe a guide that explains the 
practical side of writing packages?


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to work on a package

[Roel Schroeven]

dieter schreef op 7/02/2018 8:21:

Likely, there are many ways to execute tests for your package.



I am using "setuptools" for packaging (an extension
of Python's standard "disutils"). Its "setup.py" supports the "test"
command. This means, properly set up, I can run tests
with "python setup.py test".


That can solve the testing issue, I guess, even though it feels weird to 
me that the most straightforward way doesn't work.


But testing is not the only issue. Often I'd like to start the Python 
interpreter to load one of the modules in the package to try some things 
out, or write a little script to do the same. These things are very 
natural to me when writing Python code, so it seems very strange to me 
that there's no easy way when working on a packages.


Don't other people do that?

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to work on a package

[Roel Schroeven]

Rob Gaddi schreef op 7/02/2018 22:24:

On 02/07/2018 12:34 PM, Roel Schroeven wrote:

dieter schreef op 7/02/2018 8:21:

Likely, there are many ways to execute tests for your package.
I am using "setuptools" for packaging (an extension
of Python's standard "disutils"). Its "setup.py" supports the "test"
command. This means, properly set up, I can run tests
with "python setup.py test".
That can solve the testing issue, I guess, even though it feels weird to 
me that the most straightforward way doesn't work.


But testing is not the only issue. Often I'd like to start the Python 
interpreter to load one of the modules in the package to try some things 
out, or write a little script to do the same. These things are very 
natural to me when writing Python code, so it seems very strange to me 
that there's no easy way when working on a packages.


Don't other people do that?



The state of Python packaging is... unfortunate. Improving, due to huge 
amounts of work by some very dedicated people, but still unfortunate.


When I'm working on a module, the trick is to write a setup.py (using 
setuptools) from the very get-go.  Before I write a single line of code, 
I've got a setup.py and the directory framework.


Then you install the package using pip -e (or in practice --user -e). 
That's the missing piece.  That way you can import your module from the 
interpreter, because it's now on the path, but its physical location is 
right there where you left it, complete with your VCS metadata and etc.


That seems like a workable solution. I'll try that out.
Thanks!


Best regards,
Roel

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Bitstream -- Binary Data for Humans

[Roel Schroeven]

Sébastien Boisgérault schreef op 5/03/2018 20:05:

I have released bitstream, a Python library to manage binary data (at the byte 
or bit level),

> hopefully without the pain that this kind of thing usually entails :)


If you have struggled with this topic in the past, please take a look at the 
documentation

> (http://boisgera.github.io/bitstream/) and tell me what you think.

Hi Sébastien,

At work I have some Python code to decode AIS[1] messages, for which I 
created my own code for handling binary data. It works, but is pretty 
slow. Not surprising, since handling data at the bit level is not 
exactly Python's strength. If I find the time, I'll try to replace my 
code with your bitstream and see if it does what I need it to do, and if 
it's any faster.


If/when I actually get around to it, I'll keep you informed.

[1] https://en.wikipedia.org/wiki/Automatic_identification_system


Best regards,
Roel

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: tail

[Roel Schroeven]

dn schreef op 24/04/2022 om 0:04:

Disagreeing with @Chris in the sense that I use tail very frequently,
and usually in the context of server logs - but I'm talking about the
Linux implementation, not Python code!
If I understand Marco correctly, what he want is to read the lines from 
bottom to top, i.e. tac instead of tail, despite his subject.

I use tail very frequently too, but tac is something I almost never use.

--
"Peace cannot be kept by force. It can only be achieved through understanding."
-- Albert Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace characters in a string?

[Roel Schroeven]

Op 8/06/2022 om 11:25 schreef Dave:

Hi,

I misunderstood how it worked, basically I’ve added this function:

def filterCommonCharacters(theString):

 myNewString = theString.replace("\u2019", "'")

 return myNewString
Which returns a new string replacing the common characters.

This can easily be extended to include other characters as and when they come 
up by adding a line as so:

 myNewString = theString.replace("\u2014", “]”  #just an example

Which is what I was trying to achieve.
When you have multiple replacements to do, there's an alternative for 
multiple replace calls: you can use theString.translate() with a 
translation map (which you can make yourself or make with 
str.maketrans()) to do all the replacements at once. Example


    # Make a map that translates every character from the first string 
to the

    # corresponding character in the second string
    translation_map = str.maketrans("\u2019\u2014", "']")

    # All the replacements in one go
    myNewString = theString.translate(translation_map)

See:
    - https://docs.python.org/3.10/library/stdtypes.html#str.maketrans
    - https://docs.python.org/3.10/library/stdtypes.html#str.translate

--

"There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened."
-- Douglas Adams, The Restaurant at the End of the Universe

--
https://mail.python.org/mailman/listinfo/python-list

Re: mapLast, mapFirst, and just general iterator questions

[Roel Schroeven]

Chris Angelico schreef op 14/06/2022 om 20:47:

> def main():
> for each in (iterEmpty, iter1, iter2, iterMany):
> baseIterator = each()
> chopFirst = mapFirst(baseIterator, lambda x: x[1:-1])
> andCapLast = mapLast(chopFirst, lambda x: x.upper())
> print(repr(" ".join(andCapLast)))

Don't bother with a main() function unless you actually need to be
able to use it as a function. Most of the time, it's simplest to just
have the code you want, right there in the file. :) Python isn't C or
Java, and code doesn't have to get wrapped up in functions in order to
exist.
Not (necessarily) a main function, but these days the general 
recommendation seems to be to use the "if __name__ == '__main__':" 
construct, so that the file can be used as a module as well as as a 
script. Even for short simple things that can be helpful when doing 
things like running tests or extracting docstrings.


--
"This planet has - or rather had - a problem, which was this: most of the
people living on it were unhappy for pretty much of the time. Many solutions
were suggested for this problem, but most of these were largely concerned with
the movement of small green pieces of paper, which was odd because on the whole
it wasn't the small green pieces of paper that were unhappy."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Roel Schroeven]

Paulo da Silva schreef op 20/06/2022 om 21:01:

Às 18:19 de 20/06/22, Stefan Ram escreveu:
>The same personality traits that make people react
>to troll postings might make them spread unconfirmed
>ideas about the meaning of "C" in "CPython".
> 
>The /core/ of CPython is written in C.
> 
>CPython is the /canonical/ implementation of Python.
> 
>The "C" in "CPython" stands for C.
> 
> 


Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".


Counterpoint: https://wiki.python.org/moin/SummerOfCode/2017/python-core 
says "The reference implementation of Python is CPython, so named 
because it's written in C." Even in the absence of other evidence I'd 
much rather trust a python.org page than a www.analyticsinsight.net page 
on the subject of Python implementations.


But there's more.

Apart from www.analyticsinsight.net I can't find any website that 
mentions "Core Python" as a Python implementation. That's a strong 
indication that www.analyticsinsight.net is wrong on that point. Frankly 
that website seems very low quality in general. In that same article 
they say:


"CPython is a descendant of Pyscript built on Pyodide, a port of 
CPython, or a Python distribution for the browser and Node.js that is 
based on Webassembly and Emscripten."


CPython is definitely not a descendant of Pyscript! Looks like someone 
found something (semi-) interesting and tried to write something 
insightful about it, but without really understanding any of it. Other 
articles don't seem to be any better.


So we have an untrustworthy site that's the only one to claim that 
CPython is short for Core Python, and we have an official site that says 
CPython is so named because it's written in C. Hm, which one to believe?


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sre_constants MODIFIED CLASS - ERROR

[Roel Schroeven]

Op 24/06/2022 om 10:43 schreef נתי שטרן:

what's the problem with the code
Have you seen the replies from Mats Wichmann and Chris Angelico, who 
helpfully pointed out some problems with your code and possible 
improvements? Please take those into account instead of asking the same 
thing over and over.


--
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à
ajouter, mais quand il n'y a plus rien à retrancher."
"Perfectie is niet bereikt als er niets meer toe te voegen is, maar als er
niets meer weg te nemen is."
-- Antoine de Saint-Exupéry

--
https://mail.python.org/mailman/listinfo/python-list

Re: argparse modify

[Roel Schroeven]

Op 24/06/2022 om 0:32 schreef Dennis Lee Bieber:

On Thu, 23 Jun 2022 18:57:31 +0200, "Dieter Maurer"
declaimed the following:

>???  wrote at 2022-6-23 15:31 +0300:
>>how to solve this (argparse)

>>MAXREPEAT = _NamedIntConstant(32,name=str(32))
>>TypeError: 'name' is an invalid keyword argument for int()
>
>This does not look like an `argparse` problem:
>the traceback comes from `oracle/RTR.py`.

And the listed code looks quite suspicious to me...

>> class _NamedIntConstant(int):
>> def __init__(cls, value):
>> self = super(_NamedIntConstant, cls).__init__(cls, value)
>> self.name = name
>> return self

There does not appear to be any provision for keyword arguments at all.
The only use of "name" is to an undefined object.

The code seems to be a copy of Lib/re/_constants.py (or 
Lib/sre_constants.py before commit 
1be3260a90f16aae334d993aecf7b70426f98013), but in _constants.py that 
class uses __new__ instead of __init__:


    class _NamedIntConstant(int):
    def __new__(cls, value, name):
    self = super(_NamedIntConstant, cls).__new__(cls, value)
    self.name = name
    return self

    def __repr__(self):
    return self.name

    __reduce__ = None

(unless still older versions did use __init__)

It's used there as a kind of enum. I guess that code was originally 
written before Python had enum.Enum. _makecodes() uses it so create 
named int objects from its arguments, with automatically generated 
consecutive int values, places them in the global namespace (feels like 
a code smell to me) and also returns them.


    def _makecodes(*names):
    items = [_NamedIntConstant(i, name) for i, name in 
enumerate(names)]

    globals().update({item.name: item for item in items})
    return items

    # operators
    OPCODES = _makecodes(
    # failure=0 success=1 (just because it looks better that way :-)
    'FAILURE', 'SUCCESS',

    'ANY', 'ANY_ALL',
    'ASSERT', 'ASSERT_NOT',
    'AT',
    # ...
    )

נתי שטרן, are you trying to use that semi-enum functionality? Most 
likely you're better of using enum.Enum instead.


--
"You can fool some of the people all the time, and all of the people some
of the time, but you cannot fool all of the people all of the time."
-- Abraham Lincoln
"You can fool too many of the people too much of the time."
-- James Thurber
--
https://mail.python.org/mailman/listinfo/python-list

Re: sre_constants MODIFIED CLASS - ERROR

[Roel Schroeven]

Op 24/06/2022 om 11:10 schreef נתי שטרן:

OK. I lifted the full library to a HUGE python file that was saved on LAN
in MY WORK
Do I need to lift many other  libraries to the file?
I glad to any answer
Answer this: what is it that your _actually_ trying to do? What is the 
ultimate goal of all that copying and changing? Cause there is almost 
always a better and easier way.


--
"You can fool some of the people all the time, and all of the people some
of the time, but you cannot fool all of the people all of the time."
-- Abraham Lincoln
"You can fool too many of the people too much of the time."
-- James Thurber

--
https://mail.python.org/mailman/listinfo/python-list

Re: sre_constants MODIFIED CLASS - ERROR

[Roel Schroeven]

Op 24/06/2022 om 14:14 schreef נתי שטרן:
My TARGET  is to bind many code libraries to one Huge code file that 
works optimally and do optimizations if needed.
In this file have code of huge part of falconpy, ALL code of re, 
argparse, are and many other code libraries
Don't do that. Sorry, it's just as simple as that. Don't do that. All 
those modules are not designed to put together like that, all their 
namespaces merged together. Don't do it.
Even if you could eventually get it to work, it would not be any more 
optimal.


If you need more performance, look into things like Pypy or Cython.

--
"Experience is that marvelous thing that enables you to recognize a
mistake when you make it again."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: REPL with multiple function definitions

[Roel Schroeven]

Rob Cliffe via Python-list schreef op 27/06/2022 om 0:14:

This 2-line program

def f(): pass
def g(): pass

runs silently (no Exception).  But:

23:07:02 c:\>python
Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
  >>> def f(): pass
... def g(): pass
    File "", line 2
      def g(): pass
      ^
SyntaxError: invalid syntax
  >>>

Is there a good reason for this?
The REPL requires an extra empty line to indicate the end of multi-line 
constructs. You can see it by the prompt: as long as the REPL prints 
'... '  as prompt, that means it puts everything you type in the same 
multi-line construct. To enter a new multi-line construct (such as a 
function definition, a for-loop, an if-statement, ...), press enter 
directly at the prompt; the REPL should than use '>>> ' as the prompt again.


(Alternatives like IPython (https://ipython.readthedocs.io/en/stable/) 
are a bit more loose regarding how to enter multi-line constructs)


--
"Iceland is the place you go to remind yourself that planet Earth is a
machine... and that all organic life that has ever existed amounts to a greasy
film that has survived on the exterior of that machine thanks to furious
improvisation."
-- Sam Hughes, Ra

--
https://mail.python.org/mailman/listinfo/python-list

Re: calculate diff between dates

[Roel Schroeven]

Op 12/07/2022 om 14:37 schreef נתי שטרן:

I glad for any help

http://www.catb.org/~esr/faqs/smart-questions.html

--
"Binnen een begrensde ruimte ligt een kritiek punt, waar voorbij de vrijheid
afneemt naarmate het aantal individuen stijgt. Dit gaat evenzeer op voor mensen
in de begrensde ruimte van een planetair ecosysteem, als voor de gasmoleculen
in een hermetisch gesloten vat. Bij mensen is het niet de vraag hoeveel er
maximaal in leven kunnen blijven in het systeem, maar wat voor soort bestaan
mogelijk is voor diegenen die in leven blijven.
  -- Pardot Kynes, eerste planetoloog van Arrakis"
  -- Frank Herbert, Duin

--
https://mail.python.org/mailman/listinfo/python-list

Re: [Neuroimaging] what's the problem??????

[Roel Schroeven]

Dennis Lee Bieber schreef op 15/07/2022 om 19:11:

...
is, itself, returning a dictionary on which .values() can be applied. In
that case, the list() call is likely redundant as .values() already
returned a list (hmmm, is list(some_list) a no-op, or does it wrap
some_list into another list -- in the latter case, the indexing will fail
as there is only one element to access)


list(some_list) returns a copy of some_list, a shallow copy to be precise.

>>> a = [ [1, 2, 3], [4, 5, 6] ]
>>> b = list(a)

Both lists are equal:
>>> a == b
True

But not identical:
>>> a is b
False

The sublists are identical though:
>>> a[0] is b[0]
True
>>> a[1] is b[1]
True

--

"I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is
   just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new
   and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of 
things."
-- Douglas Adams, The Salmon of Doubt

--
https://mail.python.org/mailman/listinfo/python-list

Re: list indices must be integers or slices, not str

[Roel Schroeven]

Frank Millman schreef op 20/07/2022 om 13:04:

>> On Wed, 20 Jul 2022 at 18:34, Frank Millman  wrote:
>>>   >>>
>>>   >>> x = list(range(10))
>>>   >>>
>>>   >>> '{x[1]}'.format(**vars())
>>> '1'
>>>   >>>
>>>   >>> '{x[-1]}'.format(**vars())
>>> Traceback (most recent call last):
>>>     File "", line 1, in 
>>> TypeError: list indices must be integers or slices, not str
>>>   >>>
>>>
>>> Can anyone explain this error? It seems that a negative index is deemed
>>> to be a string in this case.
>>>
>>
>> [...]
>>

"It seems to only want integer constants. x[2+2] and x[k] where k=2
don't work either.

I think the preferred style these days is f'{x[-1]}' which works."

Unfortunately the 'f' option does not work for me in this case, as I am
using a string object, not a string literal.

I've always found a bit dirty to pass indiscriminate symbol tables like 
the one from globals() or vars() or vars(some_object) to a formatting 
method, leaving the formatting string free to access any of it. I prefer 
to make things more explicit. Can't you make a dict with a selection of 
things you possible want to format?


In a sense I think you're looking for a more complete templating 
solution than what Python's formatting mechanisms are designed for. 
Maybe you should consider a full template engine, like Jinja?


--
"There is no cause so noble that it will not attract fuggheads."
-- Larry Niven

--
https://mail.python.org/mailman/listinfo/python-list

Re: random.SystemRandom().randint() inefficient

[Roel Schroeven]

Cecil Westerhof via Python-list schreef op 27/07/2022 om 17:43:

"Michael F. Stemper"  writes:

> This is orthogonal to your question, but might be of some use to you:
>
> The combination of using len(to_try) as an argument to randint() and
> saving the output to a variable named "index" suggests that you might
> be setting up to select a random element from to_try, as in:
>   something = to_try[index]
>
> If that is the case, you might want to consider using random.choice() instead:
>
>   >>> from random import choice
>   >>> to_try = [2,3,5,7,11,13,"seventeen",19]
>   >>> choice(to_try)
>   2
>   >>> choice(to_try)
>   'seventeen'
>   >>> choice(to_try)
>   13
>   >>> choice(to_try)
>   5
>   >>>

Yes, I try to select a random element, but it has also to be removed,
because an element should not be used more as once.
This is the code I use:
 # index = randbelow(len(to_try))
 index = randrange(len(to_try))
 found = permutation[to_try.pop(index)]
Do you know in advance how many items you'll need, or maybe an upper 
limit on the amount? In that case it might be more efficient to use 
random.sample(to_try, k=nr_items_needed).


--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: Simple TCP proxy

[Roel Schroeven]

Morten W. Petersen schreef op 29/07/2022 om 22:59:

OK, sounds like sunshine is getting the best of you.

It has to be said: that is uncalled for.

Chris gave you good advice, with the best of intentions. Sometimes we 
don't like good advice if it says something we don't like, but that's no 
reason to take it off on the messenger.


--
"Iceland is the place you go to remind yourself that planet Earth is a
machine... and that all organic life that has ever existed amounts to a greasy
film that has survived on the exterior of that machine thanks to furious
improvisation."
-- Sam Hughes, Ra

--
https://mail.python.org/mailman/listinfo/python-list

Re: What can I do about this?

[Roel Schroeven]

Op 29/08/2022 om 2:55 schreef gene heskett:

On 8/28/22 19:39, Peter J. Holzer wrote:

On 2022-08-28 18:40:17 -0400, gene heskett wrote:
Persuant to my claim the py3.10 is busted, here is a sample. This is 
me,

trying to make
pronterface, inside a venv: When the package manager version will 
only run

the gui-less "pronsole"
but nothing else from that all python kit runs as it should or at all.
 From the package-managers install in /usr/share/doc/printrun-common/ I
copied requirements.txt
into the venv, and ran this command line:

gene@rock64:~/venv$ pip3 install -r requirements.txt

You are almost certainly *not* in a venv here. First, your prompt
doesn't show the name of the venv,
I've created that several times, as octoprint won''t run without it 
either.
I found a way to autostart it on reboots and octoprint seems happy 
with it
I agree with Peter: it doesn't look as if you are invoking the pip3 in 
the venv. Just making the venv-directory the current directory doesn't 
activate it.


As a diagnostic, ask the OS which pip3 is actually used:

$ type -a pip3

Does that show the pip3 installed in the venv? Or the system-wide one? 
If it's not the pip3 in the venv, well, then that's the problem (or at 
least part of the problem). Solution: first check whether the venv 
really contains 'pip3' (as opposed to eg. just 'pip'): list the contents 
of the bin subdirectory of the venv. If not, use 'pip' or whatever 
instead. Then to make sure you use the one in the venv, either activate 
the venv or explicitly specify the path when invoking pip/pip3 (and 
likewise for python/python3).


So either (assuming you're using bash):

$ source {path_to_venv}/bin/pip3  # activate the venv
$ type -a pip3  # check whether now the correct pip3 is used
$ pip3 install -r requirements.txt  # finally invoke pip3

or:

$ {path_to_venv}/bin/pip3 install -r requirements.txt

Activating the venv is easier if you're going to use multiple commands 
in the venv. Note that activating the venv only has effect on the 
current shell; other shells are unaffected, and when you close the 
current shell the venv is not activated anymore.
Explicitly using the path is easier for one-off calls, or in things like 
crontab.


--
"There is no cause so noble that it will not attract fuggheads."
-- Larry Niven

--
https://mail.python.org/mailman/listinfo/python-list

Re: What can I do about this?

[Roel Schroeven]

Mark Bourne schreef op 29/08/2022 om 13:02:

Roel Schroeven wrote:
> $ source {path_to_venv}/bin/pip3  # activate the venv

I think this first line should probably be:

$ source {path_to_venv}/bin/activate  # activate the venv

i.e. with `activate` rather than `pip3`?


Oops, yes, of course. Thank you for the correction!

--

"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: What to use for finding as many syntax errors as possible.

[Roel Schroeven]

Op 10/10/2022 om 19:08 schreef Robert Latest via Python-list:

Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible 
> in a python file.


I'm puzzled as to when such a tool would be needed. How many syntax errors can
you realistically put into a single Python file before compiling it for the
first time?
I've been following the discussion from a distance and the whole time 
I've been wondering the same thing. Especially when you have unit tests, 
as Antoon said he has, I can't really imagine a situation where you add 
so much code in one go without running it that you introduce a painful 
amount of syntax errors.


My solution would be to use a modern IDE with a linter, possibly with 
style warnings disabled, which will flag syntax errors as soon as you 
type them. Possibly combined with a TDD-style tactic which also prevents 
large amounts of errors (any errors) to build up. But I have the 
impression that any of those doesn't fit in Antoon's workflow.


--
"Peace cannot be kept by force. It can only be achieved through understanding."
-- Albert Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beautiful Soup - close tags more promptly?

[Roel Schroeven]

Op 24/10/2022 om 4:29 schreef Chris Angelico:

Parsing ancient HTML files is something Beautiful Soup is normally
great at. But I've run into a small problem, caused by this sort of
sloppy HTML:

from bs4 import BeautifulSoup
# See: https://gsarchive.net/gilbert/plays/princess/tennyson/tenniv.htm
blob = b"""

'THERE sinks the nebulous star we call the Sun,
If that hypothesis of theirs be sound,'
Said Ida;' let us down and rest:' and we
Down from the lean and wrinkled precipices,
By every coppice-feather'd chasm and cleft,
Dropt thro' the ambrosial gloom to where below
No bigger than a glow-worm shone the tent
Lamp-lit from the inner. Once she lean'd on me,
Descending; once or twice she lent her hand,
And blissful palpitations in the blood,
Stirring a sudden transport rose and fell.

"""
soup = BeautifulSoup(blob, "html.parser")
print(soup)


On this small snippet, it works acceptably, but puts a large number of
 tags immediately before the . On the original file (see
link if you want to try it), this blows right through the default
recursion limit, due to the crazy number of "nested" list items.

Is there a way to tell BS4 on parse that these  elements end at
the next , rather than waiting for the final ? This would
make tidier output, and also eliminate most of the recursion levels.

Using html5lib (install package html5lib) instead of html.parser seems 
to do the trick: it inserts  right before the next , and one 
before the closing  . On my system the same happens when I don't 
specify a parser, but IIRC that's a bit fragile because other systems 
can choose different parsers of you don't explicity specify one.


--
"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beautiful Soup - close tags more promptly?

[Roel Schroeven]

Op 24/10/2022 om 9:42 schreef Roel Schroeven:
Using html5lib (install package html5lib) instead of html.parser seems 
to do the trick: it inserts  right before the next , and one 
before the closing  . On my system the same happens when I don't 
specify a parser, but IIRC that's a bit fragile because other systems 
can choose different parsers of you don't explicity specify one.


Just now I noticed: when I don't specify a parser, BeautifulSoup emits a 
warning with the parser it selected. In one of my venv's it's html5lib, 
in another it's lxml. Both seem to get a correct result.


--

"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beautiful Soup - close tags more promptly?

[Roel Schroeven]

(Oops, accidentally only sent to Chris instead of to the list)

Op 24/10/2022 om 10:02 schreef Chris Angelico:
On Mon, 24 Oct 2022 at 18:43, Roel Schroeven  
wrote:

> Using html5lib (install package html5lib) instead of html.parser seems
> to do the trick: it inserts  right before the next , and one
> before the closing  . On my system the same happens when I don't
> specify a parser, but IIRC that's a bit fragile because other systems
> can choose different parsers of you don't explicity specify one.
>

Ah, cool. Thanks. I'm not entirely sure of the various advantages and
disadvantages of the different parsers; is there a tabulation
anywhere, or at least a list of recommendations on choosing a suitable
parser?
There's a bit of information here: 
https://beautiful-soup-4.readthedocs.io/en/latest/#installing-a-parser

Not much but maybe it can be helpful.

I'm dealing with a HUGE mess of different coding standards, all the
way from 1990s-level stuff (images for indentation, tables for
formatting, and ) up through HTML4 (a good few
of the pages have at least some  tags and declare their
encodings, mostly ISO-8859-1 or similar), to fairly modern HTML5.
There's even a couple of pages that use frames - yes, the old style
with a  block in case the browser can't handle it. I went
with html.parser on the expectation that it'd give the best "across
all standards" results, but I'll give html5lib a try and see if it
does better.

Would rather not try to use different parsers for different files, but
if necessary, I'll figure something out.

(For reference, this is roughly 9000 HTML files that have to be
parsed. Doing things by hand is basically not an option.)

I'd give lxml a try too. Maybe try to preprocess the HTML using 
html-tidy (https://www.html-tidy.org/), that might actually do a pretty 
good job of getting rid of all kinds of historical inconsistencies.
Somehow checking if any solution works for thousands of input files will 
always be a pain, I'm afraid.


--
"I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is
   just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new
   and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of 
things."
-- Douglas Adams, The Salmon of Doubt

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beautiful Soup - close tags more promptly?

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 24/10/2022 om 19:01:

On 2022-10-24, Chris Angelico  wrote:
> On Tue, 25 Oct 2022 at 02:45, Jon Ribbens via Python-list 
  wrote:
>> Adding in the omitted , , , , and 
>> would make no difference and there's no particular reason to recommend
>> doing so as far as I'm aware.
>
> And yet most people do it. Why?

They agree with Tim Peters that "Explicit is better than implicit",
I suppose? ;-)


I don't write all that much HTML, but when I do, it include those tags 
largely for that reason indeed. We don't write HTML just for the 
browser, we also write it for the web developer. And I think it's easier 
for the web developer when the different sections are clearly 
distinguished, and what better way to do it than use their tags.



> More importantly: Would you omit all the  closing tags you can, or
> would you include them?

It would depend on how much content was inside them I guess.
Something like:

   
 First item
 Second item
 Third item
   

is very easy to understand, but if each item was many lines long then it
may be less confusing to explicitly close - not least for indentation
purposes.
I mostly include closing tags, if for no other reason than that I have 
the impression that editors generally work better (i.e. get things like 
indentation and syntax highlighting right) that way.


--
"Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’à
la mort pour que vous ayez le droit de le dire."
-- Attribué à Voltaire
"I disapprove of what you say, but I will defend to the death your right to
say it."
-- Attributed to Voltaire
"Ik ben het niet eens met wat je zegt, maar ik zal je recht om het te zeggen
tot de dood toe verdedigen"
-- Toegeschreven aan Voltaire
--
https://mail.python.org/mailman/listinfo/python-list

Re: Operator: inappropriate wording?

[Roel Schroeven]

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 sides of the assignment operator (p. 86)
- The second half of the list, the augmented assignment operators, serve 
lexically as delimiters, but also perform an operation (p. 15)



Do you agree with this use of the term "operator"?
It's a bit fuzzy, I guess. Comma, =, +=, *= etc. are in section 2.6 
"Delimiters" and not in section 2.5 "Operators" of The Python Language 
Reference, which would seem to imply that those are not operators. But 
the text in section 2.6 then says "The second half of the list, the 
augmented assignment _operators_, serve lexically as delimiters, but 
also perform an operation.", so at least the augmented assignment 
operators are seen as operators despite not being in the Operators section.



Because there is no such "comma operator" in Python as explained by the 
official FAQ: 
https://docs.python.org/3/faq/programming.html#what-s-up-with-the-comma-operator-s-precedence

That does seem to contradict the text in the language reference.

And, =, += and the like are not operators since (a=b), (a+=b), etc have no 
value. There is no assignment operator instead there exists an assignment 
statement. The only assignment operator I can figure out is the walrus operator.
I think that's a good point too. The language reference calls those 
things 'delimiters', which doesn't feel like a good description either 
for many of them. I find it weird to think of =, *+, +=as a delimiter. 
Maybe that's why those things are called operators anyway instead of 
delimiters in many places? Things like "Note: If the object is a class 
instance and the attribute reference occurs on both sides of the 
assignment _delimiter_" sound a bit weird I feel, even though completely 
correct according to the language reference.


So yeah I think you have a point that the terminology regarding those 
tokens is not very consistent at the least.


--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

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

[Roel Schroeven]

Op 14/11/2022 om 4:23 schreef 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


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.


It's not invalid. In the REPL for example, it does something useful:

>>> x = [1, 2, 3]
>>> x.clear


Others have shown instances where writing a method or function without 
calling it are useful in a script too.


There are languages that handle this differently. Ruby, for example, 
calls the function/method even when you don't write the parens, if I'm 
not mistaken. Personally I don't like that; I much prefer Python's 
explicitness in making the difference between the value of a function 
and calling that function. Still, there's something to be said for 
warnings. I agree with others that such warnings are more the job for a 
linter than for the language.


FWIW I've been bitten by this in C++ once. I wanted to write something like

if (some_condition())
    foo();

But I forgot the parens after some_condition, so C++ evaluated the 
function pointer (which was non-NULL so evaluated is true in a boolean 
context) instead of the return value, and therefore foo() got called 
unconditionally.


--

"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Passing information between modules

[Roel Schroeven]

Stefan Ram schreef op 20/11/2022 om 11:39:

   The idea is about parameterizing the behavior of a module.
   For example, the module "M" may contain functions that contain
   "input.read()" to get input and "output.write()" to write
   output. Then one would write code like (the following is
   not correct Python code, just pseudo code assuming a possible
   extended Python where one can assigned to a module before
   it's loaded):

import sys

M.input = sys.stdin
M.output = sys.stdout
import M

   . So now M would use sys.stdin for input and sys.stdout
   for output.
I feel this is a bad idea. This uses global state for customizing local 
behavior. Yes, maybe you want to customize behavior in one of your 
modules, or even only in some functions, or maybe in several or even all 
of your modules. But by changing module "M", you're changing it for 
*every* user of it, even for standard library modules or third party 
packages. You can't customize it in different ways in different parts of 
your code. And it's a kind of spooky action at a distance: the behavior 
of a module gets changed by another, possibly completely unrelated, 
module. This has the potential to grossly violate the principle of least 
surprise.

   If someone else would ask this, I'd tell him to use a class:

import MM
import sys

M = MM.moduleclass( input=sys.stdin, output=sys.stdout )
That is a *much* better solution, and I would even say it's the only 
acceptable solution.

   , but this is another layer of indirection, so it's a bit
   more complicated than the direct approach of parameterizing
   a module.

I'm not even sure it's more complicated. It's more explicit, which I like.

You could have a hybrid approach, like what the random module does. The 
functions in the random module are actually methods of a global hidden 
instance of class random.Random; if you want random generators with 
separate states you can create your own instance(s) of random.Random, or 
of random.SystemRandom.


--
"You can fool some of the people all the time, and all of the people some
of the time, but you cannot fool all of the people all of the time."
-- Abraham Lincoln
"You can fool too many of the people too much of the time."
-- James Thurber

--
https://mail.python.org/mailman/listinfo/python-list

Re: Passing information between modules

[Roel Schroeven]

Thomas Passin schreef op 20/11/2022 om 20:33:

https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35413
https://devblogs.microsoft.com/oldnewthing/20101125-00/?p=12203

Now that I think about it, The Old New Thing is also where I got the 
global vs local thing: "Don’t use global state to manage a local 
problem", https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19873


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to convert a raw string r'\xdd' to '\xdd' more gracefully?

[Roel Schroeven]

Op 7/12/2022 om 4:37 schreef Jach Feng:

MRAB 在 2022年12月7日 星期三上午11:04:43 [UTC+8] 的信中寫道：
> On 2022-12-07 02:23, Jach Feng wrote: 
> > s0 = r'\x0a' 
> > At this moment it was done by 
> > 
> > def to1byte(matchobj): 
> > return chr(int('0x' + matchobj.group(1), 16)) 
> > s1 = re.sub(r'\\x([0-9a-fA-F]{2})', to1byte, s0) 
> > 
> > But, is it that difficult on doing this simple thing? 
> >
> You could try this: 
> 
> >>> s0 = r'\x0a' 
> >>> ast.literal_eval('"%s"' % s0) 
> '\n'

Not work in my system:-(

Python 3.8.8 (tags/v3.8.8:024d805, Feb 19 2021, 13:08:11) [MSC v.1928 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> s0 = r'\x0a'
>>> import ast
>>> ast.literal_eval("%s" % s0)
Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Users\Jach\AppData\Local\Programs\Python\Python38-32\lib\ast.py", 
line 59, in literal_eval
 node_or_string = parse(node_or_string, mode='eval')
   File "C:\Users\Jach\AppData\Local\Programs\Python\Python38-32\lib\ast.py", 
line 47, in parse
 return compile(source, filename, mode, flags,
   File "", line 1
 \x0a
^
SyntaxError: unexpected character after line continuation character
You missed a pair of quotes. They are easily overlooked but very 
important. The point is to wrap your string in another pair of quotes so 
it becomes a valid Python string literal in a Python string which can 
then be passed to ast.literal_eval(). Works for me:


In [7]: s0 = r'\x0a'

In [8]: import ast

In [9]: ast.literal_eval('"%s"' % s0)
Out[9]: '\n'

--
"Experience is that marvelous thing that enables you to recognize a
mistake when you make it again."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Op 13/12/2022 om 1:41 schreef John K. Parejko:

Asking here before I file an improvement request issue on the python GitHub:

sqlite has a known misfeature with double-quoted strings, whereby they will be 
interpreted as string literals if they don’t match a valid identifier [1]. The 
note in the sqlite docs describe a way to disable this misfeature at compile 
time or by calling an `sqlite3_db_config` C-function, but I don’t see any way 
to do that in the python sqlite library [2].

Am I missing a way to manage this setting, or is it not available within 
python? This would be very useful to enable, so that python’s sqlite library 
will treat queries more like standard sql, instead of this particular version 
of MySQL. I was just burned by this, where some tests I’d written against an 
sqlite database did not fail in the way that they “should” have, because of 
this double-quoted string issue.

It doesn’t look like `sqlite3_db_config` is used within the python sqlite3 
codebase at all, so this might not be a trivial change? I only see two 
references to it in the cpython github.

Like Lars Liedtke this is not an exact answer to your question, but you 
can side-step the issue by using parametrized queries, i.e. instead of


    cur.execute('SELECT name, location FROM persons WHERE name = "John 
Doe"')


do

    cur.execute('SELECT name, location FROM persons WHERE name = ?', 
('John Doe',))



--
"Life ain't no fairy tale
Just give me another ale
And I'll drink to Rock 'n Roll"
-- Barkeep (The Scabs)

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Op 13/12/2022 om 14:23 schreef Thomas Passin:

On 12/13/2022 4:09 AM, Chris Angelico wrote:
On Tue, 13 Dec 2022 at 19:52, Roel Schroeven  
wrote:

Like Lars Liedtke this is not an exact answer to your question, but you
can side-step the issue by using parametrized queries, i.e. instead of

  cur.execute('SELECT name, location FROM persons WHERE name = 
"John

Doe"')

do

  cur.execute('SELECT name, location FROM persons WHERE name = ?',
('John Doe',))



That's the wrong behaviour though. According to the SQL standard, the
second query should be equivalent to this:

cur.execute("SELECT name, location FROM persons WHERE name = 'John 
Doe'")


What the OP wanted was like your first query, and proper DBMSes like
PostgreSQL will handle it accordingly. The question is how to get
SQLite3 to also do so.


From reading the SQLite3 documentation on this issue (not from 
personal experience), in fact the second form is actually what one 
wants, even if SQLite3 will usually handle the first form correctly.  
The rule is "Use single quotes for string values and double quotes for 
database names such as schema, table and column names; for backwards 
compatibility SQLite will accept double quotes for string values, but 
you may get a surprise if the string value looks like a database name."
What I missed at first is the case where you really want to use an 
identifier, not a string. Then you use double quotes, and would like to 
get an error ("unknown identifier" or something like that) in case of a 
typo, instead of the database engine silently presuming your 
wrongly-spelled identifier is a string. That case can't be solved with 
parametrized queries, and does really require the ability to enable more 
strict behavior.


+1 to expose the sqlite3_db_config() function, or maybe just a special 
case for this specific option.


--

"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Op 13/12/2022 om 15:15 schreef Roel Schroeven:


+1 to expose the sqlite3_db_config() function, or maybe just a special 
case for this specific option.


Actually I'm surprised SQLite doesn't have a PRAGMA command to customize 
this behavior. That would make it possible to customize from any client.


--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Stefan Ram schreef op 13/12/2022 om 8:42:

"John K. Parejko"  writes:
>I was just burned by this, where some tests I’d written
>against an sqlite database did not fail in the way that they
>“should” have, because of this double-quoted string issue.

   In standard SQL, double quotes denote identifiers that are
   allowed to contain special characters.
Or that are equal SQL keywords, which can be a reason to double-quote 
them. SQL engines sometimes add new keywords; explicitly marking string 
literals as string literals prevents future conflicts and confusion.


Perhaps it's a better idea to use [identifier] or `identifier` instead 
though (I just learned about those on 
https://sqlite.org/lang_keywords.html). Both are not standard SQL ([] is 
used in MS Access and SQL Server, `` is used in MySQL) but both work in 
SQLite. That should prevent any ambiguity and confusion, if it doesn't 
bother you too much that it's not standard SQL.


--
"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Chris Angelico schreef op 13/12/2022 om 20:01:

On Wed, 14 Dec 2022 at 06:00, Roel Schroeven  wrote:
>
> Stefan Ram schreef op 13/12/2022 om 8:42:
> > "John K. Parejko"  writes:
> > >I was just burned by this, where some tests I’d written
> > >against an sqlite database did not fail in the way that they
> > >“should” have, because of this double-quoted string issue.
> >
> >In standard SQL, double quotes denote identifiers that are
> >allowed to contain special characters.
> Or that are equal SQL keywords, which can be a reason to double-quote
> them. SQL engines sometimes add new keywords; explicitly marking string
> literals as string literals prevents future conflicts and confusion.
>
> Perhaps it's a better idea to use [identifier] or `identifier` instead
> though (I just learned about those on
> https://sqlite.org/lang_keywords.html). Both are not standard SQL ([] is
> used in MS Access and SQL Server, `` is used in MySQL) but both work in
> SQLite. That should prevent any ambiguity and confusion, if it doesn't
> bother you too much that it's not standard SQL.
>

Why not just use "identifier" which is standard SQL?


If you accidentally type [identifire] or `identifire`, SQLite will 
produce an unknown identifier error, alerting you immediately to your typo.
If you accidentally type "identifire", SQLite will silently treat it as 
a string literal instead of an identifier, causing more difficult to 
diagnose problems.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Roel Schroeven schreef op 13/12/2022 om 22:18:

Chris Angelico schreef op 13/12/2022 om 20:01:
> > Perhaps it's a better idea to use [identifier] or `identifier` instead
> > though (I just learned about those on
> > https://sqlite.org/lang_keywords.html). Both are not standard SQL ([] is
> > used in MS Access and SQL Server, `` is used in MySQL) but both work in
> > SQLite. That should prevent any ambiguity and confusion, if it doesn't
> > bother you too much that it's not standard SQL.
> >
>
> Why not just use "identifier" which is standard SQL?

If you accidentally type [identifire] or `identifire`, SQLite will
produce an unknown identifier error, alerting you immediately to your typo.
If you accidentally type "identifire", SQLite will silently treat it as
a string literal instead of an identifier, causing more difficult to
diagnose problems.

Example:

-- Preparation:
sqlite> create table foo ("columna" text, "columnb" text);
sqlite> insert into foo values ("xyzzy", "xyzzy");

-- Variant with "":
sqlite> select count(*) from foo where "columna" = "colummb";
0

Not at all at first sight clear why there seem to be no matching rows, 
if you even notice straightaway that the result is not correct.


-- Variant with []:
sqlite> select count(*) from foo where [columna] = [colummb];
Error: no such column: colummb

Immediately clear that there is a problem, and what the problem is.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Roel Schroeven schreef op 13/12/2022 om 22:36:

sqlite> insert into foo values ("xyzzy", "xyzzy");
SQLite accepts it like that, but I really should have used single quotes 
there instead of double quotes. It's a bad habit from using MySQL for 
too long I guess.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

Chris Angelico schreef op 13/12/2022 om 22:58:

Okay, so. exactly the same as if you use standard double quotes,
but change the configuration option. So the options are: make
everything worse for everyone by exacerbating the problem of
non-standard identifier quoting, or get this API so SQLite can be
configured, like the OP actually asked for.

I'm not advocating for one above the other, I think they complement each 
other. Having the option to change SQLite's behavior is clearly the 
better solution if/when that happens (and is released and available in 
our development environments), but that doesn't mean there's no value in 
having a workaround here and now.


--
"Most quotes are misattributed"
-- Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: Possible re bug when using ".*"

[Roel Schroeven]

Alexander Richert - NOAA Affiliate via Python-list schreef op 28/12/2022 
om 19:42:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes: 
"Changed in version 3.7: Empty matches for the pattern are replaced when 
adjacent to a previous non-empty match." and "Changed in version 3.7: 
Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first matches 
"pattern", which is a non-empty match; then it matches the empty string 
at the end, which is an empty match but is replaced because it is 
adjacent to a non-empty match.


Seems somewhat counter-intuitive to me, but AFAICS it's the intended 
behavior.


--
"Programming today is a race between software engineers striving to build bigger
and better idiot-proof programs, and the Universe trying to produce bigger and
better idiots. So far, the Universe is winning."
-- Douglas Adams
--
https://mail.python.org/mailman/listinfo/python-list

Re: Possible re bug when using ".*"

[Roel Schroeven]

Roel Schroeven schreef op 28/12/2022 om 19:59:
Alexander Richert - NOAA Affiliate via Python-list schreef op 
28/12/2022 om 19:42:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes: 
"Changed in version 3.7: Empty matches for the pattern are replaced 
when adjacent to a previous non-empty match." and "Changed in version 
3.7: Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first 
matches "pattern", which is a non-empty match; then it matches the 
empty string at the end, which is an empty match but is replaced 
because it is adjacent to a non-empty match.


Seems somewhat counter-intuitive to me, but AFAICS it's the intended 
behavior.
For what it's worth, there's some discussion about this in this Github 
issue: https://github.com/python/cpython/issues/76489


--
"Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’à
la mort pour que vous ayez le droit de le dire."
-- Attribué à Voltaire
"I disapprove of what you say, but I will defend to the death your right to
say it."
-- Attributed to Voltaire
"Ik ben het niet eens met wat je zegt, maar ik zal je recht om het te zeggen
tot de dood toe verdedigen"
-- Toegeschreven aan Voltaire
--
https://mail.python.org/mailman/listinfo/python-list

Re: To clarify how Python handles two equal objects

[Roel Schroeven]

Jen Kris via Python-list schreef op 10/01/2023 om 21:41:

But where they have been set to the same object, an operation on one will 
affect the other as long as they are equal (in Python).
As long as they are *identical*, not equal. Identical as in having the 
same identity as Python defines it.
I advise you to read Ned Batchelder's explanation about names and values 
in Python, or watch his presentation, to get a good understanding. See 
https://nedbatchelder.com/text/names1.html


--
"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

--
https://mail.python.org/mailman/listinfo/python-list

Re: To clarify how Python handles two equal objects

[Roel Schroeven]

Op 11/01/2023 om 16:33 schreef Jen Kris via Python-list:

Yes, I did understand that.  In your example, "a" and "b" are the same pointer, 
so an operation on one is an operation on the other (because they’re the same memory block).


Sorry if you feel I'm being overly pedantic, but your explanation "an 
operation on one is an operation on the other (because they’re the same 
memory block)" still feels a bit misguided. "One" and "other" still make 
it sound like there are two objects, and "an operation on one" and "an 
operation on the other" make it sound like there are two operations.
Sometimes it doesn't matter if we're a bit sloppy for sake of simplicity 
or convenience, sometimes we really need to be precise. I think this is 
a case where we need to be precise.


So, to be precise: there is only one object, with possible multiple 
names to it. We can change the object, using one of the names. That is 
one and only one operation on one and only one object. Since the 
different names refer to the same object, that change will of course be 
visible through all of them.
Note that 'name' in that sentence doesn't just refer to variables (mx1, 
arr1, ...) but also things like indexed lists (mx1[0], mx1[[0][0], ...), 
loop variables, function arguments.


The correct mental model is important here, and I do think you're on 
track or very close to it, but the way you phrase things does give me 
that nagging feeling that you still might be just a bit off.


--
"Peace cannot be kept by force. It can only be achieved through understanding."
-- Albert Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: file.read Method Documentation (Python 2.7.10)

[Roel Schroeven]

Chris Angelico schreef op 11/01/2023 om 18:36:

On Thu, 12 Jan 2023 at 04:31, Stephen Tucker  wrote:
> 1. Create BOM.txt
> 2. Input three bytes at once from BOM.txt and print them
> 3. Input three bytes one at a time from BOM.txt and print them

All of these correctly show that a file, in binary mode, reads and writes bytes.

> 4. Input three bytes at once from BOM.txt and print them
> >>> import codecs
> >>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")

This is now a codecs file, NOT a vanilla file object. See its docs here:

https://docs.python.org/2.7/library/codecs.html#codecs.open

The output is "codec-dependent" but I would assume that UTF-8 will
yield Unicode text strings.

> 5. Attempt to input three bytes one at a time from BOM.txt and print them
> -
>
> >>> myfil = codecs.open ("BOM.txt", mode="rb", encoding="UTF-8")
> >>> myBOM_4 = myfil.read (1)
> >>> myBOM_4
> u'\ufeff'

> A. The attempt at Part 5 actually inputs all three bytes when we ask it to 
input just the first one!

On the contrary; you asked it for one *character* and it read one character.


Not exactly. You're right of course that things opened with 
codecs.open() behave differently from vanilla file objects.
codecs.open() returns a StreamReaderWriter instance, which combines 
StreamReader and StreamWriter. For read(), StreamReader is what matters 
(documented at 
https://docs.python.org/3.11/library/codecs.html#codecs.StreamReader). 
It's read() method is:


read(size=- 1, chars=- 1, firstline=False)

_size_ indicates the approximate maximum number of encoded bytes or code 
points to read for decoding. The decoder can modify this setting as 
appropriate.


_chars_ indicates the number of decoded code points or bytes to return. 
The read() method will never return more data than requested, but it 
might return less, if there is not enough available.


When only one parameter is provided, without name, it's _size_. So 
myfil.read(1) asks to read enough bytes to decode 1 code point 
(approximately). That's totally consistent with the observer behavior.


--
"Peace cannot be kept by force. It can only be achieved through understanding."
-- Albert Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: To clarify how Python handles two equal objects

[Roel Schroeven]

Chris Angelico schreef op 15/01/2023 om 1:41:

On Sun, 15 Jan 2023 at 11:38, Jen Kris  wrote:
>
> Yes, in fact I asked my original question – "I discovered something about Python 
array handling that I would like to clarify" -- because I saw that Python did it that 
way.
>

Yep. This is not specific to arrays; it is true of all Python objects.
Also, I suspect you're still thinking about things backwards, and am
trying to lead you to a completely different way of thinking that
actually does align with Python's object model.
Indeen, I also still have the impression that Jen is thinking in terms 
of variables that are possible aliased such as you can have in a 
language like C, instead of objects with one or more names like we have 
in Python. Jens, in the Python model you really have to think of the 
objects largely independently of the names that are or are not 
referencing the objects.


--
"Ever since I learned about confirmation bias, I've been seeing
it everywhere."
-- Jon Ronson

--
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Roel Schroeven]

Op 19/01/2023 om 11:32 schreef Stefan Ram:

dn  writes:
>The longer an identifier, the more it 'pushes' code over to the right or 
>to expand over multiple screen-lines. Some thoughts on this are behind 
>PEP-008 philosophies, eg line-limit.


   Raymond Hettinger (transcribed, shortened and partially
   paraphrased by me [Stefan Ram]):

|The line-width part of PEP 8 bugs me.
|
|You have to wrap your commits in seventy-two characters. You have
|to end your lines at seventy-nine characters.
|
|One time it bugs me is when I'm writing unit tests.
|
|When I write unit tests, I have to start with a class, and then
|inside the class there's a "def" for tests, and then the test
|starts with a "self.assertEqual", and by then most of my line
|is gone. So by the time I get to any business logic in my test,
|I'm near the end of the line.
|
|If I go over seventy-nine characters, somebody will come and
|PEP 8 me.
|
|They'll come in and say: "Oh, Raymond's line hit eighty-one
|characters, I'm going to PEP 8 it!". And so, while I'm not
|looking, they come in and reformat my code.
|
|They'll just throw a line break at a really awkward place.
|
|Does that make the code better?
|
|So, to escape that pressure, I think: Maybe I can just commit
|a little atrocity and that way no one will ever come and PEP 8 me.
|I'll just shorten my variable names.
|
|Does that make the code better?
|
freely adapted from Raymond Hettinger
He then goes on to say he uses 90-ish, IIRC: he tries to stay under 
that, but doesn' t mine if a line goes a bit over. Or at least that's 
what I remember from that talk, I might be wrong.


--

"If you don't read the newspaper, you're uninformed. If you read the newspaper,
you're mis-informed."
-― Onbekend (dikwijls toegeschreven aan Mark Twain, waarschijnlijk 
onterecht)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Roel Schroeven]

2qdxy4rzwzuui...@potatochowder.com schreef op 19/01/2023 om 19:30:

> The PEP-8 rules are good, but they can't cover all cases perfectly.

Some the PEP-8 rules are debatable.  Regardless, they can't cover all
cases perfectly.  (IOW, we agree on the bit that's relevant to this
thread.)

PEP 8 even covers that:

A Foolish Consistency is the Hobgoblin of Little Minds
[...]
However, know when to be inconsistent – sometimes style guide 
recommendations just aren’t applicable. When in doubt, use your best 
judgment. [...]


--
"For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled."
-- Richard Feynman

--
https://mail.python.org/mailman/listinfo/python-list

Re: DeprecationWarning but replacement doesn't work

[Roel Schroeven]

Chris Green schreef op 4/02/2023 om 16:17:

I am using Image from PIL and I'm getting a deprecation warning as
follows:-

/home/chris/bin/picShrink.py:80: DeprecationWarning: ANTIALIAS is deprecated 
and will be removed in Pillow 10 (2023-07-01). Use Resampling.LANCZOS instead.


But if I change line 80 to:-

 im.thumbnail(size, Resampling.LANCZOS)

I simply get an error as follows:-

 picShrink.py
 Traceback (most recent call last):
   File "/home/chris/bin/picShrink.py", line 80, in 
 im.thumbnail(size, Resampling.LANCZOS)
 NameError: name 'Resampling' is not defined


So, presumably there's more I need to change.  Where can I find out what
I need to do?
There's some information about changes in constants in the release notes 
for version 9.1.0, see 
https://pillow.readthedocs.io/en/stable/releasenotes/9.1.0.html. At 
first sight it looks like that indicates you have to do either


    from PIL import Image.Resampling as Resampling
    ...
    im.thumbnail(size, Resampling.LANCZOS)

or

    from PIL import Image.Resampling
    ...
    im.thumbnail(size, Image.Resampling.LANCZOS)

BUT according to the release notes of version 9.4.0 (see 
https://pillow.readthedocs.io/en/stable/releasenotes/9.4.0.html#restored-image-constants) 
the constants in Image will remain (it's not clear to me if the ones in 
Image.Resample will remain too). As far as I can see ANTIALIAS is still 
deprecated in favor of LANCZOS though. All in all, it looks like the way 
to go is to use Image.LANCZOS. In versions 9.1.0 up to but not including 
9.4.0 that will give you a deprecation warning but that can safely be 
ignored.


--
"Life ain't no fairy tale
Just give me another ale
And I'll drink to Rock 'n Roll"
-- Barkeep (The Scabs)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Am I banned from Discuss forum?

[Roel Schroeven]

Michael Torrie schreef op 11/02/2023 om 4:59:
I didn't know there was a Discourse forum.  Is it supposed to be sync  > with the mailing list and USENET? Or is it intended to replace this 
> mailing list? I rarely see Python devs on this list, so maybe > 
they've chosen to hang out exclusively in Discourse, which would be > 
unfortunate.
I don't think it's meant to replace this mailing list; it's still 
mentioned on the Python website. At least initially the forum was 
intended mostly for core dev discussions, as far as I understand it.


The initial announcement (which only talks about python-comitters being 
migrated): 
https://www.mail-archive.com/python-committers@python.org/msg06151.html

The site with the discussions: https://discuss.python.org/

--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones
--
https://mail.python.org/mailman/listinfo/python-list

Re: Tuple Comprehension ???

[Roel Schroeven]

Hen Hanna schreef op 21/02/2023 om 5:13:

 (A)   print( max( * LisX ))
 (B)   print( sum( * LisX ))<--- Bad syntax !!!

What's most surprising is (A)  is ok, and  (B) is not.

even tho'   max() and sum()  have   (basically)  the same syntax... 
 ( takes one arg ,  whch is a list )


There's an important difference in syntax.

sum() takes an iterable:

sum(iterable, /, start=0)
    Return the sum of a 'start' value (default: 0) plus an iterable of 
numbers


    When the iterable is empty, return the start value.
    This function is intended specifically for use with numeric values 
and may

    reject non-numeric types.

max() on the other hand takes either an iterable or a number of 
individual elements:


max(...)
    max(iterable, *[, default=obj, key=func]) -> value
    max(arg1, arg2, *args, *[, key=func]) -> value

    With a single iterable argument, return its biggest item. The
    default keyword-only argument specifies an object to return if
    the provided iterable is empty.
    With two or more arguments, return the largest argument.

That second form of max is why max(*some_list) works while 
sum(*some_list) doesn't.


--
"You can fool some of the people all the time, and all of the people some
of the time, but you cannot fool all of the people all of the time."
-- Abraham Lincoln
"You can fool too many of the people too much of the time."
-- James Thurber

--
https://mail.python.org/mailman/listinfo/python-list

Re: Line continuation and comments

[Roel Schroeven]

Mark Bourne schreef op 24/02/2023 om 22:04:

Personally, I don't particularly like the way you have to put multiline
strings on the far left (rather than aligned with the rest of the scope)
to avoid getting spaces at the beginning of each line.  I find it makes
it more difficult to see where the scope of the class/method/etc.
actually ends, especially if there are multiple such strings.  It's not
too bad for strings defined at the module level (outer scope) though,
and of course for docstrings the extra spaces at the beginning of each
line don't matter.
A way around this is using textwrap.dedent() 
(https://docs.python.org/3.10/library/textwrap.html?highlight=dedent#textwrap.dedent). 
Example from the documentation:


    def test():
    # end first line with \ to avoid the empty line!
    s = '''\
    hello
  world
    '''
    print(repr(s))  # prints '    hello\n world\n    '
    print(repr(dedent(s)))  # prints 'hello\n  world\n'


--
"Met een spitsvondig citaat bewijs je niets."
-- Voltaire

--
https://mail.python.org/mailman/listinfo/python-list

Re: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and

[Roel Schroeven]

Op 26/02/2023 om 6:53 schreef Hen Hanna:
> There are some similarities between Python and Lisp-family 
> languages, but really Python is its own thing. 



Scope (and extent ?) of   variables is one reminder that  Python is not Lisp

　fori in  range(5):　　print( i )
  .
　print( i )

ideally, after the FOR loop is done,  the (local) var  i should also disappear.
(this almost caused a bug for me)
I wouldn't say "i *should* also disappear". There is no big book of 
programming language design with rules like that that all languages have 
to follow. Different languages have different behavior. In some 
languages, for/if/while statements introduce a new scope, in other 
languages they don't. In Python, they don't. I won't say one is better 
than the other; they're just different.


--
"Most of us, when all is said and done, like what we like and make up
reasons for it afterwards."
-- Soren F. Petersen

--
https://mail.python.org/mailman/listinfo/python-list

Re: it seems like a few weeks ago... but actually it was more like 30 years ago that i was programming in C, and

[Roel Schroeven]

Op 27/02/2023 om 9:56 schreef inhahe:

On Mon, Feb 27, 2023 at 3:52 AM Roel Schroeven 
wrote:

> Op 26/02/2023 om 6:53 schreef Hen Hanna:
> > > There are some similarities between Python and Lisp-family
> > > languages, but really Python is its own thing.
> >
> >
> > Scope (and extent ?) of   variables is one reminder that  Python is
> not Lisp
> >
> > fori in  range(5): print( i )
> >   .
> > print( i )
> >
> > ideally, after the FOR loop is done,  the (local) var  i should also
> disappear.
> > (this almost caused a bug for me)
> I wouldn't say "i *should* also disappear". There is no big book of
> programming language design with rules like that that all languages have
> to follow. Different languages have different behavior. In some
> languages, for/if/while statements introduce a new scope, in other
> languages they don't. In Python, they don't. I won't say one is better
> than the other; they're just different.
>
> --
>
>
I'm not sure, but I think I remember this was actually a bug in the
interpreter, and presumably they didn't fix it because they didn't want to
break backward compatibility?
I'm guessing you're thinking about variables leaking out of list 
comprehensions. I seem to remember (but I could be wrong) it was a 
design mistake rather than a bug in the code, but in any case it's been 
fixed now (in the 2 to 3 transition, I think).


For loops (and while loops, and if statements) not introducing a new 
scope is a deliberate decision and is not subject to change.


--
"Ever since I learned about confirmation bias, I've been seeing
it everywhere."
-- Jon Ronson

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to escape strings for re.finditer?

[Roel Schroeven]

Op 28/02/2023 om 3:44 schreef Thomas Passin:

On 2/27/2023 9:16 PM, avi.e.gr...@gmail.com wrote:
And, just for fun, since there is nothing wrong with your code, this 
minor change is terser:



example = 'X - abc_degree + 1 + qq + abc_degree + 1'
for match in re.finditer(re.escape('abc_degree + 1') , example):

... print(match.start(), match.end())
...
...
4 18
26 40


Just for more fun :) -

Without knowing how general your expressions will be, I think the 
following version is very readable, certainly more readable than regexes:


example = 'X - abc_degree + 1 + qq + abc_degree + 1'
KEY = 'abc_degree + 1'

for i in range(len(example)):
    if example[i:].startswith(KEY):
    print(i, i + len(KEY))
# prints:
4 18
26 40
I think it's often a good idea to use a standard library function 
instead of rolling your own. The issue becomes less clear-cut when the 
standard library doesn't do exactly what you need (as here, where 
re.finditer() uses regular expressions while the use case only uses 
simple search strings). Ideally there would be a str.finditer() method 
we could use, but in the absence of that I think we still need to 
consider using the almost-but-not-quite fitting re.finditer().


Two reasons:

(1) I think it's clearer: the name tells us what it does (though of 
course we could solve this in a hand-written version by wrapping it in a 
suitably named function).


(2) Searching for a string in another string, in a performant way, is 
not as simple as it first appears. Your version works correctly, but 
slowly. In some situations it doesn't matter, but in other cases it 
will. For better performance, string searching algorithms jump ahead 
either when they found a match or when they know for sure there isn't a 
match for some time (see e.g. the Boyer–Moore string-search algorithm). 
You could write such a more efficient algorithm, but then it becomes 
more complex and more error-prone. Using a well-tested existing function 
becomes quite attractive.


To illustrate the difference performance, I did a simple test (using the 
paragraph above is test text):


    import re
    import timeit

    def using_re_finditer(key, text):
    matches = []
    for match in re.finditer(re.escape(key), text):
    matches.append((match.start(), match.end()))
    return matches


    def using_simple_loop(key, text):
    matches = []
    for i in range(len(text)):
    if text[i:].startswith(key):
    matches.append((i, i + len(key)))
    return matches


    CORPUS = """Searching for a string in another string, in a 
performant way, is
    not as simple as it first appears. Your version works correctly, 
but slowly.
    In some situations it doesn't matter, but in other cases it will. 
For better
    performance, string searching algorithms jump ahead either when 
they found a
    match or when they know for sure there isn't a match for some time 
(see e.g.

    the Boyer–Moore string-search algorithm). You could write such a more
    efficient algorithm, but then it becomes more complex and more 
error-prone.

    Using a well-tested existing function becomes quite attractive."""
    KEY = 'in'
    print('using_simple_loop:', 
timeit.repeat(stmt='using_simple_loop(KEY, CORPUS)', globals=globals(), 
number=1000))
    print('using_re_finditer:', 
timeit.repeat(stmt='using_re_finditer(KEY, CORPUS)', globals=globals(), 
number=1000))


This does 5 runs of 1000 repetitions each, and reports the time in 
seconds for each of those runs.

Result on my machine:

    using_simple_loop: [0.1395295020792, 0.1306313000456, 
0.1280345001249, 0.1318618002423, 0.1308461032626]
    using_re_finditer: [0.00386140005233, 0.00406190124297, 
0.00347899970256, 0.00341310216218, 0.003732001273]


We find that in this test re.finditer() is more than 30 times faster 
(despite the overhead of regular expressions.


While speed isn't everything in programming, with such a large 
difference in performance and (to me) no real disadvantages of using 
re.finditer(), I would prefer re.finditer() over writing my own.


--
"The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom."
-- Isaac Asimov

--
https://mail.python.org/mailman/listinfo/python-list

Re: How to escape strings for re.finditer?

[Roel Schroeven]

Op 28/02/2023 om 14:35 schreef Thomas Passin:

On 2/28/2023 4:33 AM, Roel Schroeven wrote:

[...]
(2) Searching for a string in another string, in a performant way, is 
not as simple as it first appears. Your version works correctly, but 
slowly. In some situations it doesn't matter, but in other cases it 
will. For better performance, string searching algorithms jump ahead 
either when they found a match or when they know for sure there isn't 
a match for some time (see e.g. the Boyer–Moore string-search 
algorithm). You could write such a more efficient algorithm, but then 
it becomes more complex and more error-prone. Using a well-tested 
existing function becomes quite attractive.


Sure, it all depends on what the real task will be.  That's why I 
wrote "Without knowing how general your expressions will be". For the 
example string, it's unlikely that speed will be a factor, but who 
knows what target strings and keys will turn up in the future?
On hindsight I think it was overthinking things a bit. "It all depends 
on what the real task will be" you say, and indeed I think that should 
be the main conclusion here.


--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: Testing list sequence question

[Roel Schroeven]

Gabor Urban schreef op 4/03/2023 om 17:38:

  Hi guys,

I have a strange problem that I do not understand. I am testing function
which returns a dictionary. The code should ensure that the keys of the
dictionary are generated in a given order.

I am testing the function with the standard unittest module and use the
assertListEqual statement to verify the sequence. Sometimes this test
fails, sometimes passes without any change neither in the code, nor in the
testcase. I am using "list(myDict.keys())" to create the list of the keys
of the dictionary.

I am running Python 3.3 on MS Windows. Any idea why is this?
Prior to Python 3.6 (de facto) and Python 3.7 (officially), there was no 
guarantee at all about the order of keys in a dict. If you need the keys 
to be in the same order they were inserted, either use 
collections.OrderedDict or upgrade to Python 3.7 or later.


--
"Life ain't no fairy tale
Just give me another ale
And I'll drink to Rock 'n Roll"
-- Barkeep (The Scabs)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Testing list sequence question

[Roel Schroeven]

Thomas Passin schreef op 4/03/2023 om 18:49:

On 3/4/2023 11:38 AM, Gabor Urban wrote:
>   Hi guys,
> 
> I have a strange problem that I do not understand. I am testing function

> which returns a dictionary. The code should ensure that the keys of the
> dictionary are generated in a given order.
> 
> I am testing the function with the standard unittest module and use the

> assertListEqual statement to verify the sequence. Sometimes this test
> fails, sometimes passes without any change neither in the code, nor in the
> testcase. I am using "list(myDict.keys())" to create the list of the keys
> of the dictionary.
> 
> I am running Python 3.3 on MS Windows. Any idea why is this?


List order would not be guaranteed.  Sort the list first.  Then your
problem should clear up.
How would that enable you to check that the keys in the dict are in a 
specific order?


--
"Ever since I learned about confirmation bias, I've been seeing
it everywhere."
-- Jon Ronson

--
https://mail.python.org/mailman/listinfo/python-list

Re: We can call methods of parenet class without initliaze it?

[Roel Schroeven]

Op 15/03/2023 om 10:57 schreef scruel tao:

The following code won’t be allowed in Java, but in python, it works fine:
```python
class A:
 A = 3

 def __init__(self):
 print(self.A)

 def p(self):
 print(self.A)
 self.A += 1


class B(A):
 def __init__(self):
 print(2)
 self.p()
 super().__init__()


B()
```

How can I understand this? Will it be a problem?
Important: __init__ is not a constructor, like you have for example in 
C++. I don't know Java, but it seems plausible it works somewhat like 
C++ in this regard. Python does it differently: when you create an 
instance, the instance is fully created/constructed even before __init__ 
is called. __init__ is purely an initializer: you can use to initialize 
the things you want to initialize.


Back to your example: it works because A is a class-level attribute, 
which is initialized independently from __init__. If you make it an 
instance attribute, like below, things stop working:


    class A:
    def __init__(self):
    self.A = 3
    print(self.A)

    def p(self):
    print(self.A)
    self.A += 1


    class B(A):
    def __init__(self):
    print(2)
    self.p()
    super().__init__()


    B()
    print(A.A)

That fails like this:

    Traceback (most recent call last):
  File ".code.tio", line 18, in 
    B()
  File ".code.tio", line 14, in __init__
    self.p()
  File ".code.tio", line 7, in p
    print(self.A)
    AttributeError: 'B' object has no attribute 'A'

That's because now A is indeed initialized in A.__init__, so it doesn't 
exist before A.__init__ is called.


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging reason for python running unreasonably slow when adding numbers

[Roel Schroeven]

Op 14/03/2023 om 8:48 schreef Alexander Nestorov:

I have the following code:

 ...
 for i in range(151): # 150 iterations
     ...
Nothing to do with your actual question and it's probably just a small 
oversight, but still I thought it was worth a mention: that comment does 
not accurately describe the code; the code is actually doing 151 
iterations, numbered 0 up to and including 150.


--
"I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is
   just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new
   and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of 
things."
-- Douglas Adams, The Salmon of Doubt

--
https://mail.python.org/mailman/listinfo/python-list

Re: Friday finking: IDE 'macro expansions'

[Roel Schroeven]

Op 17/03/2023 om 0:54 schreef Thomas Passin:
What I find more useful is matching brackets/parens/braces.  Not 
inserting them but highlighting or (better) jumping to the matching 
one when asked.

That is very helpful indeed.
Even better than simply highlighting is (IMO) a thing called "Rainbow 
Braces" or "Bracket Pair Colorization" I recently learned about: both 
braces of a matching pair get the same color, while other pairs get 
other colors. I have to say I like it quite a lot. It's in VS Code these 
days; possible there are implementations or extensions for other editors 
and IDEs as well.


--
"Most of us, when all is said and done, like what we like and make up
reasons for it afterwards."
-- Soren F. Petersen

--
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Friday finking: IDE 'macro expansions'

[Roel Schroeven]

Peter J. Holzer schreef op 18/03/2023 om 13:15:

On 2023-03-18 08:46:42 +, Alan Gauld wrote:
> On 17/03/2023 17:55, Thomas Passin wrote:
> >> I used Delphi and Smalltalk/V which both pretty much only exist within
> >> their own IDEs and I used their features extensively.
> > 
> > Back when Delphi first came out, when I first used it, I don't remember 
> > any IDE; one just used a text editor.
> 
> I think you might be meaning TurboPascal, Delphi's forerunner. It just

> had a compiler and text editor.

I'd still classify Turbo Pascal as an IDE. It wasn't a standalone
compiler you would invoke on source files you wrote with some other
tool. It was a single program where you would write your code, compile
it, see the errors directly in the source code. I think it even had a
debugger which would also use the same editor window (Turbo C did).


Oh yes, Turbo Pascal was definitely an IDE. It was actually pretty 
similar to the GUI applications we have today, even though it was all 
text based. It had a menu bar with pull-down menus, it had popup 
windows. The look and feel is pretty similar to that of Midnight 
Commander (mc) nowadays, for those who know that.


Like you say it had an editor (obviously) and an integrated compiler, 
and indeed an integrated debugger, with watches and all, much like you 
would see in an IDE today. See this screenshot for example: 
https://daynhauhoc.s3.dualstack.ap-southeast-1.amazonaws.com/original/3X/7/8/782423b53bb6531d43c3c2075cb4a00f4ac7a5c0.png


For people too young to have used such semi-graphical applications in 
the past, you can find plenty of screenshots when you do an image search 
for turbo pascal.


Turbo Pascal was obviously not as advanced as the IDEs we have today, 
but it was definitely an IDE, and it had all the basic functions that 
one would expect from an IDE.


--
"Most of us, when all is said and done, like what we like and make up
reasons for it afterwards."
-- Soren F. Petersen

--
https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

[Roel Schroeven]

Andreas Eisele schreef op 30/03/2023 om 11:15:

I sometimes make use of the fact that the built-in pow() function has an optional third 
argument for modulo calculation, which is handy when dealing with tasks from number 
theory, very large numbers, problems from Project Euler, etc. I was unpleasantly 
surprised that math.pow() does not have this feature, hence "from math import 
*" overwrites the built-in pow() function with a function that lacks functionality. 
I am wondering for the rationale of this. Does math.pow() do anything that the built-in 
version can not do, and if not, why is it even there?
According to the docs, "Unlike the built-in ** operator, math.pow() 
converts both its arguments to type float. Use ** or the built-in pow() 
function for computing exact integer powers." I think that means that 
math.pow() is more meant to work with floats, while the built-in is more 
meant for integers (even though the built-in works with floats just fine).


In any case, I would strongly advocate against "from math import *" (not 
just for math but for any module really). One of the reasons is the 
potential for name conflicts, which is exactly what you experience here.


Either import the things you need explicitly: "from math import sin, 
cos, exp" (for example).

Or a plain import: "import math" combined with "math.sin", "math.cos".
Or use an abbreviation: "import math as m" combined with "m.sin", "m.cos".

--
"There is no cause so noble that it will not attract fuggheads."
-- Larry Niven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Christoph Gohlke and compiled packages

[Roel Schroeven]

Op 11/04/2023 om 12:58 schreef Chris Angelico:

On Tue, 11 Apr 2023 at 20:15, Jim Schwartz  wrote:
>
> What’s the problem now?  Is it with python on windows?  I use python on 
windows so I’d like to know. Thanks
>

Python itself is fine, but a lot of third-party packages are hard to
obtain. So if you need numpy, for instance, or psycopg2, you might
need to find an alternative source.
These days I use pip to install packages, and so far for the things I 
need it simply works. "pip install numpy" works, same for psycopg2, 
pillow, pandas, and other packages I use. Conda should work too, for 
those who use the Anaconda Python distribution. I honestly don't even 
know how it's done: are there some kind souls who provide the wheels 
(binary packages) for all those things, or if there is maybe a build 
farm that does the hard work to make things easy for us.


In the past I've used Christoph Gohlke's site and I'm very grateful for 
the service it provided, but these days I don't really need it anymore, 
luckily.


--
"Ever since I learned about confirmation bias, I've been seeing
it everywhere."
-- Jon Ronson

--
https://mail.python.org/mailman/listinfo/python-list

Re: Dataclasses, immutability(?), and ChatGPT

[Roel Schroeven]

Op 12/04/2023 om 6:58 schreef dn via Python-list:

Are dataclasses (or instances thereof) mutable or immutable?
- and in what sense?
Instances of dataclasses are mutable, just like normal classes. 
Dataclasses *are* normal classes, with some extra special methods. They 
are totally different from namedtuples, even though the use cases 
somewhat overlap. They *can* be immutable, I think, if the programmer 
takes care to make them so. I don't think adding __hash__() is enough: 
as I understand it's an indication that a class is immutable, but 
doesn't actually by itself make it so. "Mutability is a complicated 
property that depends on the programmer’s intent, the existence and 
behavior of |__eq__()|, and the values of the |eq| and |frozen| flags in 
the |dataclass()| 
 
decorator.", says the documentation.

Amongst the four benefits ChatGPT listed was:
«
Immutable instances: By default, instances of dataclasses are 
immutable, which means that once created, their attributes cannot be 
modified. This can help to prevent unintended modifications to the data.

»

Huh? If we'd been discussing namedtuples over (say) dictionaries, I'd 
perhaps have accepted the reply.

ChatGPT is wrong.

Anything I've 'missed'?
- or a salutary tale of not depending upon ChatGPT etc?
You didn't miss anything, ChatGPT is wrong. The thing to look out for is 
that when ChatGPT is wrong, it sounds just as convincing as when it's 
right; there is no indication in it's tone or style that it's making 
things up. Always double check!


--
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams
--
https://mail.python.org/mailman/listinfo/python-list

Re: Invalid literal for int() with base 10?

[Roel Schroeven]

Op 25/05/2023 om 23:30 schreef Kevin M. Wilson via Python-list:

Ok, I'm not finding any info. on the int() for converting a str to an int (that specifies 
a base parameter)?! The picture is of the code I've written... And the base 10 paradigm 
involved?? years = int('y') # store for calculationValueError: invalid literal for int() 
with base 10: 'y'What is meant by "invalid literal"? I'm trying to convert srt 
to int, and I didn't know I needed to specify the base. Plus I haven't read anything that 
I need to specify the base for the int().
That error message might give the impression that you have to specify 
the base, but that's misleading. It's just trying to be helpful, showing 
what base was used because the allowed values depend on the base. For 
example, these will work:


int('abcd', 16) # abcd is a valid hexadecimal number
int('249', 10)
int('249') # same as above, since base 10 is the default
int('14', 8)

These don't work:

int('abcd', 10) # abcd is not a decimal number
int('abcd') # same as above, since base 10 is the default
int('249', 8) # 249 is not an octal number since 9 is not an octal digit

An error message like "invalid literal for int(): '249'" would be very 
confusing because 249 seems to be a valid integer at first sight; 
""invalid literal for int(): '249' with base 8" makes clear why it's not 
accepted.


--
"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

"Invalid literal for int() with base 10": is it really a literal?

[Roel Schroeven]

Kevin M. Wilson's post "Invalid literal for int() with base 10?" got me 
thinking about the use of the word "literal" in that message. Is it 
correct to use "literal" in that context? It's correct in something like 
this:


>>> int('invalid')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: 'invalid'

But something like this generates the same message:

>>> int(input())
hello
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: 'hello'

In cases like this there is no literal in sight.

I'm thinking it would be more correct to use the term 'value' here: 
ValueError: invalid value for int() with base 10: 'hello'

Does my reasoning make sense?

--
"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

Re: "Invalid literal for int() with base 10": is it really a literal?

[Roel Schroeven]

Op 26/05/2023 om 10:29 schreef Chris Angelico:

However, if you want to change the wording, I'd be more inclined to
synchronize it with float():

>>> float("a")
Traceback (most recent call last):
   File "", line 1, in 
ValueError: could not convert string to float: 'a'

I was looking for other ValueError-generating functions to find 
potentially better wording, and I somehow failed to think of float(), so 
thank you for mentioning it :) The ones I could think of were math 
functions like math.sqrt(); they give "ValueError: math domain error" 
which is rather less user friendly.


--
"'How to Stop Worrying and Learn to Love the Internet':
1) everything that’s already in the world when you’re born is just
normal;
2) anything that gets invented between then and before you turn
   thirty is incredibly exciting and creative and with any luck you can
   make a career out of it;
3) anything that gets invented after you’re thirty is against the
   natural order of things and the beginning of the end of civilisation
   as we know it until it’s been around for about ten years when it
   gradually turns out to be alright really.
Apply this list to movies, rock music, word processors and mobile
phones to work out how old you are."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: f-string syntax deficiency?

[Roel Schroeven]

Op 6/06/2023 om 16:08 schreef Chris Angelico:

On Wed, 7 Jun 2023 at 00:06, Neal Becker  wrote:
>
> The following f-string does not parse and gives syntax error on 3.11.3:
>
> f'thruput/{"user" if opt.return else "cell"} vs. elevation\n'
>
> However this expression, which is similar does parse correctly:
>
> f'thruput/{"user" if True else "cell"} vs. elevation\n'
>
> I don't see any workaround.  Parenthesizing doesn't help:
>  f'thruput/{"user" if (opt.return) else "cell"} vs. elevation\n'
>
> also gives a syntax error

Is this a problem with the f-string, or with the expression
opt.return? That's a keyword.

'return' being a keyowrd is definitely going to be the problem.

Neal, I assume you're using 'opt.return' also outside of that f-string. 
Does that work? How did you manage to do that? I tried to make a simple 
class with an attribute called 'return', but that already fails with a 
syntax error.


(Recently there has been an effort to provide clearer and more useful 
error messages; this seems to be a case where there is still room for 
improvement: "SyntaxError: invalid syntax" doesn't immediately remind me 
of that fact that 'return' is a keyword and therefor can't be used as an 
attribute.)


--
"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

--
https://mail.python.org/mailman/listinfo/python-list

Re: f-string syntax deficiency?

[Roel Schroeven]

Op 6/06/2023 om 16:41 schreef Roel Schroeven:

'return' being a keyowrd is definitely going to be the problem.

*keyword

--
"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Mr Flibble schreef op 15/02/2021 om 0:32:

On 14/02/2021 23:00, Christian Gollwitzer wrote:
I'm not saying that it is unfeasible or very difficult. I'm saying that it is a lot of work, and for a single 
developer who has this as a side project / support for his graphics engine and who wants to beat existing 
implementations wrt. speed, I'm saying it is going to take a lot of time. It'definitely impossible by 
"defining a few JSON schema files", as Leigh claims with his "universal compiler". There 
definitely IS a lot of stuff in a baseline CPython interpreter - a (seemingly) simple thing like 
"print" will have an implementation of 1000 lines in C with all the formatting library, file I/O 
etc. Arbitrary precision integers - another library, networking - yet another and so on.

There will only be one schema file and it is will be a relatively small task which 
certainly isn't "impossible": I should have a working implementation by the 
summer.


So your claim is that your compiler is able to, or will be able to, 
compile any language just by specifying a small schema file. Great!


Do you maybe have a proof-of-concept? A simple language with a simple 
schema file to test the basic workings of your compiler, like your 
neoscript or perhaps something like a minimal variant of Python? I'm 
curious what such a schema file would like look, and especially how you 
use it to not only specify the syntax but also the semantics of the 
various languages.


Is it your intention to not only compile procedural and object-oriented 
languages, or also functional languages such as Haskell, Ocaml, Scheme?


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Grant Edwards schreef op 15/02/2021 om 21:59:

On 2021-02-15, Roel Schroeven  wrote:


Is it your intention to not only compile procedural and object-oriented
languages, or also functional languages such as Haskell, Ocaml, Scheme?


And Prolog!


Ha, yes, that one was the next one I thought about, but in the I decided 
to leave it out.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Roel Schroeven]

Christian Gollwitzer schreef op 16/02/2021 om 8:25:

Am 15.02.21 um 21:37 schrieb Roel Schroeven:


So your claim is that your compiler is able to, or will be able to,
compile any language just by specifying a small schema file. Great!

Do you maybe have a proof-of-concept? A simple language with a simple
schema file to test the basic workings of your compiler,


Here is the git repo:

https://github.com/i42output/neos

under languages/ you'll find different schema files.


I saw that, and I saw the schema files. I had a look at the one for C, 
because I don't know the first thing about Ada, and it's not nearly 
enough to describe even the tiniest subset of C. And I saw the example 
session he posted here, where he supposedly compiles something, but 
doesn't even run it. It looked like that compilation did nothing but 
folding and folding and folding. And he didn't run it!


So it looks like that's the status of the project now: a compilation 
step that does /something/, but apparently doesn't result in anything 
runnable. And some work-in-progress (seemingly) schema files, but 
nothing concrete yet.


But I wanted to give Mr Flibble to benefit of the doubt, and asked more 
explicitly about the status of the project. Apparently I was too late, 
Mr Flibble was already banned, but I didn't know that yet.


I've thougt about downloading the whole thing and trying to build it. 
But I'd have to install Visual Studio 2019 first and probably some 
dependencies. It didn't seem worth the effort.



Regards,
Roel

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Current thinking on required options

[Roel Schroeven]

Avi Gross via Python-list schreef op 20/04/2021 om 1:56:

Sidestepping the wording of "options" is the very real fact that providing
names for even required parts can be helpful in many cases.


Very true. It's very much like named arguments in Python function calls: 
they help to document precisely and explicitly what's happening, instead 
of having to rely on remembering the order of arguments/options.


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
    -- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Posting code on stackoverflow

[Roel Schroeven]

Rich Shepard schreef op 5/06/2021 om 23:36:

I tried to post a question on stackoverflow.com which included a bunch of
code (entered after clicking the box 'code'). I noticed that lines were
wrapped but could not find how to expand the input box so they would not
wrap.

SO wouldn't let me post the question because of the wrapped code. As I've
not asked a question ther for a long time, and it didn't involve long lines
of code, I need to learn a) how to enter code if it's not just clicking on
the 'code' box before pasting text and b) how to keep code lines from
wrapping so a horizontal scroll bar is made available.


There are several ways to format code on StackOverflow, see 
https://meta.stackoverflow.com/questions/251361/how-do-i-format-my-code-blocks


What I do most of the time is indent the code by 4 spaces and make sure 
there are blank lines before and after the code block.




--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why the list creates in two different ways? Does it cause by the mutability of its elements? Where the Python document explains it?

[Roel Schroeven]

Dieter Maurer schreef op 16/06/2021 om 18:32:

Chris Angelico wrote at 2021-6-16 02:20 +1000:

On Wed, Jun 16, 2021 at 2:18 AM Dieter Maurer  wrote:

As far as I know, there are no guarantees are the language level.
There are some (partially documented) implementation details
for CPython (which is just one possible implementation).


Yes there are - plenty of them :) The example I gave is a language
guarantee.


Would you point to the documentation location where this is guaranteed?


I lost track of which exact guarantee we're discussing here. In any 
case, the documentation for the id() function ([1]) says:


"This is an integer which is guaranteed to be unique and constant for 
this object during its lifetime. Two objects with non-overlapping 
lifetimes may have the same id() value.


CPython implementation detail: This is the address of the object in memory."

Does that answer your doubts?


[1] https://docs.python.org/3.8/library/functions.html?highlight=id#id

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
    -- Franklin P. Jones

Roel Schroeven

--
https://mail.python.org/mailman/listinfo/python-list

Re: argparse: delimiter for argparse list arguments

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 3/08/2021 om 17:48:

On 2021-08-03, Michael Torrie  wrote:
> On 8/2/21 1:43 PM, Sven R. Kunze wrote:
>> maybe, I am missing something here but is it possible to specify a 
>> delimiter for list arguments in argparse:
>> 
>> https://docs.python.org/3/library/argparse.html
>> 
>> Usually, '--' is used to separate two lists (cf. git).

>
> I've not seen this syntax in git. Are you referring the the double and
> triple dot notation git uses?  Can you give me an example of how git
> uses -- as a list separator?

Loads of git commands do this. e.g. commit, diff, log, status, etc.
It's not completely unlike what you're describing above, which is
already supported automatically by argparse.
Commands like git commit do not use '--' to separate two lists, but as 
Dan and Sven said to separate options from arguments, even if the 
arguments start with '-' (like many other programs -- I think this is 
standard in GNU). If you're 100% certain that none of the filenames 
start with '-', you can leave out '--' without any change in behavior. 
Especially when scripting and/or using wildcards it's best always to use 
that '--' to avoid nasty surprises.


$ git commit -m "hello" -- hello.py

is exactly the same as

$ git commit -m "hello" hello.py

It's just that the former is safer to use, because it properly works 
even in cases like


$ git commit -m "hello" -- -hello.py

whereas

$ git commit -m "hello" -hello.py

will likely not do what you expect.

As https://git-scm.com/docs/git-commit says:

> --
>   Do not interpret any more arguments as options.

--
"The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom."
-- Isaac Asimov

--
https://mail.python.org/mailman/listinfo/python-list

Re: argparse: delimiter for argparse list arguments

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 3/08/2021 om 22:55:

>> Loads of git commands do this. e.g. commit, diff, log, status, etc.
>> It's not completely unlike what you're describing above, which is
>> already supported automatically by argparse.
>
> Commands like git commit do not use '--' to separate two lists, but as 
> Dan and Sven said to separate options from arguments,


That is not quite correct. Check out 'git diff' for example - it takes
as position arguments zero, one, or two commit hashes followed by zero
or more pathnames.  You can use '--' to separate these two lists,
because of course sometimes a pathname can be indistinguishable from
a commit hash.
Ah yes, I stand corrected, git diff indeed uses -- to separate two lists 
(commits and paths).


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Regarding inability of Python Module Winsound to produce beep in decimal frequency

[Roel Schroeven]

Op 15/08/2021 om 7:01 schreef Chris Angelico:

On Sun, Aug 15, 2021 at 1:02 PM John O'Hagan  wrote:
>
> > On 2021-08-13 17:17, Chris Angelico wrote:
> > > Is it really? In my experience, no human ear can distinguish 277Hz
> > > from 277.1826Hz when it's played on a one-bit PC speaker, which the
> > > Beep function will be using.
>
> Rounding to integer frequencies will produce disastrously out-of-tune
> notes in a musical context! Particularly for low notes, where a whole
> semitone is only a couple of Hz difference. Even for higher notes, when
> they're played together any inaccuracies are much more apparent.

But before you advocate that too hard, check to see the *real*
capabilities of a one-bit PC speaker.
We're not necessarily talking about the PC speaker here: (almost) all 
computers these days have sound cards (mostly integrated on the 
motherboard) that are much more capable than those one-bit PC speakers. 
Beep uses that sound card, when available. I don't know how accurate the 
generated sound is though.


--
"Now, the invention of the scientific method and science is, I'm sure we'll all
agree, the most powerful intellectual idea, the most powerful framework for
thinking and investigating and understanding and challenging the world around
us that there is, and that it rests on the premise that any idea is there to be
attacked and if it withstands the attack then it lives to fight another day and
if it doesn't withstand the attack then down it goes. Religion doesn't seem to
work like that; it has certain ideas at the heart of it which we call sacred or
holy or whatever. That's an idea we're so familiar with, whether we subscribe
to it or not, that it's kind of odd to think what it actually means, because
really what it means is 'Here is an idea or a notion that you're not allowed to
say anything bad about; you're just not. Why not? - because you're not!"
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Roel Schroeven]

Op 2/09/2021 om 17:08 schreef Hope Rouselle:

 ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
 sum(ls)
> 39.594
>
 ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
 sum(ls)
> 39.61
>
> All I did was to take the first number, 7.23, and move it to the last
> position in the list.  (So we have a violation of the commutativity of
> addition.)

Suppose these numbers are prices in dollar, never going beyond cents.
Would it be safe to multiply each one of them by 100 and therefore work
with cents only?
For working with monetary values, or any value that needs to accurate 
correspondence to 10-based values, best use Python's Decimal; see the 
documentation: https://docs.python.org/3.8/library/decimal.html


Example:

from decimal import Decimal as D
ls1 = [D('7.23'), D('8.41'), D('6.15'), D('2.31'), D('7.73'), D('7.77')]
ls2 = [D('8.41'), D('6.15'), D('2.31'), D('7.73'), D('7.77'), D('7.23')]
print(sum(ls1), sum(ls2))

Output:
39.60 39.60

(Note that I initialized the values with strings instead of numbers, to 
allow Decimal access to the exact number without it already being 
converted to a float that doesn't necessarily exactly correspond to the 
decimal value)


--
"Your scientists were so preoccupied with whether they could, they didn't
stop to think if they should"
-- Dr. Ian Malcolm

--
https://mail.python.org/mailman/listinfo/python-list

Sad news: Fredrik Lundh ("Effbot") has passed away

[Roel Schroeven]

Message from Guido van Rossum 
(https://mail.python.org/archives/list/python-...@python.org/thread/36Q5QBILL3QIFIA3KHNGFBNJQKXKN7SD/):


A former core dev who works at Google just passed the news that 
Fredrik Lundh (also known as Effbot) has died.


Fredrik was an early Python contributor (e.g. Elementtree and the 're' 
module) and his enthusiasm for the language and community were 
inspiring for all who encountered him or his work. He spent countless 
hours on comp.lang.python answering questions from newbies and 
advanced users alike.


He also co-founded an early Python startup, Secret Labs AB, which 
among other software released an IDE named PythonWorks. Fredrik also 
created the Python Imaging Library (PIL) which is still THE way to 
interact with images in Python, now most often through its Pillow 
fork. His effbot.org site was a valuable resource for generations of 
Python users, especially its Tkinter documentation.


Fredrik's private Facebook page contains the following message from 
November 25 by Ylva Larensson (translated from Swedish):


"""

It is with such sorrow and pain that I write this. Fredrik has left us 
suddenly.


"""

A core dev wrote: "I felt privileged to be able to study Fredrik's 
code and to read his writing. He was a huge asset to our community in 
the early days. I enjoyed his sense of humor as well. I'm sad that he 
passed away."


We will miss him.



--
"Your scientists were so preoccupied with whether they could, they didn't
stop to think if they should"
-- Dr. Ian Malcolm

--
https://mail.python.org/mailman/listinfo/python-list

Re: venv and executing other python programs

[Roel Schroeven]

Op 15/02/2022 om 8:21 schreef Reto:

On Tue, Feb 15, 2022 at 06:35:18AM +0100, Mirko via Python-list wrote:
> How to people here deal with that?

Don't activate the venv for those programs then?
The point of a venv is that you only enter it when you actually want
that specific python stack.

Get yourself a terminal that can either multiplex, or add something like
tmux or screen to the mix if you frequently need other python tools
during development.
Or just install those in you venv, after all if you
do use them for dev they are part of your dependencies, so declare them
as such.

Still feels like a problem to me though.

Suppose you're working on a program which, for example, prints json to 
stdout. And suppose you want to use a tool like jq (let's call it pjq as 
an example) to process that output, by piping the output of your program 
to it:


    python your-program.py | pjq

That seems to me a very sensible thing to do. If pjq is written in C, 
C++, Rust, Ruby, PHP, Go, or whatever, itis not a problem at all. To the 
user of pjq, it shouldn't matter at all in what language it's written, 
and mostly it doesn't matter at all indeed.


But if pjq happens to be written in Python, it suddenly matters very 
much: it won't work in your venv (unless your venv happens to have the 
right modules).


There are ways around it of course:
- install the tool in your venv, like you say
- from outside the venv: venv/bin/python your_program.py | pjq
- from inside the venv: python your_program.py | interpreter> 
Or something like that. At least I think those should work, I haven't 
tested it.


But it feels to wrong to have to use such workarounds simply because pjq 
happens to be written in the same language as you're writing your 
program in.


--
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Roel Schroeven]

Op 3/03/2022 om 14:24 schreef computermaster360:

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in
practice? Do you even know how it works, or that there is such a thing
in Python?
- No, or at least not when balanced against the drawbacks as I perceive 
them.
- I have a hard time remembering how it works, which is the major 
drawback for me. I simply can't seem to wrap my head around it.

- Yes

I have used it maybe once. My issue with this construct is that
calling the second block `else` doesn't make sense; a much more
sensible name would be `then`.
There have been multiple proposals for a better name, but they all have 
their own drawbacks. There doesn't seem to be a clear winner.


Maybe a bit of an explanation of my dislike for the for-else construct. 
I can't remember what exactly it does and doesn't do, maybe because of 
the IMHO unfortunate naming or maybe because it's just an unusal 
construct, I don't know. While coding I never feel the need for for-else.
I like coding in a way where "every line expresses a single thought", as 
much as possible. That means that I don't mine creating short functions 
for things that in my mind otherwise break the flow of my code. So I 
often have short functions with a for loop and early returns. I have 
never seen an example of for-else that wouldn't be at least as clear 
with a little helper function (granted I haven't looked all that hard).


I'm googling for an example, but all I find are tutorial-type things 
that don't necessarily compare to real code. But it's the best I can do, 
so let's dive in. What they all seem to have in common is that they mix 
business logic and user interface (maybe precisely because of their 
tutorial nature), which I strive to avoid. For example, on 
https://www.geeksforgeeks.org/using-else-conditional-statement-with-for-loop-in-python/ 
I found this example:


    # Python 3.x program to check if an array consists
    # of even number
    def contains_even_number(l):
  for ele in l:
    if ele % 2 == 0:
  print ("list contains an even number")
  break

  # This else executes only if break is NEVER
  # reached and loop terminated after all iterations.
  else:
    print ("list does not contain an even number")

    # Driver code
    print ("For List 1:")
    contains_even_number([1, 9, 8])
    print (" \nFor List 2:")
    contains_even_number([1, 3, 5])

I would always refactor this even just for that mixing of business logic 
and printing stuff. Perhaps like this:


    def contains_even_number(lst):
    for element in lst:
    if element % 2 == 0:
    return True
    return False

    def print_contains_even_number(lst):
    if contains_even_number(lst):
    print("list contains an even number")
    else:
    print("list does not contain an even number")

    print("For List 1:")
    print_contains_even_number([1, 9, 8])
    print()
    print("For List 2:")
    print_contains_even_number([1, 3, 5])

Even without consciously avoiding for-else, it automatically disappears.
(In real code I would actually use any(element % 2 == 0 for element in 
lst) for something simple like this)



Now, imagine a parallel universe, where the for-else construct would
have a different behavior:

 for elem in iterable:
 process(elem)
 else:
 # executed only when the iterable was initially empty
 print('Nothing to process')

Wouldn't this be more natural? I think so. Also, I face this case much
more often than having detect whether I broke out of a loop early
(which is what the current for-else construct is for).
That's a different construct, also possibly useful. I think this would 
be more useful to me than the existing for-else.


--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Roel Schroeven]

Op 4/03/2022 om 8:18 schreef Chris Angelico:

On Fri, 4 Mar 2022 at 18:13, Dieter Maurer  wrote:
> One of my use cases for `for - else` does not involve a `break`:
> the initialization of the loop variable when the sequence is empty.
> It is demonstrated by the following transscript:
>
> ```pycon
> >>> for i in range(0):
> ...   pass
> ...
> >>> i
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'i' is not defined
> >>> for i in range(0):
> ...   pass
> ... else: i = None
> ...
> >>> i
> >>>
> ```
>
> For this use case, `else` is perfectly named.

What's the point of this? Why not just put "i = None" after the loop?
As I understand it: range(0) is just a (bad) example, it's actually 
about any arbitrary iterable. You don't know in advance if it's empty or 
not, and you want i to be initialized in all cases. (I don't think I 
have ever encountered that situation.)


You could easily solve this by placing "i = None" before the loop, but I 
guess in situations where you want to initialize i with the result of an 
expensive operation Dieter's method could be a reasonable solution.


This would actually be a good use case for computermaster360's proposal.

--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list