Re: Addition of a .= operator

[2QdxY4RzWzUUiLuE]

On 2023-05-21 at 06:11:02 +1200,
dn via Python-list  wrote:

> On 21/05/2023 05.54, Alex Jando wrote:
> > I have many times had situations where I had a variable of a certain type, 
> > all I cared about it was one of it's methods.
> > 
> > For example:
> > 
> > 
> > import hashlib
> > hash = hashlib.sha256(b'word')
> > hash = hash.hexdigest()
> > 
> > import enum
> > class Number(enum.Enum):
> >  One: int = 1
> >  Two: int = 2
> >  Three: int = 3
> > num = Number.One
> > num = num.value
> > 
> > 
> > Now to be fair, in the two situations above, I could just access the method 
> > right as I declare the object, however, sometimes when passing values into 
> > functions, it's a lot messier to do that.

Can you give an example, preferably one from an actual program, that
shows the mess?  Is it More Messier™ than the difference between the
following examples?

# example 1
hash = hashlib.sha256(b'word')
f(hash.hexdigest()) # call f with hash's hexdigest

# example 2
hash = hashlib.sha256(b'word')
hash = hash.hexdigest() # extract hash's hexdigest
f(hash) # call f with hash's hexdigest

Can you also show what your code would look like with a .= operator?

> > So what I'm suggesting is something like this:
> > 
> > 
> > import hashlib
> > hash = hashlib.sha256(b'word')
> > hash.=hexdigest()
> > 
> > import enum
> > class Number(enum.Enum):
> >  One: int = 1
> >  Two: int = 2
> >  Three: int = 3
> > num = Number.One
> > num.=value
> > 
> 
> A custom-class wrapper?
> Even, a decorator-able function?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Editing PEP-8, in particular "expected 2 blanks, found 1

[2QdxY4RzWzUUiLuE]

On 2023-05-02 at 20:39:35 +,
"Kevin M. Wilson via Python-list"  wrote:

> [...] Where can I edit these out of my IDE?

I doubt anyone will know unless you at least tell us which IDE you're
using.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RE: Weak Type Ability for Python

[2QdxY4RzWzUUiLuE]

On 2023-04-13 at 22:14:25 -0400,
avi.e.gr...@gmail.com wrote:

> I am looking at a data structure that is an object of some class and
> stores the data in any way that it feels like. But it may be a bit of
> a chameleon that shows one face or another as needed. I can write code
> now that simply adds various access methods to the class used and also
> provides a way to query if it supports some interfaces.

Python dicts act mostly like hash tables.  All by themselves, hash
tables are unordered (and in return for giving up that order, you get
O(1) access to an item if you know its key).

But when you ask a Python dict for the keys, you always get them in the
same order, skipping those that have been deleted since the last time
you asked, and appending the new keys to the end of the list in the
order in which you added them.

There's your chameleon.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Weak Type Ability for Python

[2QdxY4RzWzUUiLuE]

On 2023-04-12 at 22:47:17 -0400,
Dennis Lee Bieber  wrote:

>   REXX -- where everything is considered a string until it needs to be
> something else.

I see your REXX, and raise you an awk,¹ except that awk won't add a
string to a number, or a number to string, but it will concatenate in
both cases:

$ echo 1 a | awk '{print $1 $2}{print $1 + $2}'
1a
1

$ echo 1 a | awk '{print $2 $1}{print $2 + $1}'
a1
1

$ echo 1 2 | awk '{print $1 $2}{print $2 + $1}'
12
3

¹ GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.0, GNU MP 6.2.1)

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

Re: Weak Type Ability for Python

[2QdxY4RzWzUUiLuE]

On 2023-04-12 at 14:51:44 -0400,
Thomas Passin  wrote:

> On 4/12/2023 1:11 PM, Chris Angelico wrote:
> > On Thu, 13 Apr 2023 at 03:05, Ali Mohseni Roodbari
> >  wrote:
> > > 
> > > Hi all,
> > > Please make this command for Python (if possible):
> > > 
> > > > > > x=1
> > > > > > y='a'
> > > > > > wprint (x+y)
> > > > > > 1a
> > > 
> > > In fact make a new type of print command which can print and show strings
> > > and integers together.
> > > 
> > 
> > Try:
> > 
> > print(x, y)
> > 
> > ChrisA
> 
> It puts a space between "1" and "a", whereas the question does not want the
> space.  print(f'{x}{y}') would do it, but only works for variables named "x"
> and "y".

Or possibly print(x, y, sep='').

> As happens so often, the OP has not specified what he actually wants to do
> so we can only answer the very specific question.

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

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

[2QdxY4RzWzUUiLuE]

On 2023-04-01 at 08:16:46 -0700,
Andreas Eisele  wrote:

> BTW, there is another difference: built-in pow() deals with complex
> arguments, while functions in math won't accept them at all.

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

Re: Windows installer from python source code without access to source code

[2QdxY4RzWzUUiLuE]

On 2023-04-01 at 10:49:18 +1100,
Chris Angelico  wrote:

> [...] I don't have access to the Gmail source code but I'm using the
> service [...]

You have access to Gmail's front end source code.  Your web browser runs
it every time you use the service (and probably while you aren't using
the service, too).  My educated guess is that Google expended some
effort to hinder you from looking at and/or analyzing (or do you say
analysing?) that code, and that their lawyers will come knocking at your
metaphorical door if they so much as think you are using that code in
some way other than running it inside your web browser.  If only this
situation were a cruel April Fool's Day joke.

You don't have access to Gmail's back end source code.

Many/Most web apps follow this pattern to varying degrees.  I do not
know whether this setup meets the OP's requirements.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What kind of "thread safe" are deque's actually?

[2QdxY4RzWzUUiLuE]

On 2023-03-27 at 18:25:01 -0700,
Travis Griggs  wrote:

> "Deques support thread-safe, memory efficient appends and pops from
> either side of the deque with approximately the same O(1) performance
> in either direction.”

> (https://docs.python.org/3.11/library/collections.html?highlight=deque#collections.deque)

[...]

> I guess this surprised me. When I see “thread safe”, I don’t expect to
> get errors.

Even without threads, mutating a collection while iterating over it
usually results in bad things happening.

$ python
Python 3.10.10 (main, Mar  5 2023, 22:26:53) [GCC 12.2.1 20230201] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> x = collections.deque()
>>> x.append(44)
>>> x.append(55)
>>> x.append(66)
>>> x.append(77)
>>> x
deque([44, 55, 66, 77])
>>> for y in x:
 x.pop()

77
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: deque mutated during iteration

Concurrency just increases the likeliness of mutating while iterating.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday finking: IDE 'macro expansions'

[2QdxY4RzWzUUiLuE]

On 2023-03-18 at 11:49:24 +,
"Weatherby,Gerard"  wrote:

> For templating, I have two Python programs for starting new work. One
> generates a standalone Python program with the Python shebang, a
> __main__ which calls def main(), and logging and argparser
> intialization. The other generates a pyproject.toml /setup.cfg
> directory structure with a main.py referenced as a console
> script. from setup.cfg

You don't describe the process for using those programs, but if you
"have two Python programs," then it sounds like you're *not* using the
IDE/editor for that.

(I'm not judging, I'm trying to relate your answer to dn's original
question.)

For an opposing view, I'm much more likely to copy an old project (at
the command line, often with sed) and then use my editor to morph it
into a new project.  IME, unless there's an imposed process, those
templates and programs tend to experience bitrot, whereas going back to
an old program gives me the chance to keep it up to date w.r.t. what
I've learned more recently, which helps reinforce said learning.

> From: Python-list  on 
> behalf of dn via Python-list 
> Date: Thursday, March 16, 2023 at 6:59 PM
> To: 'Python' 
> Subject: Friday finking: IDE 'macro expansions'
> *** Attention: This is an external email. Use caution responding, opening 
> attachments or clicking on links. ***
> 
> It is a long, long, time since I've thrown one of these into the
> maelstrom of our musings.
> (have the nightmares receded?)
> 
> 
> Do you make use of your IDE's expansionist tendencies, and if-so, which
> ones?

[...]

-- 
I can eat glass, it does not hurt me.
Dan Sommers, http://www.tombstonezero.net/dan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday finking: IDE 'macro expansions'

[2QdxY4RzWzUUiLuE]

On 2023-03-17 at 11:55:38 +1300,
dn via Python-list  wrote:

> Do you make use of your IDE's expansionist tendencies, and if-so, which
> ones?

Expansionist tendencies.  Nice phrase.  :-)

> NB this is where vi/emacs enthusiasts start chuckling (polite term for
> 'insane cackling') ...

Long time (since the 1980s, when you had to edit config.h and compile it
yourself) insane emacs enthusiast and "Unix is my IDE" claimant here.  I
used one language that required a special editor because the "source
code" was a semi-compiled byte stream instead of ASCII.  A coworker once
awarded me a black belt in vi for knowing how to indent and unindent
code.

They made me write in Java at my last job; that language encourages IDEs
beause they deny that the underlying OS and tools exist at all.  I used
to say that some of my coworkers weren't writing Java, they were writing
IntelliJ.

Anyway, the short answer to your question is no.

I think the main reason is that there are/were too many editors in too
many contexts to start depending on such features.  What happens if I'm
editing on a target box instead of my desktop?  What if I'm helping a
coworker, and they use a different editor (different tools for different
programmers)?

> I haven't made use of such a tool, to-date - OK, yes, I have practised a
> high typing-speed (and accuracy). Puff, puff...

I, too, type relatively quickly, which definitely relieves some of the
appeal.  Saving a few keystrokes isn't worth the extra congnitive load
to remember how to use those features.  And by the time I edit the
template, it's more keystrokes (and usually cursor motion and
placeholder deletion keystrokes not related to the programming task at
hand) than if I had typed the full code in the first place.

> Also, at the time, I'm thinking in 'code', rather than about what tool might
> implement said ideas.

Exactly.  Any excursion away from the programming language and the
programming task at hand is disruptive.

I did finally train myself to use Emacs' dabbrev-expand function, which
completes the current "word" according to the previous occurrance of
that word, which lets me use longer identifiers without having to type
them out or copy/paste them.  That said, I often find myself typing
stuff out anyway, again because any deviation from writing code is a
deviation from writing code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lambda returning tuple question, multi-expression

[2QdxY4RzWzUUiLuE]

On 2023-03-10 at 22:16:05 -0500,
Thomas Passin  wrote:

> I'd make the pattern in this example even more understandable and less
> error-prone:
> 
> def update_pids(target):
> cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"]
> pids.update({target: subprocess.Popen(cmd)}) if not \
> pids[target] else None

I might be missing something, but how is that more understandable and
less error prone than any of the following:

if not pids[target]:
cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"]
pids.update({target: subprocess.Popen(cmd)})

or:

cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"]
pids[target] or pids.update({target: subprocess.Popen(cmd)})

or:

if pids[target]:
pass
else:
cmd = ["tail", "-n", "1", "-f", f"/var/log/{target}"]
pids.update({target: subprocess.Popen(cmd)})

Picking a nit, that's not a good place to continue that line with the
backslash, either.  IMO, "not pids[target]" should be atomic.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Baffled by readline module

[2QdxY4RzWzUUiLuE]

On 2023-03-09 at 19:11:56 -0800,
Grant Edwards  wrote:

> On 2023-03-10, 2qdxy4rzwzuui...@potatochowder.com 
> <2qdxy4rzwzuui...@potatochowder.com> wrote:

> If you run this application from the command line, you get command
> recall and editing when entering strings at the "cmd:" prompt?
> 
> #!/usr/bin/python
> while True:
> try:
> line = input('cmd: ')
> except EOFError:
> print()
> break
> print('You entered "%s"' % line)

In my case, no.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Baffled by readline module

[2QdxY4RzWzUUiLuE]

On 2023-03-10 at 12:57:48 +1100,
Chris Angelico  wrote:

> On Fri, 10 Mar 2023 at 12:56, Greg Ewing via Python-list
>  wrote:
> >
> > On 10/03/23 1:46 pm, Grant Edwards wrote:
> > > That's not how it acts for me. I have to "import readline" to get
> > > command line recall and editing.
> >
> > Maybe this has changed? Or is platform dependent?
> >
> > With Python 3.8 on MacOSX I can use up arrow with input()
> > to recall stuff I've typed before, without having to
> > import anything.
> >
> 
> import sys; "readline" in sys.modules
> 
> Is it? Might be that something's pre-importing it.

My ~/.pythonrc contains the following:

import readline
import rlcompleter
readline.parse_and_bind( 'tab: complete' )

IIRC, that's been there "forever," certainly back into Python2, and
probably back into Python1.  On my Arch Linux system Python 3.10.9, I
get readline behavior with or without those lines.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Baffled by readline module

[2QdxY4RzWzUUiLuE]

On 2023-03-10 at 11:02:52 +1100,
Chris Angelico  wrote:

> Traditional retirement: Work till you're 60 or 65 or whatever, then
> society pats you on the head, calls you a "senior citizen", and lets
> you go and be idle till you die (which might be prematurely soon).

Sounds like Free Four¹:

  The memories of a man in his old age
  Are the deeds of a man in his prime.

  You shuffle in the gloom of the sickroom
  And talk to yourself as you die.

Great tune.  Bad life.

> Direction-change retirement: Work till you can afford to zero out your
> income, then finally do what you've always wanted to do, but never had
> time because you spent so much of it earning money.

A little bit of that.  We live in the RV, and we have crisscrossed the
country more than once, coronavirus notwithstanding.

> Tell-the-next-generation: Work till you know so much that you're
> infinitely valuable, then spend the rest of your life empowering the
> next group of amazing people. See for instance: NASA.

And a little bit of that, too.  NASA would have been nice; I did my most
of my time in the commercial space, with a short break in the government
contracting business.

> Programmer retirement: At an early age, learn how to wield PHENOMENAL
> COSMIC POWER, and spend the next X years in an itty bitty working
> space, earning money. Eventually, upgrade to better living/working
> space. Eventually, downgrade to a small wooden box six feet below the
> ground. Never once relinquish the power. Never once abandon that
> feeling of mastery.

I was with you until that part of the small wooden box.  :-)

> We're not really an industry that has a concept of retirement.

Which is why I'm still here (on this mailing list, and a handful of
others like it).

Thanks for asking.

¹ https://www.azlyrics.com/lyrics/pinkfloyd/freefour.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Baffled by readline module

[2QdxY4RzWzUUiLuE]

On 2023-03-09 at 15:02:53 -0800,
Grant Edwards  wrote:

> Yeesh. What's _really_ embarassing is that I just stumbled across a
> small test program with which I had apparently figured this out 10-12
> years ago.  Must be about time to retire...

Retiring doesn't help.  :-)

I retired almost five years ago, and I just (within the past few days)
(re)discovered a command line parsing library I'd written about a year
and a half ago (i.e., after I retired).

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

Re: Regular Expression bug?

[2QdxY4RzWzUUiLuE]

On 2023-03-02 at 14:22:41 -0500,
jose isaias cabrera  wrote:

> For the RegExp Gurus, consider the following python3 code:
> 
> import re
> s = "pn=align upgrade sd=2023-02-"
> ro = re.compile(r"pn=(.+) ")
> r0=ro.match(s)
> >>> print(r0.group(1))
> align upgrade
> 
> 
> This is wrong. It should be 'align' because the group only goes up-to
> the space. Thoughts? Thanks.

The bug is in your regular expression; the plus modifier is greedy.

If you want to match up to the first space, then you'll need something
like [^ ] (i.e., everything that isn't a space) instead of that dot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7 range Function provokes a Memory Error

[2QdxY4RzWzUUiLuE]

On 2023-03-02 at 11:25:49 +,
Stephen Tucker  wrote:

> The range function in Python 2.7 (and yes, I know that it is now
> superseded), provokes a Memory Error when asked to deiliver a very long
> list of values.
> 
> I assume that this is because the function produces a list which it then
> iterates through.
> 
> 1. Does the  range  function in Python 3.x behave the same way?

No.

> 2. Is there any equivalent way that behaves more like a  for loop (that is,
> without producing a list)?

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

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

[2QdxY4RzWzUUiLuE]

On 2023-03-01 at 14:35:35 -0500,
avi.e.gr...@gmail.com wrote:

> What would have happened if all processors had been required to have
> some low level instruction that effectively did something in an atomic
> way that allowed a way for anyone using any language running on that
> machine a way to do a simple thing like set a lock or check it?

Have happened?  I don't know about "required," but processors have
indeed had such instructions for decades; e.g., the MC68000 from the
early to mid 1980s (and used in the original Apple Macintosh, but I
digress) has/had a Test and Set instruction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: No module named _socket, on windows

[2QdxY4RzWzUUiLuE]

On 2023-02-25 at 15:58:35 -0800,
ofek shulberg  wrote:

> On Monday, January 4, 2010 at 9:19:21 PM UTC+2, Gabriel Genellina wrote:
> > En Mon, 04 Jan 2010 14:24:22 -0300, louisJ  escribi�:
> > > I installed python 2.6 (from python.org) for windows XP, and then
> > > Pylab.
> > > When I type "import pylab" in a python shell it shows the error:
> > >
> > > ImportError: No module named _socket
> > Open the Python command line, type the following lines, and tell us what 
> > happens:
> > Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit 
> > (Intel)] on
> > win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import socket
> > >>> socket._socket
> > 
> > 
> > -- 
> > Gabriel Genellina
> 
> 
> hi Gabriel,
> i have the same problem and also pip is not installed for some reason, what 
> can i do?

Gabriel's post is thirteen years old and against a truly ancient version
of Python (on Windows XP, no less).  Please repost your question.
Include the OS and the version of Python you're using, and a copy/paste
of the error(s) you're receiving.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Evaluate once or every time

[2QdxY4RzWzUUiLuE]

On 2023-02-24 at 18:42:39 -0500,
Thomas Passin  wrote:

> VOWELS = 'aeiouAEIOU'
> is_vowel = 'y' in VOWELS
> 
> If I really needed them to be in a list, I'd probably do a list
> comprehension:
> 
> VOWEL_LIST = [ch for ch in VOWELS]

Why use a comprehension when a simple loop will do?  ;-)

No.  Wait.  That's not what I meant.

Why use a comprehension when the constructor will do?

VOWEL_LIST = list(VOWELS)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to read file content and send email on Debian Bullseye

[2QdxY4RzWzUUiLuE]

On 2023-02-04 at 17:59:11 -0500,
Thomas Passin  wrote:

> On 2/4/2023 10:05 AM, ^Bart wrote:
> > Hi guys,
> > 
> > On a Debian Bullseye server I have a lftp upload and after it I should
> > send an email.

[...]

> [...] you could run a shell script that sends the file with lftp, and
> depending on the return code uses xdg-email to send one of the two
> messages. This would probably be simpler than using Python.

xdg-email appears to be for interactive use (it opens the user's
"preferred email composer"); I think sendmail would work much better
from a script.

Otherwise, I had the same initial thought, to add to and/or build a
wrapper around the existing lftp script.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Organizing modules and their code

[2QdxY4RzWzUUiLuE]

On 2023-02-03 at 13:18:46 -0800,
transreductionist  wrote:

> Here is the situation. There is a top-level module (see designs below)
> containing code, that as the name suggests, manages an ETL pipeline. A
> directory is created called etl_helpers that organizes several modules
> responsible for making up the pipeline. The discussion concerns the
> Python language, which supports OOP as well as Structural/Functional
> approaches to programming.

> I am interested in opinions on which design adheres best to standard
> architectural practices and the SOLID principles. I understand that
> this is one of those topics where people may have strong opinions one
> way or the other. I am interested in those opinions.

Okay, I'll start:  unless one of extract, transform, or load is already,
or will certainly at some point become, complex/complicated enough to be
its own architectural module with its own architectural substructure; or
you're constructing specific ETL pipelines for specific ETL jobs at the
times the jobs are defined; then I think you're overthinking it.

Note that I say that speaking as a notorious overthinker.  ;-)

Keep It Simple:  Put all four modules at the top level, and run with it
until you falsify it.  Yes, I would give you that same advice no matter
what language you're using.

FWIW, I'm not a big fan of OO, but based on what little I know about
your ETL pipelines, I agree with you that it probably doesn't make a big
difference at this level.  Define solid (in pretty much any/every sense
of the word, capitalized or not) interfaces between your modules, and
write your code against those interfaces, whether OO or any other
paradigm.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make argparse accept "-4^2+5.3*abs(-2-1)/2" string argument?

[2QdxY4RzWzUUiLuE]

On 2023-01-29 at 16:51:20 +1100,
Cameron Simpson  wrote:

> They're unrelated. As others have mentioned, "--" is _extremely_ common;
> almost _all_ UNIX command like programmes which handle -* style options
> honour the "--" convention. _argparse_ itself honours that convention, as
> does getopt etc.

And why do UNIX programs behave this way?

Because POSIX says they should:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bool and int

[2QdxY4RzWzUUiLuE]

On 2023-01-26 at 12:12:30 -0500,
Dino  wrote:

> On 1/25/2023 5:42 PM, Chris Angelico wrote:
> 
> > 
> > Try this (or its equivalent) in as many languages as possible:
> > 
> > x = (1 > 2)
> > x == 0
> > 
> > You'll find that x (which has effectively been set to False, or its
> > equivalent in any language) will be equal to zero in a very large
> > number of languages. Thus, to an experienced programmer, it would
> > actually be quite the opposite: having it NOT be a number would be the
> > surprising thing!
> 
> I thought I had already responded to this, but I can't see it. Weird.
> 
> Anyway, straight out of the Chrome DevTools console:
> 
> x = (1>2)
> false
> 
> x == 0
> true
> 
> typeof(x)
> 'boolean'
> 
> typeof(0)
> 'number'
> 
> typeof(x) == 'number'
> false
> 
> So, you are technically correct, but you can see that JavaScript - which
> comes with many gotchas - does not offer this particular one.

When you start a new language, try to start from the beginning.  Yes,
you know other languages, to varying degrees, and the language you are
learning is very likely similar, at least superficially, in some way or
another, to one of those other languages.  Use that existing knowledge
to the extent that it is useful; be prepared to forget everything you
know.

Python's choice of type hierarchy is not at all uncommon, and it's only
a gotcha if you come in with a predetermined idea of how certain things
"should" work.  I've already noted that writing FORTRAN in any language
is a meme.

For a completely different take on booleans, take a look at Python's
logical "and" and "or" operators (*not* the arithmetic "|" and "&"
operators), which only sometimes return an actual boolean value.  Then
compare them to the "any" and "all" builtins, which came along much
later.  Idiomatic Python uses the right tool for the job *in Python*,
whether or not that same tool is or isn;'t the right tool for the same
job in some other language.

Python is like Lisp in that it (Python) has strong dynamic typing.  From
my Common Lisp REPL:

CL-USER> (let ((x (< 1 2)))
   (cons x (type-of x)))
(T . BOOLEAN)

CL-USER> (let ((x (> 1 2)))
   (cons x (type-of x)))
(NIL . NULL)

In English, the canonical "true" value in Lisp is T, and its type is
BOOLEAN.  Likewise, the canonical "false" value in Lisp is NIL, and its
type is NULL.  Out of the box, Lisp will not convert T or NIL to a
number.
-- 
https://mail.python.org/mailman/listinfo/python-list

Flamebait (was: Re: bool and int)

[2QdxY4RzWzUUiLuE]

On 2023-01-26 at 10:52:06 +,
"Weatherby,Gerard"  wrote:

> I can’t help but wonder if there exists some Java forum /mailing list
> going on about how horrible Python is.

Not some of them.  *All* of them.  Here's the summary:

  - Dynamic Typing causes defects and makes non-toy software projects
impossible.

  - Python is slow.

  - Significant Whitespace [insert pejorative here].

  - Python allows code to exist outside of methods, and methods to exist
outside of classes.  What's a function?

  - There is no backwards compatibility.

Many, if not most, languages are created as improvements over others,
because those others have serious flaws (whether those flaws are real or
perceived).  And even at that, the earliest languages were created
because cores, wires, and machine languages were extremely painful.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bool and int

[2QdxY4RzWzUUiLuE]

On 2023-01-25 at 23:11:37 +1100,
Chris Angelico  wrote:

> On Wed, 25 Jan 2023 at 22:55, <2qdxy4rzwzuui...@potatochowder.com> wrote:

> > So, I think what you're trying to say is that you prefer the razor sharp
> > quality of truthiness to the zen of explicit being better than implicit.
> 
> Not sure what you mean here. If you want to bring this back to the Zen
> of Python, I would reference "practicality beats purity". We can do
> arithmetic on integers and floats without having to explicitly cast
> one to the other, because there's really no point in distinguishing
> them. We can do that with booleans and other types, too.

My point was that we all have our own preferences and biases, and in
this case, I think you and I lean in opposite directions, and Python is
big enough for both of us.

> > To bring this back to Python (sorry), blurring the line between booleans
> > and integers is an old machine language trick, born of the days when we
> > measured memory in bytes (and large sums of cash!) rather than gigs[0].
> > In Python3, there's no more reason to use a boolean value as integer
> > (whether to accumulate values or to test a value against zero) as there
> > is to use a string (e.g., from an HTML form) as an integer.
> 
> Strongly disagree. There is PLENTY of practical value in using
> booleans as numbers. This is nothing to do with counting bytes, and
> everything to do with how useful it is in practice.

IMO, the difference in readability between

autothrust_last_dv *= AT_mode == AT.Idle;

and

if(AT_mode != AT.Idle)
autothrust_last_dv = 0;

outweighs the practicality, whether C, C#, Java, or Python (ignoring the
insignificant differences in syntax).

Maintainability, too:  as soon as there's something else to do when
AT_mode isn't AT.Idle, I'm going to rewrite the first one as the second
one anyway.  (No, I won't mess up the braces.)

I could argue that the only reason the first one is readable at all is
that we've both been exposed to languages where fanatics assume that
True is 1 and False is 0.  I've also written low-level code with
hardware fanatics who insist that True is 0 and False is -1 (or 255,
depending on how much math they know).  In a posix shell script (or a
program that knows it might be run inside such a script), 0 is "true"
and non-zero is "false."  My point here is that you have to understand
how to work within whatever environment you're using, and that future
programmers (and future you!)  will have to deal with your choices
regardless of their background, biases, and preferences.

> C# is a pain to work with because it fails on these points of
> practicality. I'm morbidly curious as to how C# fanatics justify this
> sort of thing, given that so many languages just DTRT without needing
> to be told.

They say that Perl is practical.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bool and int

[2QdxY4RzWzUUiLuE]

On 2023-01-25 at 12:14:50 +1100,
Chris Angelico  wrote:

> On Wed, 25 Jan 2023 at 10:32, <2qdxy4rzwzuui...@potatochowder.com> wrote:

> > The usual complaint is that some people write FORTRAN no matter what
> > language they're actually using.  Are you writing Python in C#?  ;-)

> But the way I have to write it in C# is a messed-up version of C:

There's your problem:  C# isn't C, it's Java.  Java looks like C, too,
but it isn't C, either.

> So the problem isn't that I'm trying to write Python in C#, but that
> I'm trying to write code that would work on pretty much *any other
> C-family language*, but doesn't work on C#. I could use those
> techniques in plenty of C-derived and C-inspired languages, but no
> not in C#, despite looking very much C-inspired. Unfortunately the
> truth is that C# is not *actually* C-inspired; it's really Microsoft
> Java, so it has all the stupidities of Java:

There.  Even ChrisA agrees with me.  ;-)

So, I think what you're trying to say is that you prefer the razor sharp
quality of truthiness to the zen of explicit being better than implicit.

To bring this back to Python (sorry), blurring the line between booleans
and integers is an old machine language trick, born of the days when we
measured memory in bytes (and large sums of cash!) rather than gigs[0].
In Python3, there's no more reason to use a boolean value as integer
(whether to accumulate values or to test a value against zero) as there
is to use a string (e.g., from an HTML form) as an integer.

[0] I remember meetings where the agenda was to allocate memory (yes, at
design time) for a particular value, and the answer was along the lines
of "you can have these five bits, and this would have taken a lot less
time had you told us sooner that you needed that value to persist across
input messages."

> But this is hardly a Python-versus-C# thing; it's Java versus most of
> the rest of the world, and C# feigns to be part of the C style while
> retaining the limitations of Java.

IMO, the problem started when Java tried to be too much like C to
attract (or should I say "trap"?) C developers.

> (My apologies if the Java entries look synthetic. It's because they
> are, and that's a consequence of me not having ANY reason to write
> Java code in, like, ever. In fact, I had to go and install a JDK just
> to confirm that Java really did have these limitations.)

They used Java at my last job (as in, the last job I had before I
retired), and it was absolutely awful, for any number of reasons, the
gymnastics (on many levels) required to support "primitive types" being
one of them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bool and int

[2QdxY4RzWzUUiLuE]

On 2023-01-25 at 08:58:06 +1100,
Chris Angelico  wrote:

> On Wed, 25 Jan 2023 at 08:22, MRAB  wrote:
> > For backwards compatibility, bool was made a subclass of int.
> 
> Plus, it's really REALLY handy in quite a lot of situations.
> 
> > > C# is pickier, which I guess is a good thing.
> >
> 
> Nope, not a good thing. Actually a highly frustrating thing on those
> occasions when I have to write C# code.

The usual complaint is that some people write FORTRAN no matter what
language they're actually using.  Are you writing Python in C#?  ;-)

There's a sweet spot somewhere that includes dynamic typing, high
powered global type inference and optimization systems, a thriving
community, and a metric [boatload] of rock solid libraries.

And an alomost fanatical devotion to the Pope.  :-/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make argparse accept "-4^2+5.3*abs(-2-1)/2" string argument?

[2QdxY4RzWzUUiLuE]

On 2023-01-22 at 18:19:13 -0800,
Jach Feng  wrote:

> 1) Modify the sys.argv by inserting an item '--' before parsing it, ie.
> sys.argv.insert(1, '--')
> args = parser.parse_args()

Please don't do that.  :-)

In my mind, sys.argv belongs to Python, not the application.  Instead,
pass a newly created argument list to parse_args:

args = parser.parse_args(['--'] + sys.argv)

This approach (adjusting the actual arguments) will work until your
program actually has options.

> 2) By adding an extra space character before the leading '-' sign, ie.
> e:\Works\Python>py infix2postfix.py " -4^2+5.3*abs(-2-1)/2"
> -4 2 ^ 5.3 -2 1 - abs * 2 / +
> 
> But no idea how it works? and if it can survive in a newer argparse 
> version?:-)

It works because argparse checks the first character of each argument,
and *doesn't* strip/trim whitespace.  So "-x" looks like an option, and
" -x" looks an argument.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[2QdxY4RzWzUUiLuE]

On 2023-01-19 at 12:59:21 -0500,
Thomas Passin  wrote:

> Well, it's an art, not a science [...]

+1

> # Create a plot
> g2 = (
>   ggplot(df2,
>   aes('Days Since Jan 22',  # Comments can clarify these params
>   + geom_point(size=.1, color='blue') # size, color params optional
>   + theme_bw() # Optional theme (background, grid color, ...)
>  )

You've got a comma followed by a plus sign in there, so I'm not exactly
sure where the parameters to which function begin and end.

When it starts to look like this, I begin breaking out the parameters:

label = 'Days Since Jan 22'
size = geom_point(size=.1, color='blue')
theme = theme_bw()
g2 = ggplot(df2, aes(label, size, theme))

> # Compose a long string:
> msg = ('A very long line .\n'
>   + 'Another long bit of text '
>   + 'plus another '
>   )

If all the pieces are constants, then Python will concatenate them for
you:

msg = ('A very long line .\n'
   'Another long bit of text '
   'plus another')

You can even mix in "f" strings:

msg = ('long line\n'
   f'left text {name} right text'
   'more here')

But watch out for missing spaces between the pieces!  :-)

> 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.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[2QdxY4RzWzUUiLuE]

On 2023-01-04 at 12:02:55 +,
"Weatherby,Gerard"  wrote:

> Dealing with stdout / stderr is bash is just syntax. I don’t always
> remember it off the top of my head but … stackoverflow.com.

https://tldp.org/LDP/abs/html/io-redirection.html

> On Linux at least it’s possible to pipe to arbitrary streams, it
> seems. The following uses bash to write “Hi” to the file “third”
> opened by Python. I determined the file was 5 empirically.

Empirically?

> import os
> import subprocess
> command= 'echo Hi >/dev/fd/5'
> fd = os.open("third",os.O_WRONLY|os.O_CREAT)

command = f"echo Hi >/dev/fd/{fd}"

Or:

command = f"echo Hi >&{fd}"

> os.set_inheritable(fd,True)
> 
> subprocess.run(('/usr/bin/bash','-c',command),close_fds=False)

By the time I'm that far down that path, I usually write a separate
function to call fork, open, close, and exec myself (old habits die
hard).  In the end, there's no reward for writing and maintaining shell
programs in Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[2QdxY4RzWzUUiLuE]

On 2023-01-03 at 21:24:20 +,
c.bu...@posteo.jp wrote:

> The main question here is why does Python deciecded to make all logs
> go to stderr?

It makes sense to send all logging to one destination, and stderr is
that place.

> Maybe I totally misunderstood the intention of logging.info()?! Isn't
> this the "usual applicaton output"?

Aha.  This seems to be the misconception.  "Usual" in the sense of "the
application is running as usual," but not in the sense of "the output
the users usually see."

Logging is the process where applications write details that ordinarily
aren't visible to the user.  Logs are for forensics, after the fact.
There is an entire universe of software for managing (writing, reading,
archiving, retrieving, searching, etc.) log files.

At my last job, we wrote gigabytes of compressed logs every hour, and
read roughly two or three out of a million entries to track down
questions from our users.  Users wouldn't have understood 99% of what
was in the logs anyway.

I also worked a lot in embedded systems, like telephone switches.  Users
(i.e., the people with the telephones) didn't have access to the
switches, but when things went wrong, I could look at the switches' logs
to get the their view of what happened.

> If not, what messages should go into logging.info()? Can you name me some
> examples?

INFO level messages usually track "regular" happy-path progress through
your application:  reading config files, calculating results, writing
report.  Again, not meant for users (who would have their own progress
meters, textual or graphical), but for tracking down problems when there
are problems.  For one example, the name of the config file, even if you
only tell the users that you found a config file.

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

Re: Need max values in list of tuples, based on position

[2QdxY4RzWzUUiLuE]

On 2022-11-12 at 15:03:10 +,
"Weatherby,Gerard"  wrote:

> Types are available if you want to use
> them. https://www.pythontutorial.net/python-basics/python-type-hints/

Python has always been a strongly typed language.

Recent changes have given it some level of static type checking in
addition to the dyunamic typing.

> From: Python-list  on 
> behalf of Pancho via Python-list 
> Date: Friday, November 11, 2022 at 6:28 PM
> To: python-list@python.org 
> Subject: Re: Need max values in list of tuples, based on position
> 
> That was one of the things I didn't like about Python. Lack of types and
> subsequent loss of intellisense is the thing I find hardest to deal with.

-- 
I can eat glass, it does not hurt me.
Dan Sommers, http://www.tombstonezero.net/dan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to manage python shebang on mixed systems?

[2QdxY4RzWzUUiLuE]

On 2022-11-07 at 11:56:19 +,
"Weatherby,Gerard"  wrote:

> Write the wrapper script.
> 
> #!/bin/bash
> if [ $(hostname) == "oldystem" ]; then
> exec /usr/bin/python $*
> else
> exec /usr/bin/python2 $*
> fi

Use "$@" (with the quotes) instead of a bare $*.  The former preserves
quoted arguments, while the latter does not.

Also, it's probably more robust to check explcitly for python2 instead
of depending on the hostname.  Renaming hosts isn't a common operation,
but in general, checking for what something *does* or *has* is better
than checking for what it *is* (hey, look:  duck typing!).

Implementing both suggestions yields this:

#! /bin/bash
if [ -x /usr/bin/python2 ]; then
exec /usr/bin/python2 "$@"
else
exec /usr/bin/python "$@"
fi

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

Re: Find the path of a shell command

[2QdxY4RzWzUUiLuE]

On 2022-10-12 at 17:43:18 +0100,
Paulo da Silva  wrote:

> Às 17:22 de 12/10/22, Tilmann Hentze escreveu:
> > Paulo da Silva  schrieb:
> > > I have python program that launches a detached rm. It works pretty well
> > > until it is invoked by cron! I suspect that for cron we need to specify
> > > the full path.
> > 
> > Probably you could use os.unlink[1] with no problem.
> No, because I need to launch several rm's that keep running after the script
> ends.

rm doesn't take that long.  Why are you detaching them?

(I'm not debating your point about cron.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Changing 'Scripts/*.exe'

[2QdxY4RzWzUUiLuE]

On 2022-10-04 at 14:55:36 +1300,
dn  wrote:

> On 04/10/2022 14.10, Meredith Montgomery wrote:
> > r...@zedat.fu-berlin.de (Stefan Ram) writes:
> > 
> >> Meredith Montgomery  writes:
> >>> Wouldn't it be great if it were portable by default?
> >>
> >>   I think under Windows there is a division of software
> >>   suggested by Microsoft, a division of software into
> >>   executable code and data (data may change in time).
> >>
> >>   The executable code is supposed to rest under
> >>   "C:\Program Files" the contents of which cannot be
> >>   modified by user processes easily. Program configuration
> >>   can be stored below "AppData" in the user directory.
> >>   It is supposed to be more secure when executable code
> >>   cannot be modified easily by user processes.
> >>
> >>   So far, Python has decided to ignore this and install
> >>   everything under AppData as I understand it. So one 
> >>   gets neither the security of "Program Files" nor the
> >>   possibility to move it to another directory easily.
> > 
> > Interesting.  I like portable things.  You copy from one place to
   ^
Copy what?  That's the crux of it.

On vintage (1980s? 1990s? way before OS X, anyway) Mac OS, I could copy
an alias (Mac's version of a symbolic link) to a floppy disk, walk (IOW,
"transfer via sneaker net") that alias to another Mac on the network,
and open *the original file* from that other Mac.  (I could even move
the file to another folder on the original Mac, but that didn't mean
much, because those old file systems were entirely flat (directories and
folders were an illusion maintained by the Finder).)

Permissions?  We don't need no stinkin' permissions!  ;-)

> > another and it just runs.  As it should.  Things should be simple.
> 
> +1

I like simple, portable things, too.  But this kind of simplicity
(applications looking in known locations for certain files) and this
kind of portability (allowing users to move those files) are at oods.
And that's before we consider security.

Also, [almost] by definition, Python virtual environments really blur
the lines between user, system, public, private, programs, and data.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to replace an instance method?

[2QdxY4RzWzUUiLuE]

On 2022-09-18 at 09:11:28 +,
Stefan Ram  wrote:

> r...@zedat.fu-berlin.de (Stefan Ram) writes (abbreviated):
> >types.MethodType( function, instance )
> >functools.partial( function, instance )
> >new_method.__get__( instance )
> 
>   I wonder which of these three possibilities expresses
>   the idea of creating a new method from a function and
>   an instance most clearly.

The first one.  And only the first one.

The second one requires too much inside knowledge of Python to make the
leap from currying to instance method.

The third one doesn't even mention the function.  Also, in Python, if
I'm applying dunder methods directly (it's okay to write them), then I'm
doing something wrong.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Mutating an HTML file with BeautifulSoup

[2QdxY4RzWzUUiLuE]

On 2022-08-19 at 20:12:35 +0100,
Barry  wrote:

> > On 19 Aug 2022, at 19:33, Chris Angelico  wrote:
> > 
> > What's the best way to precisely reconstruct an HTML file after
> > parsing it with BeautifulSoup?
> 
> I recall that in bs4 it parses into an object tree and loses the
> detail of the input.  I recently ported from very old bs to bs4 and
> hit the same issue.  So no it will not output the same as went in.
> 
> If you can trust the input to be parsed as xml, meaning all the rules
> of closing tags have been followed. Then I think you can parse and
> unparse thru xml to do what you want.

XML is in the same boat.  Except for "canonical form" (which underlies
cryptographically signed XML documents) the standards explicitly don't
require tools to round-trip the "source code."  The preferred method of
comparing XML documents is at the structural level rather than with
textual representations.  That way, the following two elements are the
same (and similar with a collection of sub-elements in a different order
in another document):



and



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

Re: Parallel(?) programming with python

[2QdxY4RzWzUUiLuE]

On 2022-08-09 at 17:04:51 +,
"Schachner, Joseph (US)"  wrote:

> Why would this application *require* parallel programming?  This could
> be done in one, single thread program.  Call time to get time and save
> it as start_time.  Keep a count of the number of 6 hour intervals,
> initialize it to 0.

In theory, you are correct.

In practice, [stuff] happens.  What if your program crashes?  Or the
computer crashes?  Or there's a Python update?  Or an OS update?  Where
does all that pending data go, and how will you recover it after you've
addressed whatever happened? ¹

OTOH, once you start writing the pending data to a file, then it's an
extremely simple leap to multiple programs (rather than multiple
threads) for all kinds of good reasons.

¹ FWIW, I used to develop highly available systems, such as telephone
switches, which allow [stuff] to happen, and yet continue to function.
It's pretty cool to yank a board (yes, physically remove it, without
warning) from the system without [apparently] disrupting anything.  Such
systems also allow for hardware, OS, and application upgrades, too
(IIRC, we were allowed a handful of seconds of downtime per year to meet
our availability requirements).  That said, designing and building such
a system for the sakes of simplicity and convenience of the application
we're talking about here would make a pretty good definition of
"overkill."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Register multiple excepthooks?

[2QdxY4RzWzUUiLuE]

On 2022-08-04 at 09:41:00 +0200,
Albert-Jan Roskam  wrote:

>Thank you both. I'll give this a try. I think it would be nice if
>the standard library function atexit.register would be improved,
>such that the registered functions would not only be called upon
>(a) normal program termination, but that one could also register
>functions that are called (b) upon error (c) unconditionally. Much
>like (a) try - (b) except - (c) finally.

There.  You've just designed the top level of a better behaved, more
robust application (completely untested):

on_normal_exit_funcs = list()
on_error_exit_funcs = list()
on_any_exit_funcs = list()

def run_exit_funcs(exit_funcs):
for func in exit_funcs:
try: func()
except e: maybe_do_some_logging(e)

try:
run_the_application()
run_exit_funcs(on_normal_exit_funcs)
except:
run_exit_funcs(on_error_exit_funcs)
finally:
run_exit_funcs(on_any_exit_funcs)

def register_normal_exit_func(f):
on_normal_exit_funcs.append(f)

def register_error_exit_func(f):
on_error_exit_funcs.append(f)

def register_any_exit_func(f):
on_any_exit_funcs.append(f)

No, really.  There are worse ways to build an extremely generic, fairly
minimalist application framework.

Season to taste,¹ add it to your personal (or company) toolbox, and
refine and improve it as things come up.  You may discover some number
of common exit functions that are useful across appliations, too.

¹ are you object oriented, functional, imperative, or something else?
do you like long names, short names, names that follow some existing
coding standard, non-English names? do you have a standardized
logging/exception library?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dictionary order?

[2QdxY4RzWzUUiLuE]

On 2022-08-02 at 07:50:52 +1000,
Chris Angelico  wrote:

> On Tue, 2 Aug 2022 at 07:48, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-08-01 at 13:41:11 -0700,
> > Dan Stromberg  wrote:
> >
> > > keys = [5, 10, 15, 14, 9, 4, 1, 2, 8, 6, 7, 12, 11]
> > >
> > > dict_ = {}
> > > for key in keys:
> > > dict_[key] = 1
> >
> > $ python
> > Python 3.10.5 (main, Jun  6 2022, 18:49:26) [GCC 12.1.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> [hash(x) for x in range(20)]
> > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
> >
> > Just sayin'.  :-)
> 
> Yes, but I'm pretty sure that's been true for a LONG time. The hashes
> for small integers have been themselves for as long as I can remember.
> But the behaviour of the dictionary, when fed such keys, is what's
> changed.

I'm not disputing either of those facts.  I'm pointing out that the
apparently arbitrary order of a mapping's keys becomes obvious when you
look at the hashes of those keys.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dictionary order?

[2QdxY4RzWzUUiLuE]

On 2022-08-01 at 13:41:11 -0700,
Dan Stromberg  wrote:

> keys = [5, 10, 15, 14, 9, 4, 1, 2, 8, 6, 7, 12, 11]
> 
> dict_ = {}
> for key in keys:
> dict_[key] = 1

$ python
Python 3.10.5 (main, Jun  6 2022, 18:49:26) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> [hash(x) for x in range(20)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]

Just sayin'.  :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter not working

[2QdxY4RzWzUUiLuE]

On 2022-08-01 at 18:53:47 +0100,
Matthew Barnett  wrote:

> On 01/08/2022 13:17, Daniel Lee wrote:
> > Hello, I my code with tkinter was working before, and now, it has many 
> > errors in it. I’m not sure what has happened. The results after running are 
> > below:
> > 
> > "D:\Python Projects\tes\venv\Scripts\python.exe" "D:/Python 
> > Projects/tes/main.py"
> > Traceback (most recent call last):
> >File "D:\Python Projects\tes\main.py", line 1, in 
> >  import tkinter as tk
> >File 
> > "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py",
> >  line 3, in 
> >  import tkinter.messagebox
> >File 
> > "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\messagebox.py",
> >  line 25, in 
> >  from tkinter.commondialog import Dialog
> >File 
> > "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\commondialog.py",
> >  line 13, in 
> >  from tkinter import Frame, _get_temp_root, _destroy_temp_root
> > ImportError: cannot import name 'Frame' from partially initialized module 
> > 'tkinter' (most likely due to a circular import) 
> > (C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py)
> > 
> > Process finished with exit code 1
> 
> The entry:
> 
>   File 
> "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py",
> line 3, in 
> import tkinter.messagebox
> 
> in the traceback does not look right to me. On my PC that file starts with a
> long docstring.

My tkinter/__init__.py, too.

Do you have (and did you create since the last time your code worked)
your own module called tkinter?  Is line 3 "import tkinter.messagebox"?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mailbox misbehavior with non-ASCII

[2QdxY4RzWzUUiLuE]

On 2022-07-29 at 23:24:57 +,
Peter Pearson  wrote:

> The following code produces a nonsense result with the input 
> described below:
> 
> import mailbox
> box = mailbox.Maildir("/home/peter/Temp/temp",create=False)
> x = box.values()[0]
> h = x.get("X-DSPAM-Factors")
> print(type(h))
> # 
> 
> The output is the desired "str" when the message file contains this:
> 
> To: recipi...@example.com
> Message-ID: <123>
> Date: Sun, 24 Jul 2022 15:31:19 +
> Subject: Blah blah
> From: f...@from.com
> X-DSPAM-Factors: a'b
> 
> xxx
> 
> ... but if the apostrophe in "a'b" is replaced with a
> RIGHT SINGLE QUOTATION MARK, the returned h is of type 
> "email.header.Header", and seems to contain inscrutable garbage.
> 
> I realize that one should not put non-ASCII characters in
> message headers, but of course I didn't put it there, it
> just showed up, pretty much beyond my control.  And I realize
> that when software is given input that breaks the rules, one
> cannot expect optimal results, but I'd think an exception
> would be the right answer.

Be strict in what you send, but generous is what you receive.

I agree that email headers are supposed to be ASCII (RFC 822, 2822, and
now 5322) all say that, but always throwing an exception seems a little
harsh, and arguably (I'm not arguing for or against) breaks backwards
compatibility.  At least let the exception contain, in its own
attribute, the inscrutable garbage after the space after the colon and
before next CR/LF pair.

> Is this worth a bug report?

If nothing else, the documentation could specify or disclaim the
existing behavior.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: More efficient code, but slower program

[2QdxY4RzWzUUiLuE]

On 2022-07-27 at 17:48:47 +0200,
Regarding "Re: More efficient code, but slower program,"
Cecil Westerhof via Python-list  wrote:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
> 
> > Cecil Westerhof  writes:
> >>values = [*range(100)]
> >
> >   In many cases, any iterable is just fine and a list is not
> >   required, just as peudo-random numbers often are just fine and
> >   real-world entropy is not required.
> 
> In this case both are. I must select (several times) a random element
> from the list. So I need the list.
> I also want the randomness to be as good as possible to make the
> 'simulation' as good as possible.

"[A]s good as possible" for simulations and tests may not require the
cryptographic quality numbers from SystemRandom.  Many/most pseudo
random number generators are optimized for statistically normalized
outputs, and are repeatable as a bonus (again, often a requirement for
certain types of simulations; YMMV).

Also, what if you shuffled the list first (e.g., with random.shuffle)
and then iterated through it directly?  Repeatedly removing arbitrary
elements from the middle of a list is potentially expensive.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Object in List : how?

[2QdxY4RzWzUUiLuE]

On 2022-07-24 at 19:47:38 -0500,
Khairil Sitanggang  wrote:

> Regarding [Peter Otten's] comment : "
> *However, usually object creation and initialization iscombined by allowing
> arguments to the initializer:*" , so which one of the two classes Node1,
> Node2 below is more common in practice? Option 2, I guess.

No.  Please use option 1.

Another option would be to expose b as an optional parameter with a
default value:

class Node:
def __init__(self, a, b=0):
self.a = a
self.b = self.calculation() if b == 0 else b

There are other ways to write that particular assignment to b (because
the default is 0), but the relevant concept for right now is that
callers *can* supply a value for b, but that they don't *have* to:

n1 = Node(a) # uses a default value for b
n2 = Node(a, 22) # overrides the default; use 22 instead

Designing APIs can be tricky, and it's not an exact science.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: calculate diff between dates

[2QdxY4RzWzUUiLuE]

On 2022-07-12 at 15:37:55 +0300,
נתי שטרן  wrote:

> I glad for any help

http://www.sscce.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[2QdxY4RzWzUUiLuE]

On 2022-06-21 at 17:04:45 +,
Avi Gross via Python-list  wrote:

> My problem with that idea is, believe it or not, that it is too negative. 
> What you meant to be seen as a dash is a minus sign to me. And both C and C++ 
> not only have both a pre and post autoincrement variable using ++x and x++, 
> they also have autodecrement operators using a minus sign such as --x and x-- 
> and it can get pretty weird trying to figure out if some code is legal, let 
> alone what it does, without parentheses. I mean what the heck does this do?
> 
> y = x++-++x

That code evokes (or at least can evoke) nasal demons.

https://en.wikipedia.org/wiki/Undefined_behavior
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ModuleNotFoundError

[2QdxY4RzWzUUiLuE]

On 2022-06-17 at 08:03:28 +,
Zoltan Szenderak  wrote:

> How do I reply to: Chris Angelico rosuav at gmail.com so it is listed
> on the Python list?

Please don't.  Please continue replying to python-list@python.org; that
way, other people can help you, and future programmers can find their
issues in the public archives.  ChrisA is a regular on this list, and
will see your replies on it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-09 at 04:15:46 +1000,
Chris Angelico  wrote:

> On Thu, 9 Jun 2022 at 04:14, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-06-09 at 03:18:56 +1000,
> > Chris Angelico  wrote:
> >
> > > On Thu, 9 Jun 2022 at 03:15, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > > >
> > > > On 2022-06-08 at 08:07:40 -,
> > > > De ongekruisigde  wrote:
> > > >
> > > > > Depending on the problem a regular expression may be the much simpler
> > > > > solution. I love them for e.g. text parsing and use them all the time.
> > > > > Unrivaled when e.g. parts of text have to be extracted, e.g. from 
> > > > > lines
> > > > > like these:
> > > > >
> > > > >   root:x:0:0:System 
> > > > > administrator:/root:/run/current-system/sw/bin/bash
> > > > >   dhcpcd:x:995:991::/var/empty:/run/current-system/sw/bin/nologin
> > > > >   nm-iodine:x:996:57::/var/empty:/run/current-system/sw/bin/nologin
> > > > >   avahi:x:997:996:avahi-daemon privilege separation 
> > > > > user:/var/empty:/run/current-system/sw/bin/nologin
> > > > >   sshd:x:998:993:SSH privilege separation 
> > > > > user:/var/empty:/run/current-system/sw/bin/nologin
> > > > >   geoclue:x:999:998:Geoinformation 
> > > > > service:/var/lib/geoclue:/run/current-system/sw/bin/nologin
> > > > >
> > > > > Compare a regexp solution like this:
> > > > >
> > > > >   >>> g = 
> > > > > re.search(r'([^:]*):([^:]*):(\d+):(\d+):([^:]*):([^:]*):(.*)$' , s)
> > > > >   >>> print(g.groups())
> > > > >   ('geoclue', 'x', '999', '998', 'Geoinformation service', 
> > > > > '/var/lib/geoclue', '/run/current-system/sw/bin/nologin')
> > > > >
> > > > > to the code one would require to process it manually, with all the 
> > > > > edge
> > > > > cases. The regexp surely reads much simpler (?).
> > > >
> > > > Uh...
> > > >
> > > > >>> import pwd # https://docs.python.org/3/library/pwd.html
> > > > >>> [x for x in pwd.getpwall() if x[0] == 'geoclue']
> > > > [pwd.struct_passwd(pw_name='geoclue', pw_passwd='x', pw_uid=992, 
> > > > pw_gid=992, pw_gecos='Geoinformation service', 
> > > > pw_dir='/var/lib/geoclue', pw_shell='/sbin/nologin')]
> > >
> > > That's great if the lines are specifically coming from your system's
> > > own /etc/passwd, but not so much if you're trying to compare passwd
> > > files from different systems, where you simply have the files
> > > themselves.
> >
> > In addition to pwent to get specific entries from the local password
> > database, POSIX has fpwent to get a specific entry from a stream that
> > looks like /etc/passwd.  So even POSIX agrees that if you think you have
> > to process this data manually, you're doing it wrong.  Python exposes
> > neither functon directly (at least not in the pwd module or the os
> > module; I didn't dig around or check PyPI).
> 
> So.. we can go find some other way of calling fpwent, or we can
> just parse the file ourselves. It's a very VERY simple format.

If you insist:

>>> s = 'nm-iodine:x:996:57::/var/empty:/run/current-system/sw/bin/nologin'
>>> print(s.split(':'))
['nm-iodine', 'x', '996', '57', '', '/var/empty', 
'/run/current-system/sw/bin/nologin']

Hesitantly, because this is the Python mailing list, I claim (a) ':' is
simpler than r'([^:]*):([^:]*):(\d+):(\d+):([^:]*):([^:]*):(.*)$', and
(b) string.split covers pretty much the same edge cases as re.search.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-09 at 03:18:56 +1000,
Chris Angelico  wrote:

> On Thu, 9 Jun 2022 at 03:15, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-06-08 at 08:07:40 -,
> > De ongekruisigde  wrote:
> >
> > > Depending on the problem a regular expression may be the much simpler
> > > solution. I love them for e.g. text parsing and use them all the time.
> > > Unrivaled when e.g. parts of text have to be extracted, e.g. from lines
> > > like these:
> > >
> > >   root:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash
> > >   dhcpcd:x:995:991::/var/empty:/run/current-system/sw/bin/nologin
> > >   nm-iodine:x:996:57::/var/empty:/run/current-system/sw/bin/nologin
> > >   avahi:x:997:996:avahi-daemon privilege separation 
> > > user:/var/empty:/run/current-system/sw/bin/nologin
> > >   sshd:x:998:993:SSH privilege separation 
> > > user:/var/empty:/run/current-system/sw/bin/nologin
> > >   geoclue:x:999:998:Geoinformation 
> > > service:/var/lib/geoclue:/run/current-system/sw/bin/nologin
> > >
> > > Compare a regexp solution like this:
> > >
> > >   >>> g = re.search(r'([^:]*):([^:]*):(\d+):(\d+):([^:]*):([^:]*):(.*)$' 
> > > , s)
> > >   >>> print(g.groups())
> > >   ('geoclue', 'x', '999', '998', 'Geoinformation service', 
> > > '/var/lib/geoclue', '/run/current-system/sw/bin/nologin')
> > >
> > > to the code one would require to process it manually, with all the edge
> > > cases. The regexp surely reads much simpler (?).
> >
> > Uh...
> >
> > >>> import pwd # https://docs.python.org/3/library/pwd.html
> > >>> [x for x in pwd.getpwall() if x[0] == 'geoclue']
> > [pwd.struct_passwd(pw_name='geoclue', pw_passwd='x', pw_uid=992, 
> > pw_gid=992, pw_gecos='Geoinformation service', pw_dir='/var/lib/geoclue', 
> > pw_shell='/sbin/nologin')]
> 
> That's great if the lines are specifically coming from your system's
> own /etc/passwd, but not so much if you're trying to compare passwd
> files from different systems, where you simply have the files
> themselves.

In addition to pwent to get specific entries from the local password
database, POSIX has fpwent to get a specific entry from a stream that
looks like /etc/passwd.  So even POSIX agrees that if you think you have
to process this data manually, you're doing it wrong.  Python exposes
neither functon directly (at least not in the pwd module or the os
module; I didn't dig around or check PyPI).

IMO, higher level functions to process such data is way better than a
[insert your own adjective/expletive here] regular expression that
collects the pieces into numbered groups rather than labeled fields.
Readability counts.

Yes, absolutely, use a regular expression when all else fails.  Don't
forget to handle all the edge cases!  (I assume that sane OSes preclude
colons in paths that are likely to come up in the local password
database, but I don't know what happens, e.g., when there's a reason for
GECOS to contain a colon.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-08 at 08:07:40 -,
De ongekruisigde  wrote:

> Depending on the problem a regular expression may be the much simpler
> solution. I love them for e.g. text parsing and use them all the time.
> Unrivaled when e.g. parts of text have to be extracted, e.g. from lines
> like these:
> 
>   root:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash
>   dhcpcd:x:995:991::/var/empty:/run/current-system/sw/bin/nologin
>   nm-iodine:x:996:57::/var/empty:/run/current-system/sw/bin/nologin
>   avahi:x:997:996:avahi-daemon privilege separation 
> user:/var/empty:/run/current-system/sw/bin/nologin
>   sshd:x:998:993:SSH privilege separation 
> user:/var/empty:/run/current-system/sw/bin/nologin
>   geoclue:x:999:998:Geoinformation 
> service:/var/lib/geoclue:/run/current-system/sw/bin/nologin
> 
> Compare a regexp solution like this:
> 
>   >>> g = re.search(r'([^:]*):([^:]*):(\d+):(\d+):([^:]*):([^:]*):(.*)$' , s)
>   >>> print(g.groups())
>   ('geoclue', 'x', '999', '998', 'Geoinformation service', 
> '/var/lib/geoclue', '/run/current-system/sw/bin/nologin')
> 
> to the code one would require to process it manually, with all the edge
> cases. The regexp surely reads much simpler (?).

Uh...

>>> import pwd # https://docs.python.org/3/library/pwd.html
>>> [x for x in pwd.getpwall() if x[0] == 'geoclue']
[pwd.struct_passwd(pw_name='geoclue', pw_passwd='x', pw_uid=992, 
pw_gid=992, pw_gecos='Geoinformation service', pw_dir='/var/lib/geoclue', 
pw_shell='/sbin/nologin')]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-07 at 23:07:42 +0100,
Regarding "Re: How to test characters of a string,"
MRAB  wrote:

> On 2022-06-07 21:23, Dave wrote:
> > Thanks a lot for this! isDigit was the method I was looking for and 
> > couldn’t find.
> > 
> > I have another problem related to this, the following code uses the code 
> > you just sent. I am getting a files ID3 tags using eyed3, this part seems 
> > to work and I get expected values in this case myTitleName (Track name) is 
> > set to “Deadlock Holiday” and myCompareFileName is set to “01 Deadlock 
> > Holiday” (File Name with the Track number prepended). The is digit test 
> > works and myCompareFileName is set to  “Deadlock Holiday”, so they should 
> > match, right?
> > 
> OT, but are you sure about that name? Isn't it "Dreadlock Holiday" (by
> 10cc)?

Edsger Dijkstra originally wrote Deadlock Holiday for his band, The
Semaphores.  10cc lost the race condition and had to change the lyrics.

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

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-08 at 07:29:03 +1000,
Chris Angelico  wrote:

> On Wed, 8 Jun 2022 at 07:24, Barry  wrote:
> >
> >
> >
> > > On 7 Jun 2022, at 22:04, Dave  wrote:
> > >
> > > It depends on the language I’m using, in Objective C, I’d use isNumeric, 
> > > just wanted to know what the equivalent is in Python.
> > >
> > > If you know the answer why don’t you just tell me and if you don’t, don’t 
> > > post!
> >
> > People ask home work questions here and we try to teach a student with 
> > hints not finished answers.
> > Your post was confused with a home work question.
> >
> 
> In the future, to make it look less like a homework question, show
> your current code, which would provide context. Last I checked,
> homework questions don't usually involve ID3 tags in MP3 files :)

The original question in this thread didn't say anything about MP3
files.  Jumping to that conclusion from strings like '05 Trinket' was
left as an exercise for the interested reader.  :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test characters of a string

[2QdxY4RzWzUUiLuE]

On 2022-06-07 at 21:35:43 +0200,
Dave  wrote:

> I’m new to Python and have a simple problem that I can’t seem to find
> the answer.

> I want to test the first two characters of a string to check if the
> are numeric (00 to 99) and if so remove the fist three chars from the
> string.

> Example: if “05 Trinket” I want “Trinket”, but “Trinket” I still want
> “Trinket”. I can’t for the life of work out how to do it in Python?

How would you do it without Python?

Given that if the string is called x, then x[y] is the y'th character
(where what you would call "the first character," Python calls "the
zeroth character"), describe the steps you would take *as a person* (or
in some other programming language, if you know one) to carry out this
task.

Translating that algorithm to Python is the next step.  Perhaps
https://docs.python.org/3/library/string.html can help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Changing calling sequence

[2QdxY4RzWzUUiLuE]

On 2022-05-15 at 14:44:09 +1000,
Chris Angelico  wrote:

> On Sun, 15 May 2022 at 14:27, dn  wrote:
> >
> > On 15/05/2022 11.34, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > > On 2022-05-15 at 10:22:15 +1200,
> > > dn  wrote:
> > >
> > >> That said, a function which starts with a list of ifs-buts-and-maybes*
> > >> which are only there to ascertain which set of arguments have been
> > >> provided by the calling-routine; obscures the purpose/responsibility
> > >> of the function and decreases its readability (perhaps not by much,
> > >> but varying by situation).
> > >
> > > Agreed.
> > >
> > >> Accordingly, if the function is actually a method, recommend following
> > >> @Stefan's approach, ie multiple-constructors. Although, this too can
> > >> result in lower readability.
> > >
> > > (Having proposed that approach myself (and having used it over the
> > > decades for functions, methods, procedures, constructors, ...), I also
> > > agree.)
> > >
> > > Assuming good names,¹ how can this lead to lower readability?  I guess
> > > if there's too many of them, or programmers have to start wondering
> > > which one to use?  Or is this in the same generally obfuscating category
> > > as the ifs-buts-and-maybes at the start of a function?
> > >
> > > ¹ and properly invalidated caches
> >
> > Allow me to extend the term "readability" to include "comprehension".
> > Then add the statistical expectation that a class has only __init__().

Aha.  In that light, yeah, in geeral, the more stuff there is, the
harder it is to get your head around it.  And even if I document the
class (or the module), no one makes the time to read (let alone
comprehend) the document, which *should* clarify all those things that
are hard to discern from the code itself.

> > Thus, assuming this is the first time (or, ... for a while) that the
> > class is being employed, one has to read much further to realise that
> > there are choices of constructor.
> 
> Yeah. I would generally say, though, that any classmethod should be
> looked at as a potential alternate constructor, or at least an
> alternate way to obtain objects (eg preconstructed objects with
> commonly-used configuration - imagine a SecuritySettings class with a
> classmethod to get different defaults).

I think opening up the class and sifting through its classmethods to
find the factory functions is what dn is talking about.  Such a design
also means that once I have a SecuritySettings object, its (the
instance's) methods include both instance and class level methods.  IMO,
classmethods were/are a bad idea (yes, I'm probably in the minority
around here, but someone has to be).  The first person to scream "but
discoverability" will be severely beaten with a soft cushion.

> > Borrowing from the earlier example:
> >
> > >   This would be quite pythonic. For example, "datetime.date"
> > >   has .fromtimestamp(timestamp), .fromordinal(ordinal),
> > >   .fromisoformat(date_string), ...
> >
> > Please remember that this is only relevant if the function is actually a
> > module - which sense does not appear from the OP (IMHO).

Note that datetime.date is a class, not a module.

> > The alternatives' names are well differentiated and (apparently#)
> > appropriately named*.

[...]

> > Continuing the 'have to read further' criticism (above), it could
> > equally-well be applied to my preference for keyword-arguments, in that
> > I've suggested defining four parameters but the user will only call the
> > function with either three or one argument(s). Could this be described
> > as potentially-confusing?

Potentially.  :-)

In a well designed *library*, common keywords across multiple functions
provide consistency, which is generally good.  Even a bit of redundancy
can be good for the same reason.

OTOH, when there's only one function, and it has a pile of keyword
parameters that can only be used in certain combinations, then it
definitely can be harder to read/understand/use than separate functions
with simpler interfaces.

> Yes, definitely. Personally, I'd split it into two, one that takes the
> existing three arguments (preferably with the same name, for
> compatibility), and one with a different name that takes just the one
> arg. That could be a small wrapper that calls the original, or the
> original could become a wrapper that calls the new one, or the main
> body could be refactored into a helper that they both call. It all
> depends what makes the most sense internally, because that's not part
> of the API at that point.
> 
> But it does depend on how the callers operate. Sometimes it's easier
> to have a single function with switchable argument forms, other times
> it's cleaner to separate them.

"Easier" and "cleaner" are very often orthogonal.  ;-)  (Rich Hickey
(creator of Clojure) talks a lot about the difference between "easy" and
"simple."  Arguemnts for and against Unix often involve similar terms.)

And "easier" or "cleaner" for whom?  The person writing the function(s)

Re: Changing calling sequence

[2QdxY4RzWzUUiLuE]

On 2022-05-15 at 10:22:15 +1200,
dn  wrote:

> That said, a function which starts with a list of ifs-buts-and-maybes*
> which are only there to ascertain which set of arguments have been
> provided by the calling-routine; obscures the purpose/responsibility
> of the function and decreases its readability (perhaps not by much,
> but varying by situation).

Agreed.

> Accordingly, if the function is actually a method, recommend following
> @Stefan's approach, ie multiple-constructors. Although, this too can
> result in lower readability.

(Having proposed that approach myself (and having used it over the
decades for functions, methods, procedures, constructors, ...), I also
agree.)

Assuming good names,¹ how can this lead to lower readability?  I guess
if there's too many of them, or programmers have to start wondering
which one to use?  Or is this in the same generally obfuscating category
as the ifs-buts-and-maybes at the start of a function?

¹ and properly invalidated caches
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tail

[2QdxY4RzWzUUiLuE]

On 2022-05-13 at 12:16:57 +0200,
Marco Sulla  wrote:

> On Fri, 13 May 2022 at 00:31, Cameron Simpson  wrote:

[...]

> > This is nearly the worst "specification" I have ever seen.

> You're lucky. I've seen much worse (or no one).

At least with *no* documentation, the source code stands for itself.  If
I can execute it (whatever that entails), then I can (in theory) figure
out *what* it does.  I still don't what it's *supposed* to do, and
therefore *cannot* know how well it does or doesn't "work,", but at
least source code is deterministic and unambiguous (except when it
isn't, but let's not go there).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Changing calling sequence

[2QdxY4RzWzUUiLuE]

On 2022-05-11 at 08:33:27 -0500,
"Michael F. Stemper"  wrote:

> I have a function that I use to retrieve daily data from a
> home-brew database. Its calling sequence is;
> 
> def TempsOneDay( year, month, date ):
> 
> After using it (and its friends) for a few years, I've come to
> realize that there are times where it would be advantageous to
> invoke it with a datetime.date as its single argument.
> 
> As far as I can tell, there are three ways for me to proceed:
> 1. Write a similar function that takes a single datetime.date
>as its argument.
> 2. Rewrite the existing function so that it takes a single
>argument, which can be either a tuple of (year,month,date)
>or a datetime.date argument.
> 3. Rewrite the existing function so that its first argument
>can be either an int (for year) or a datetime.date. The
>existing month and date arguments would be optional, with
>default=None. But, if the first argument is an int, and
>either of month or date is None, an error would be raised.
> 
> The first would be the simplest. However, it is obviously WET
> rather than DRY.

It's also the least disruptive to existing code and tests, and the most
clear to readers (whether or not they're familiar with said existing
code).

What pieces, exactly, do you think you would repeat, especially after
you extract the common logic into a new function that should be simpler
than either API-level function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tail

[2QdxY4RzWzUUiLuE]

On 2022-05-08 at 18:52:42 +,
Stefan Ram  wrote:

>   Remember how recently people here talked about how you cannot copy
>   text from a video? Then, how did I do it? Turns out, for my
>   operating system, there's a screen OCR program! So I did this OCR
>   and then manually corrected a few wrong characters, and was done!

When you're learning, and the example you tried doesn't work like it
worked on the video, you probably don't know what's wrong, let alone how
to correct it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python/New/Learn

[2QdxY4RzWzUUiLuE]

On 2022-05-05 at 16:51:49 -0700,
Grant Edwards  wrote:

> On 2022-05-05, Mats Wichmann  wrote:
> 
> > Without having any data at all on it, just my impressions, more
> > people these days learn from in-person or video experiences.
> 
> I've always been utterly baffled by video tutorials for
> programming. There must be people who prefer that format, but it seems
> like absolutely the worst possible option for me. You can't cut/paste
> snippets from the examples. You have to constantly pause them so you
> can try out examples. Sometimes it's not even easy to read the
> examples. Perhaps if there was an accompanying web page or PDF...

+1 (maybe more), except that an accompanying web page or PDF only solves
the problem of copying/pasting examples badly, at the expense of the
cognitive load to keep track of one more thing (because it's highly
unlikely that the web page or PDF tracks the video "automatically").

As far as easy-to-read examples go, writing them down doesn't always
help.  One of my physics textbooks used upsilon and nu to describe some
phenomenon related to lasers.  IIRC, the text, the math, and the physics
were pretty straightforward, until you looked at the fraction υ/ν in
something resembling Times Roman Italic (although, to be fair, once you
got that far, it was pretty obvious that it was upsilon over nu rather
than nu over upsilon).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Style for docstring

[2QdxY4RzWzUUiLuE]

On 2022-04-23 at 08:33:37 +1000,
Chris Angelico  wrote:

> On Sat, 23 Apr 2022 at 08:24, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-04-22 at 15:35:15 -0500,
> > "Michael F. Stemper"  wrote:
> >
> > > On 22/04/2022 14.59, Chris Angelico wrote:
> > > > On Sat, 23 Apr 2022 at 05:56, Michael F. Stemper
> > > >  wrote:
> > > > >
> > > > > I'm writing a function that is nearly self-documenting by its name,
> > > > > but still want to give it a docstring. Which of these would be
> > > > > best from a stylistic point of view:
> > > > >
> > > > >
> > > > > Tells caller whether or not a permutation is even.
> > > > >
> > > > > Determines if a permutation is even. (Alternative is that it's 
> > > > > odd.)
> > > > >
> > > > > Returns True if permutation is even, False if it is odd.
> > >
> > >
> > > >
> > > > I'd go with the third one, but "Return" rather than "Returns". Or
> > > > possibly "Test whether a permutation is even".
> > >
> > > "So let it be written. So let it be done."
> >
> > "Test whether a permutation is even," while technically factual, leaves
> > the reader to wonder what form the result takes, and what happens to
> > that result.
> 
> While it's definitely possible to have other results and other ways to
> deliver them, the return of a boolean would be the most obvious
> default.

Maybe, depending on the context and purpose of the application.

> > Do you want callers of the function also to assume that True means that
> > the permutation is even?  There are other reasonable strategies, such as
> > an enumerated type (whose items are Even, Odd, and FileNotFound), or
> > throwing an exception if the permutation is odd.
> 
> I'm assuming that the function is called something like "is_even()"
> and that it either is a method on a permutation object, or its
> parameters make it very clear what the permutation is.
> 
> If it returns an enumeration, I would say that in the docstring. If
> the docstring doesn't say, I would assume it returns True or False.

I think we're agreeing, but the OP didn't provide that information.
I've seen enough oddball (yes, that's my professional opinion :-)) APIs
(and worked with enough programmers from enough backgrounds) to know
that "most obvious default" is subjective.

> > I prefer the "return" (rather than "returns") version of the third
> > option.  Assuming that the programmers are familiar with the domain,
> > the other two leave out important information.

[...]

> We don't need to say "Figures out algorithmically whether the
> permutation is even. If it is, will return True; if it isn't, will
> return False; if something goes wrong, will raise an exception". This
> is Python; we know that if something goes wrong, an exception is
> raised. (Though it can help to say WHICH exception will be raised
> under WHAT circumstances). Some things are obvious.

No, we don't need to say it that way.  I believe that we do need to say
what the function returns under what circumstances.

If, in fact, the function in question is named is_permutation_even, then
it *is* as simple as the OP's third option, but not simpler.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Style for docstring

[2QdxY4RzWzUUiLuE]

On 2022-04-22 at 15:35:15 -0500,
"Michael F. Stemper"  wrote:

> On 22/04/2022 14.59, Chris Angelico wrote:
> > On Sat, 23 Apr 2022 at 05:56, Michael F. Stemper
> >  wrote:
> > > 
> > > I'm writing a function that is nearly self-documenting by its name,
> > > but still want to give it a docstring. Which of these would be
> > > best from a stylistic point of view:
> > > 
> > > 
> > > Tells caller whether or not a permutation is even.
> > > 
> > > Determines if a permutation is even. (Alternative is that it's odd.)
> > > 
> > > Returns True if permutation is even, False if it is odd.
> 
> 
> > 
> > I'd go with the third one, but "Return" rather than "Returns". Or
> > possibly "Test whether a permutation is even".
> 
> "So let it be written. So let it be done."

"Test whether a permutation is even," while technically factual, leaves
the reader to wonder what form the result takes, and what happens to
that result.  Yes, we'd all like to think that programmers are smart
enough to *assume* that the function returns the result of the test.
I've also seen functions that perform tests and then print the results
out, or write them to a database, or simply execute the tests for their
side effects (or leave it up to the individual tests to do something
with the result).

Do you want callers of the function also to assume that True means that
the permutation is even?  There are other reasonable strategies, such as
an enumerated type (whose items are Even, Odd, and FileNotFound), or
throwing an exception if the permutation is odd.

I prefer the "return" (rather than "returns") version of the third
option.  Assuming that the programmers are familiar with the domain, the
other two leave out important information.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why no list as dict key?

[2QdxY4RzWzUUiLuE]

On 2022-04-21 at 06:22:53 +0400,
Abdur-Rahmaan Janhangeer  wrote:

> Maybe hashes should point to an object rather than being the hash of an
> object themselves.
> Maybe the speed drop is not worth it.

Then you have a different problem.

x = [1, 2, 3]
y = [n for n in 1, 2, 3]

Those two lists (x and y) are separate but equal objects.  Being
separate, pointers to them would not be equal.  Being equal, they have
to have the same hash.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Comparing sequences with range objects

[2QdxY4RzWzUUiLuE]

On 2022-04-10 at 22:20:33 +0200,
Antoon Pardon  wrote:

> 
> 
> Op 9/04/2022 om 02:01 schreef duncan smith:
> > On 08/04/2022 22:08, Antoon Pardon wrote:
> > > 
> > > Well my first thought is that a bitset makes it less obvious to calulate
> > > the size of the set or to iterate over its elements. But it is an idea
> > > worth exploring.
> > > 
> > 
> > 
> > 
> > def popcount(n):
> >     """
> >     Returns the number of set bits in n
> >     """
> >     cnt = 0
> >     while n:
> >     n &= n - 1
> >     cnt += 1
> >     return cnt
> > 
> > and not tested,
> > 
> > def iterinds(n):
> >     """
> >     Returns a generator of the indices of the set bits of n
> >     """
> >     i = 0
> >     while n:
> >     if n & 1:
> >     yield i
> >     n = n >> 1
> >     i += 1
> > 
> Sure but these seem rather naive implementation with a time complexity of
> O(n) where n is the maximum number of possible elements. Using these would
> turn my O(n) algorithm in a O(n^2) algorithm.

O(n) where n is the expected number of elements.  The loops iterate once
for each bit actually contained in the set, which is usually [much] less
than the size of the universe.  If you have lots and lots of elements in
your sets, or your universe is large and n is a long integer, then these
may not be as efficient as other methods.  You know your data better
than we do.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get_deep()

[2QdxY4RzWzUUiLuE]

On 2022-04-03 at 18:01:58 +0300,
Kirill Ratkin via Python-list  wrote:

> It seems 'case if' should help with types:
> 
> case {"users": [{"address": {"street": street}}]} if isinstance(street,
> str):

reduce(lambda x, y: x[y], ["users", 0, "address", "street"], data)

Unless it's y[x] rather than x[y], and there might be a More Cleverer™
way to do it with getattr or one of its relatives instead of lambda.

> 02.04.2022 23:44, Marco Sulla пишет:
> > A proposal. Very often dict are used as a deeply nested carrier of
> > data, usually decoded from JSON. Sometimes I needed to get some of
> > this data, something like this:
> > 
> > data["users"][0]["address"]["street"]
> > 
> > What about something like this instead?
> > 
> > data.get_deep("users", 0, "address", "street")
> > 
> > and also, instead of this
> > 
> > try:
> >  result = data["users"][0]["address"]["street"]
> > except KeyError, IndexError:
> >  result = "second star"
> > 
> > write this:
> > 
> > data.get_deep("users", 0, "address", "street", default="second star")
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best practice for caching hash

[2QdxY4RzWzUUiLuE]

On 2022-03-12 at 21:45:56 +0100,
Marco Sulla  wrote:

[ ... ]

> So if I do not cache if the object is unhashable, I save a little
> memory per object (1 int) and I get a better error message every time.

> On the other hand, if I leave the things as they are, testing the
> unhashability of the object multiple times is faster. The code:
> 
> try:
> hash(o)
> except TypeError:
> pass
> 
> execute in nanoseconds, if called more than 1 time, even if o is not
> hashable. Not sure if this is a big advantage.

Once hashing an object fails, why would an application try again?  I can
see an application using a hashable value in a hashable situation again
and again and again (i.e., taking advantage of the cache), but what's
the use case for *repeatedly* trying to use an unhashable value again
and again and again (i.e., taking advantage of a cached failure)?

So I think that caching the failure is a lot of extra work for no
benefit.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[2QdxY4RzWzUUiLuE]

On 2022-03-04 at 11:14:29 -0500,
Dennis Lee Bieber  wrote:

>   Try to tell the difference between
> 
> afileand
> afile
> 
> when doing a directory listing.

Easy:  log in over a 110 baud modem, where the characters take almost as
much time as the beep.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: All permutations from 2 lists

[2QdxY4RzWzUUiLuE]

On 2022-03-01 at 19:12:10 -0500,
Larry Martell  wrote:

> If I have 2 lists, e.g.:
> 
> os = ["Linux","Windows"]
> region = ["us-east-1", "us-east-2"]
> 
> How can I get a list of tuples with all possible permutations?
> 
> So for this example I'd want:
> 
> [("Linux", "us-east-1"), ("Linux", "us-east-2"), ("Windows",
> "us-east-1"), "Windows", "us-east-2')]
> 
> The lists can be different lengths or can be 0 length. Tried a few
> different things with itertools but have not got just what I need.

[(o, r) for o in os for r in region]

Feel free to import itertools, but it's not really necessary.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to check if there is internet?

[2QdxY4RzWzUUiLuE]

On 2022-02-25 at 13:48:32 -0600,
"Michael F. Stemper"  wrote:

> On 25/02/2022 12.07, Abdur-Rahmaan Janhangeer wrote:

> > I have been following language feature proposals from various
> > languages. Some decide to avoid Python's route, but others have been
> > trying hard to catch up with Python.  One gleaming example is the
> > switch case. JS recently proposed pattern matching, referencing
> > Python and explaining why the proposal is a cool treatment of the
> > usecase.

> I'm not clear on what you mean here. JavaScript has had a switch/case
> construct since 1.2, in the late 1990s. As far as I can determine,
> python has no such thing, since PEP-3103 was rejected in 2007.

Python has a relatively new (as of version 3.10) "match" statement:

https://docs.python.org/3/reference/compound_stmts.html#the-match-statement
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to check if there is internet?

[2QdxY4RzWzUUiLuE]

On 2022-02-23 at 09:28:40 -0700,
Akkana Peck  wrote:

> 2qdxy4rzwzuui...@potatochowder.com writes:
> > I think someone said it way upthread:  don't check, just do whatever you
> > came to do, and it will work or it will fail (presumably, your program
> > can tell the difference, regardless of a past snapshot of being able to
> > retrieve data from an arbitrary URL).
> > 
> > EAFP, anyone?
>
> Yes, but the code being discussed is still helpful, if only for
> error handling: yes, the network isn't fully up, but *why" isn't it?
>
> while True:
> try:
> do_whatever_I_came_to_do()
> except NetworkError:
> net_config_with_good_error_detection()

Sure, after the fact, once things fail, diagnostics are useful.  The
questions that remain are when should you run them, how complex do they
have to be, and how reliable can they be?

> Aside from error handling, it's useful in a network-up script:
> when you've just enabled a network, it's good to check right then if
> there's a captive portal and deal with it. If you just assume that
> the first thing the user wants is to go to an http: page in a
> browser, and so don't bother to check for a captive portal,
> that'll be annoying for people who want to fetch IMAP mail,
> or run ssh, or load an https: page.

Honest questions:  If I'm captured by a portal, do I "have internet"?
If I don't "have internet," who and/or what should detect, report,
and/or fix it?  When?

(As a matter of fact, I'm one of those people who annoyingly has to deal
with captive portals when my only use for the internet is IMAP or SMTP.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to check if there is internet?

[2QdxY4RzWzUUiLuE]

On 2022-02-09 at 11:15:34 +0400,
Abdur-Rahmaan Janhangeer  wrote:

> I think for me having the internet means ability to request urls

You can always ask.

The real question is what will the response be?  ;-)

This entire exercise is a race condition, just like checking for that a
file exists before deleting it, or that it doesn't exist before creating
it.

If you "have internet" when you check, what assurance do you have that
you will still "have internet" when you actually want to use it?

And if you don't "have internet" when you check, when do you check
again?

I think someone said it way upthread:  don't check, just do whatever you
came to do, and it will work or it will fail (presumably, your program
can tell the difference, regardless of a past snapshot of being able to
retrieve data from an arbitrary URL).

EAFP, anyone?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to check if there is internet?

[2QdxY4RzWzUUiLuE]

On 2022-02-08 at 06:51:20 +1100,
Chris Angelico  wrote:

> Either way, though: would a person on Mars "have the internet"? Yes,
> but not the internet as we know it...

By current definition, they *can't* have the internet as we know it.

Wikipedia,¹ Mirrian-Webster,² and TechTerms.com³ (the first three that
came up in my search engine, which is admittedly Earthbound for now) all
use words like "global" and phrases like "across the world" or "around
the world," all of which arguably exclude Mars, or at least a network
that covers both Earth and Mars.

IMO, Mars and its current and future living beings are better off
without the World Wide Web, too.

¹ https://en.wikipedia.org/wiki/Internet
² https://www.merriam-webster.com/dictionary/Internet
³ https://techterms.com/definition/internet
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Waht do you think about my repeated_timer class

[2QdxY4RzWzUUiLuE]

On 2022-02-03 at 05:52:19 +0100,
Cecil Westerhof via Python-list  wrote:

> 2qdxy4rzwzuui...@potatochowder.com writes:
> 
> > FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> > fortnights, etc.) instead of making them wade through your code to find
> > the call to (and possibly the [broken] help text of) Timer.
> 
> You mean with docstring?

Docstring, comments, error/exception text, external documentation, URLs
or other references in the source code (docstring, comments), the name
of the object in question (e.g., instead of "interval," call it
"interval_seconds," or "seconds_between_runs").  *Something*.  Or more
than one of the above.  A reference to the Timer class's documentation.
There are a lot of options.

Pick a place (or more than one!) that will be fairly conspicuous in as
many situations to as many users (including future you) or potential
users (including your future code) as possible.

In a perfect world, you will receive feedback and/or use your own code,
and improve your choice(s) and method(s) over time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Waht do you think about my repeated_timer class

[2QdxY4RzWzUUiLuE]

On 2022-02-03 at 15:07:22 +1100,
Chris Angelico  wrote:

> On Thu, 3 Feb 2022 at 14:52, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2022-02-03 at 12:39:43 +1100,
> > Cameron Simpson  wrote:
> >
> > > You have:
> > >
> > > def _check_interval(self, interval):
> > > if not type(interval) in [int, float]:
> > > raise TypeError('{} is not numeric'.format(interval))
> > >
> > > This check is better written:
> > >
> > > if not isinstance(interval, (int,float)):
> > >
> > > which handles subclasses of these types (but note that bool subclasses
> > > int :-) normally we don't care), or behaviourally:
> > >
> > > try:
> > > interval = float(interval)
> > > except ValueError as e:
> > > raise TypeError(
> > > "cannot convert %s:%r to float: %s"
> > > % (type(interval).__name__, interval, e)) from e
> > >
> > > which tries to convert to float and fails if that does not work, which
> > > supports classes with a __float__ method (these classes are rare, but
> > > decimal.Decimal is one example).
> >
> > I think this can be simplified for time intervals to the following:
> >
> > if interval <= 0:
> > raise ValueError(...)
> 
> That's checking something quite different, though. Casting to float
> will accept anything that can be, well, cast to float, but checking
> for less than or equal to zero demands that it already be some sort of
> number. It's debatable which check is more correct, but certainly this
> is not a simplification of the other code, it's a distinctly different
> validation.

Okay, "simplified" isn't quite the right word.  Given two examples (with
known deficiencies) and no actual use cases or specifications, I added a
third example, which I believed was simpler (and arguably better in one
or more ways, which I explained), than the others.

> > which accepts non-negative real values; throws ValueError for negative
> > real values; and TypeError for other stuff, including complex numbers
> > (pathological types notwithstanding).  One thing that doesn't work right
> > is NaNs, but I'm sure it's not the only code that acts weirdly when
> > faced with a NaM (curiously, Timer accepts a NaN, but the text I get
> > from help(Timer) in Python 3.10.2 is, well, broken).
> 
> Strange. The text I get in 3.11.0a1 is fine. But in any case, there's
> always the docs on the web.
> 
> https://docs.python.org/3/library/threading.html#timer-objects

help(Timer) is built into my REPL (and likely consumed by development
systems and IDEs everywhere).  No web necessary.

> > FWIW, I'd find some way to tell users the units (seconds, milliseconds,
> > fortnights, etc.) instead of making them wade through your code to find
> > the call to (and possibly the [broken] help text of) Timer.
> 
> In anything in Python, assume that the unit is seconds. With anything
> that accepts floats (where these can be distinguished from integers),
> assume the unit is seconds. If it accepts micro or nanoseconds, it'll
> almost certainly be called "high resolution timer" (unless it accepts
> two args, sec and us/ns, but that's pretty obvious), so you can
> generally exclude those too. The only real question is whether
> sleep(int) takes seconds or milliseconds, which isn't a problem here.
> 
> Citation: I've slept in many many programming languages and
> frameworks. Which sounds seriously weird, but you're all programmers,
> you know what I mean :)

I've slept in enough programming environments to know better than to
assume anything.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Waht do you think about my repeated_timer class

[2QdxY4RzWzUUiLuE]

On 2022-02-03 at 12:39:43 +1100,
Cameron Simpson  wrote:

> You have:
> 
> def _check_interval(self, interval):
> if not type(interval) in [int, float]:
> raise TypeError('{} is not numeric'.format(interval))
> 
> This check is better written:
> 
> if not isinstance(interval, (int,float)):
> 
> which handles subclasses of these types (but note that bool subclasses 
> int :-) normally we don't care), or behaviourally:
> 
> try:
> interval = float(interval)
> except ValueError as e:
> raise TypeError(
> "cannot convert %s:%r to float: %s"
> % (type(interval).__name__, interval, e)) from e
> 
> which tries to convert to float and fails if that does not work, which 
> supports classes with a __float__ method (these classes are rare, but 
> decimal.Decimal is one example).

I think this can be simplified for time intervals to the following:

if interval <= 0:
raise ValueError(...)

which accepts non-negative real values; throws ValueError for negative
real values; and TypeError for other stuff, including complex numbers
(pathological types notwithstanding).  One thing that doesn't work right
is NaNs, but I'm sure it's not the only code that acts weirdly when
faced with a NaM (curiously, Timer accepts a NaN, but the text I get
from help(Timer) in Python 3.10.2 is, well, broken).

FWIW, I'd find some way to tell users the units (seconds, milliseconds,
fortnights, etc.) instead of making them wade through your code to find
the call to (and possibly the [broken] help text of) Timer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: AttributeError: 'NoneType' object has no attribute 'get'

[2QdxY4RzWzUUiLuE]

On 2022-01-06 at 14:21:48 -0700,
Mats Wichmann  wrote:

> And at a more meta level:  many functions in the Python world return
> None as an indication that the operation did not succeed.  It's useful
> because in many circumstances None is an "out of band" value - one
> that could not happen naturally - and thus returning it provides an
> easy way for the caller to check for success or failure.

Errors should never pass silently.

Unless explicitly silenced.

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

Exceptions aren't perfect, but when something fails, I'd much rather
have an exception raised and thrown at me than to get back None.  An
exception is immediate,¹ but None often ends up causing trouble far
away¹ from where the actual failure occurred.

¹ in space and in time
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why operations between dict views return a set and not a frozenset?

[2QdxY4RzWzUUiLuE]

On 2022-01-05 at 08:30:30 +1100,
Cameron Simpson  wrote:

> On 04Jan2022 21:03, Marco Sulla  wrote:
> >On Tue, 4 Jan 2022 at 19:38, Chris Angelico  wrote:
> >> [...] should the keys view be considered
> >> frozen or not? Remember the set of keys can change (when the
> >> underlying dict changes).
> >
> >Well, also the items can change, but they are returned as tuples with
> >2 elements.
> >
> >It seems to me that the stdlib, when something should return a
> >sequence, prefers to return a tuple. So I expected the same preference
> >for frozenset over set.
> >
> >> It's not difficult to construct a frozenset from a set.
> >
> >This sentence has the commutative property :)
> 
> Indeed.
> 
> But speaking for myself, I may well want to perform additional work on 
> the object returned. Making a copy of it for tht purpose seems very 
> wasteful (imagine the set is quite large). A modifiable version can be 
> used immediately with no time or space cost. And it can be left alone if 
> it is to be unchanged.  If I got a frozenset back I would inherently 
> have to copy it to do "modifying work".

Unless the additional work is to use it as a dictionary key, or to add
it to an existing [necessarily mutable!] set.  Then again, that's not
work *on* the object returned, that's additional work *with* the object
returned.

We could go around and around on this all day.  :-)

Python began with the premise of mutability.  IIRC, many attempts at
immutable class instances (for use in sets or as dictionary keys) have
run into the same issues Marco Sulla is having.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

[2QdxY4RzWzUUiLuE]

On 2021-11-18 at 23:16:32 -0300,
René Silva Valdés  wrote:

> Hello, I would like to report the following issue:
> 
> Working with floats i noticed that:
> 
> int(23.99/12) returns 1, and
> int(23.999/12) returns 2
> 
> This implies that int() function is rounding ...

It's not int() that's doing the rounding; that second numerator is being
rounded before being divided by 12:

Python 3.9.7 (default, Oct 10 2021, 15:13:22) 
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 23.999
24.0
>>> (23.999).hex()
'0x1.8p+4'

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

Re: Syntax not understood

[2QdxY4RzWzUUiLuE]

On 2021-11-05 at 06:28:34 +1100,
Chris Angelico  wrote:

> On Fri, Nov 5, 2021 at 6:23 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-11-04 at 14:36:48 -0400,
> > David Lowry-Duda  wrote:
> >
> > > > x_increment, y_increment = (scale * i for i in srcpages.xobj_box[2:])
> > > >
> > > > (scale * i for i in srcpages.xobj_box[2:]) is a generator, a single
> > > > object, it should not be possible to unpack it into 2 variables.
> > >
> > > If you know the exact number of values in the generator, you can do
> > > this. Here is an oversimplified example.
> > >
> > >   l = [0, 1, 2, 3, 4, 5]
> > >   a, b = (elem * 10 for elem in l[:4])
> > >   print(a, b) # prints 40 50
> > >
> > > This is very fragile code and I would recommend against using it.
> >
> > How is that any more fragile than any other operation that destructs (or
> > doesn't) a tuple?
> >
> 
> The only part that's fragile, in my opinion, is (from the initial
> post) that it's using removal syntax to slice off some, which is
> fragile against the original input length:
> 
> x_increment, y_increment = (scale * i for i in srcpages.xobj_box[2:])
> 
> But since it says "box", I would start by assuming that it has four
> elements. (They might be x1,y1,x2,y2 or x,y,w,h but it'll almost
> always be four.) So it's not TOO fragile, when working with boxes, but
> it is a little less clear that thing[2:] will always give exactly two
> results.

I won't disagree that most boxes are going to be described by four
elements, in which case slicing off the first two *should* leave two
more (presumably x_increment and y_increment).

So if you're saying that all that's missing is a description of
srcpages.xobj_box, then I agree.  :-)  But such is life on a mailing
list where posters don't always give their questions the context they
deserve.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax not understood

[2QdxY4RzWzUUiLuE]

On 2021-11-04 at 14:36:48 -0400,
David Lowry-Duda  wrote:

> > x_increment, y_increment = (scale * i for i in srcpages.xobj_box[2:])
> > 
> > (scale * i for i in srcpages.xobj_box[2:]) is a generator, a single
> > object, it should not be possible to unpack it into 2 variables.
> 
> If you know the exact number of values in the generator, you can do 
> this. Here is an oversimplified example.
> 
>   l = [0, 1, 2, 3, 4, 5]
>   a, b = (elem * 10 for elem in l[:4])
>   print(a, b) # prints 40 50
> 
> This is very fragile code and I would recommend against using it.

How is that any more fragile than any other operation that destructs (or
doesn't) a tuple?

Is the following fragile:

quotient, remainder = divmod(numerator, denominator)

Would you surround it with try/except, or always unpack it defensively?

result = divmod(numerator, denominator)
if len(result) == 2:
quotient, remainder = result
else:
raise SomeException("divmod didn't work")

If I know where a generator (or an iterator, or a tuple, or a list) came
from, and it's documented to contain/yield a known quantity of values,
then why is it fragile to depend on that?

On the other hand, yes, if I build code that depends on a lot of
unstated relationships between values of questionable (or unknown)
origin, then I am definitely asking for trouble.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 09:21:34 +1000,
Chris Angelico  wrote:

> ... read off a hex dump and see E8
> 03 and instantly read it as "1,000 little-endian".

ITYM 000,1 little-endian.  ;-)

(Or possibly 000.1, depending on your locale.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 09:21:34 +1000,
Chris Angelico  wrote:

> On Wed, Sep 29, 2021 at 9:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-09-29 at 11:38:22 +1300,
> > dn via Python-list  wrote:
> >
> > > For those of us who remember/can compute in binary, octal, hex, or
> > > decimal as-needed:
> > > Why do programmers confuse All Hallows'/Halloween for Christmas Day?
> >
> > That one is also very old.  (Yes, I know the answer.  No, I will not
> > spoil it for those who might not.)  What do I have to do to gain the
> > insight necessary to have discovered that question and answer on my own?
> 
> You'd have to be highly familiar with numbers in different notations,
> to the extent that you automatically read 65 and 0x41 as the same
> number ...

I do that.  And I have done that, with numbers that size, since the late
1970s (maybe the mid 1970s, for narrow definitions of "different").

There's at least one more [sideways, twisted] leap to the point that you
even think of translating the names of those holidays into an arithmetic
riddle.

> ... Or, even better, to be able to read off a hex dump and see E8 03
> and instantly read it as "1,000 little-endian".

59535 big endian.  Warningm flamebait ahead:  Who thinks in little
endian?  (I was raised on 6502s and 680XX CPUs; 8080s and Z80s always
did things backwards.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT: AttributeError

[2QdxY4RzWzUUiLuE]

On 2021-09-29 at 11:38:22 +1300,
dn via Python-list  wrote:

> For those of us who remember/can compute in binary, octal, hex, or
> decimal as-needed:
> Why do programmers confuse All Hallows'/Halloween for Christmas Day?

That one is also very old.  (Yes, I know the answer.  No, I will not
spoil it for those who might not.)  What do I have to do to gain the
insight necessary to have discovered that question and answer on my own?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 10:44:02 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 10:40 AM Skip Montanaro
>  wrote:
> >
> > Woo hoo! It's installed. The ultimate error was a missing turbojpeg.h
> > file. Thank goodness for the apt-file command. I was able to track
> > that down to the libturbojpeg0-dev package, install that, and after a
> > bit more fussing around now have jpegdupes installed.
> >
> > Thanks for the help,
> >
> 
> Sweet! I like stories that have happy endings.
> 
> (No compilers were harmed in the making of this.)

Nor compiler authors/vendors/maintainers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 04:16:58 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 4:04 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-09-28 at 03:23:53 +1000,
> > Chris Angelico  wrote:
> >
> > > On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  
> > > wrote:
> > > >>
> > > >> Those are all warnings. Are there any errors that follow them?
> > > >
> > > >
> > > > Maybe I just missed the actual errors, but the compiler exit status was 
> > > > 1, so there must have been. I'll give it another try.
> > >
> > > Yeah, one of the annoying things of building large C packages is when
> > > the maintainers don't care about warnings, and then legit errors get
> > > lost in the spam.
> >
> > It's also possible that the compiler is running in a "warnings are
> > errors" mode.  Hack the Makefile (or equivalent) at your own peril.
> >
> > One of the annoying things about warnings is that they're not standard,
> > so squelching them under one compiler makes another compiler (or a
> > different version of the same compiler) whine.  IIRC, a compliant C
> > compiler can issue a warning for anything it wants, including "this
> > variable name contains too many vowels" or "this is a computer, and
> > today may be Tuesday."
> >
> > In many ways, the engineering pieces of software engineering remain in
> > their infancy.  *sigh*
> 
> But that's kinda the point of having different compilers. Warnings
> that we consider fairly standard today didn't exist in the past, and
> someone had to be the first to add them. If the C language had to
> mandate every warning, it'd take forever to make changes.

That is indeed one benefit of having different compilers and compilers
that improve over time.  It's also a nuisance when the compiler in your
development/unit test environment produces different warnings than
either cross compiler for your target environments (plural).

In Python, it's more likely that MSVC, MinGW, LLVM, and gcc choose
different warnings, and that no collection of settings supresses them
all.  Present C projects contain oodles of conditional compilation,
often controlled by the preprocessor; achieving ideal results can be,
well, "tricky."  It's not a matter of not caring.

At some point, it comes down to a question of ignoring a warning vs.
cluttering up your code (preprocessor or otherwise) with extra
conditionals.  Or being stuck with a warning about unneeded defensive
programming vs. being stuck with a warning about possible arithmetic
overflow on your 32-bit target.

I agree that the standard shouldn't regulate warnings.  I'm also saying
that sometimes, it's a pain that it doesn't, and that not every warning
is the package maintainer's fault.  :-)

> I don't think that warnings-are-errors mode is a good thing though.
> They should remain just as warnings. (And with the most popular
> compilers, using the compilation options as specified in their own
> makefile, maintainers should ideally try to ensure that there are as
> few warnings as possible.)

Ideally, yes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 03:23:53 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  
> wrote:
> >>
> >> Those are all warnings. Are there any errors that follow them?
> >
> >
> > Maybe I just missed the actual errors, but the compiler exit status was 1, 
> > so there must have been. I'll give it another try.
> 
> Yeah, one of the annoying things of building large C packages is when
> the maintainers don't care about warnings, and then legit errors get
> lost in the spam.

It's also possible that the compiler is running in a "warnings are
errors" mode.  Hack the Makefile (or equivalent) at your own peril.

One of the annoying things about warnings is that they're not standard,
so squelching them under one compiler makes another compiler (or a
different version of the same compiler) whine.  IIRC, a compliant C
compiler can issue a warning for anything it wants, including "this
variable name contains too many vowels" or "this is a computer, and
today may be Tuesday."

In many ways, the engineering pieces of software engineering remain in
their infancy.  *sigh*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Subject: Re: Posts from gmane no longer allowed?

[2QdxY4RzWzUUiLuE]

On 2021-09-26 at 17:40:18 -0700,
Grant Edwards  wrote:

> On 2021-09-26, Mats Wichmann  wrote:
> > On 9/26/21 10:38, 2qdxy4rzwzuui...@potatochowder.com wrote:
> >> On 2021-09-26 at 11:21:08 -0500,
> >
> >> No.  I use mbsync (formerly isync) to synchronize my gmail account with
> >> a local maildir folder, and while mbsync does send the app password
> >> (over TLS) to google every few minutes, it doesn't need the second
> >> factor.  Or at least it hasn't so far (it's been a couple of years).  I
> >> do get periodic nags from google because I'm using a "less secure"
> >> method than their web page to access my mail, but I ignore them.
> 
> Are you using an app-specific password?

Yes.  It was a hoop, but not a big one.  No, wait, I mean it wasn't a
small, flaming, poison spiked hoop; i.e., it was fairly simple to jump
through.

> > Just be aware, because It's Google, this will change again at some
> > point and you'll lose access.
> 
> Of course. That's half the fun of using Google's services. ;)

If it changes, I'll just forward incoming mail to my main (non-google)
account and not look back.  If I didn't need the account to access the
google store on my android phone, I'd would have abandoned it long ago.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Subject: Re: Posts from gmane no longer allowed?

[2QdxY4RzWzUUiLuE]

On 2021-09-26 at 11:21:08 -0500,
Grant Edwards  wrote:

> [...] Do you need the 2nd factor every time you connect to GMail via a
> browser or Android Gmail app? Or just the first time for each
> browser/device?  A bit of studying seems to be in order no matter
> what. :)

No.  I use mbsync (formerly isync) to synchronize my gmail account with
a local maildir folder, and while mbsync does send the app password
(over TLS) to google every few minutes, it doesn't need the second
factor.  Or at least it hasn't so far (it's been a couple of years).  I
do get periodic nags from google because I'm using a "less secure"
method than their web page to access my mail, but I ignore them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[2QdxY4RzWzUUiLuE]

On 2021-09-25 at 15:20:19 -0500,
"Michael F. Stemper"  wrote:

> ... For instance, if
> I modeled a fuel like this:
> 
>   
> ton
> 21.96
> 18.2
>   
> 
> and a generating unit like this:
> 
>   
> 
>   
>   
>   
>   
> 
> 
>   
>   
>   
>   
> 
>   
> 
> why would the fact that I could have chosen, instead, to model
> the unit of measure as an attribute of the fuel, or its name
> as a sub-element matter? Once the modeling decision has been
> made, all of the decisions that might have been would seem to
> be irrelevant.

Disclaimer:  I am not a big XML fan, for a number of reasons
already stated in this thread.

That said, please do include units in elements like heat_content,
whether or not it's Joules/kilogram/K, and price, even if is the
local currency in the only country to which your data applies.
If there's a standard for your industry, or your company, or on
some other level, then at least document what it is and that
you're using it, so that the next person (which may be you a
year from now) doesn't have to guess.

You also never know when someone else on the other side of the
planet will notice your work and try to duplicate it and/or
update it (again, even if it's you).  The fewer assumptions
that person has to make, the better.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Polymorphic imports

[2QdxY4RzWzUUiLuE]

On 2021-09-22 at 05:10:02 +1000,
Chris Angelico  wrote:

> You can dynamically import modules using importlib.import_module(),
> but an easier way might just be a conditional import:
> 
> # client/__init__.py
> if some_condition:
> import module_a_default as module_a
> else:
> import module_a_prime as module_a
> 
> Now everything that refers to client.module_a.whatever will get the
> appropriate one, either the original or the alternate.

+1

> Alternatively, since you are talking about paths, it might be easiest
> to give everything the same name, and then use sys.path to control
> your import directories. Not sure which would work out best.

-1

Please don't do that.  Mutable shared and/or global state (i.e.,
sys.paths) is the root of all evil.  And homegrown crypto and date
libraries.  And those funny red hats.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[2QdxY4RzWzUUiLuE]

On 2021-09-11 at 18:21:17 +0100,
Alan Gauld via Python-list  wrote:

> On 11/09/2021 15:41, Peter J. Holzer wrote:
> 
> > How is C's do/while loop more horrible than Pascal's repeat/until? 
> 
> Because it is very hard to spot or distinguish from a normal
> while loop.
> 
> while condition ;
> 
> Is a valid (and fairly common) loop in C
> 
> so code that has
> 
> do{
> code
> }
> while condition;
> 
> Looks, for non-trivial cases, like a lot of code followed
> by an empty while loop.
> 
> The do is easy to miss  and the while loop disguised as
> a repeat termination is confusing.

Well, yeah, except that only a macro would ever write it that way.  :-)

At the very least, the code would be indented (making it easier to spot
the "do," before or after you see the while; and my apologies if you
intended it that way and it got lost somewhere between your intent and
my monitor):

do {
code;
}
while(condition);

(Side question:  why put the "{" next to the "do," but the "}" and the
"while" on separate lines?)

And I would put the while on the same line as the closing brace (which
is also where I put the "else" in an if statement):

do {
code;
} while(condition);
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[2QdxY4RzWzUUiLuE]

On 2021-09-10 at 15:08:19 -0600,
Joe Pfeiffer  wrote:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:

> >   The existence of statements like "break" renders 
> >   proof techniques for loops (such as Hoare's) with
> >   their invariants and inference rules unapplicable.
> 
> Also the reason to avoid repeat-until loops:  the loop "invariant" isn't
> the same on the first iteration as on subsequent iterations.

I am by no means an expert, nor likely even a neophyte, but why would
the loop invariant not be the same on the first iteration?

I can certainly see that the exit condition may not make sense at the
beginning of the first iteration (e.g., there is not yet any data to
compare to the sentinel), but ISTM that claiming that the exit condition
is a loop invariant isn't kosher (because all you're claiming is that
the compiler works).

I can also see that certain state information may not be captured until
the end of the first iteration.  But presumably said state information
can change from iteration to iteration, so I can't see how you'd derive
an invariant involving it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Contorted loops

[2QdxY4RzWzUUiLuE]

On 2021-09-09 at 22:33:16 +,
Stefan Ram  wrote:

>   One can think of a language where every loop is exited this
>   way, the only loop construct would be
> 
> loop
> ...
> 
>   and it would /always/ have to be exited via enclosed breaks.

I'm not quite sure what you mean by "one can," but that's how the simple
form of Common Lisp's loop macro works.  Friendlier looping constructs
are built with other macros on top of that one and/or its underlying
mechanism.¹

¹ The underlying mechanism is the moral equivalent of a Python suite
that can also contain tags and unconditional jumps to those tags, aka
"goto"s.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on writing a while loop for rolling two dice

[2QdxY4RzWzUUiLuE]

On 2021-09-06 at 20:11:41 -0400,
Avi Gross via Python-list  wrote:

> And in the python version, has anyone made a generator that returned
> NULL or the like so you can say uselessly:
> 
> for ( _ in forever() ) ...

while "forever":
...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Scraping of Google Map to get the address of locations for given geocodes.

[2QdxY4RzWzUUiLuE]

On 2021-09-02 at 20:12:19 -0300,
Michio Suginoo  wrote:

> I have the following question regarding how to scrape Google Map to get
> address based on a given list of geocodes.
> Given a list of geocodes (latitude; longitude) of locations, I would like
> to scrape municipalities of all the spots in the list. How can I do that?
> 
> For example, I have
> 
>   lat  lon
> 
> 1) -34.5722317  -58.4314464
> 
> 2) -34.553906   -58.4520949
> 
> 3) -34.5661444  -58.4964289
> 
> 4) -34.5648053  -58.4431567
> 
> 5) -34.5664089  -58.4323004
> 
> 6) -34.5664089  -58.4323004
> 
> 
> 
> And I want to get the name of municipality (city/town), or alternatively
> the address, of each location.
> 
> 
> I would appreciate it, if anyone can advise me how to do that.

Is scraping Google Map a hard requirement?

Both geopy¹ and geocoder² can translate those coordinates into street
addresses directly, and their documentation even explains how to bypass
the libraries and go straight to the service providers.

¹ https://geopy.readthedocs.io/en/latest/
² https://geocoder.readthedocs.io/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico  wrote:

> On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> > What about Phoenix?  In the winter, it's the same time there as it is in
> > San Francisco, but in the summer, it's the same time there as it is in
> > Denver (Phoenix doesn't observe Daylight Saving Time).
> 
> I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> as Phoenix, but in summer, Los Angeles changes its clocks away, and
> Denver changes to happen to be the same as Phoenix.

Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST.  San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.

> At least the US has governed DST transitions. As I understand it, any
> given city has to follow one of the standard time zones, and may
> EITHER have no summer time, OR transition at precisely 2AM/3AM local
> time on the federally-specified dates. (I think the EU has also
> mandated something similar for member states.)

That's my understanding, too.

> If we could abolish DST world-wide, life would be far easier. All the
> rest of it would be easy enough to handle.

Agreed.

> ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> timezone change ...

Yeah, I read about that somewhere.  Remember when the Pope declared that
September should skip a bunch of days?

> > Having lived in the United States my entire life (and being a nerd), I
> > can confirm that (1) I'm used to it and handle it as well as possible,
> > but (2) many people are not and don't.
> 
> Yup, absolutely. I've been working internationally for a number of
> years now, so my employment has been defined by a clock that isn't my
> own. I got used to it and developed tools and habits, but far too many
> people don't, and assume that simple "add X hours" conversions
> suffice.

Way back in the 1990s, I was working with teams in Metro Chicago, Tel
Aviv, and Tokyo (three separate teams, three really separate time zones,
at least two seaprate DST transition dates).  I changed my wristwatch to
24 hour time (and never looked back).  I tried UTC for a while, which
was cute, but confusing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 08:36:55 +1200,
dn via Python-list  wrote:

> ... there is less consideration about working-out what time it is in
> Pune cf Kolkata, than between (say) San Francisco and Denver -
> although they are in the same country, are they in the same time-zone,
> or not?  (they aren't!)

What about Phoenix?  In the winter, it's the same time there as it is in
San Francisco, but in the summer, it's the same time there as it is in
Denver (Phoenix doesn't observe Daylight Saving Time).

And then there's Indiana, a medium size state that tends to get ignored
(they used to advertise "there's more than just corn in Indiana").  Most
of Indiana is in US/Eastern, but the cities that are (for practical
purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

ChrisA is right; you can't make this [stuff] up.

Having lived in the United States my entire life (and being a nerd), I
can confirm that (1) I'm used to it and handle it as well as possible,
but (2) many people are not and don't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: name for new Enum decorator

[2QdxY4RzWzUUiLuE]

On 2021-05-27 at 20:23:29 -0700,
Regarding "name for new Enum decorator,"
Ethan Furman  wrote:

> Greetings!
> 
> The Flag type in the enum module has had some improvements, but I find it
> necessary to move one of those improvements into a decorator instead, and
> I'm having a hard time thinking up a name.
> 
> What is the behavior?  Well, a name in a flag type can be either canonical
> (it represents one thing), or aliased (it represents two or more things).
> To use Color as an example:
> 
> class Color(Flag):
> RED = 1# 0001
> GREEN = 2  # 0010
> BLUE = 4   # 0100
> PURPLE = RED | BLUE# 0101
> WHITE = RED | GREEN | BLUE # 0111
> 
> The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are
> aliases for certain flag combinations.  But what if we have something like:
> 
> class Color(Flag):
> RED = 1# 0001
> BLUE = 4   # 0100
> WHITE = 7  # 0111
> 
> As you see, WHITE is an "alias" for a value that does not exist in the Flag
> (0010, or 2).  That seems like it's probably an error.  But what about this?
> 
> class FlagWithMasks(IntFlag):
> DEFAULT = 0x0
> 
> FIRST_MASK = 0xF
> FIRST_ROUND = 0x0
> FIRST_CEIL = 0x1
> FIRST_TRUNC = 0x2
> 
> SECOND_MASK = 0xF0
> SECOND_RECALC = 0x00
> SECOND_NO_RECALC = 0x10
> 
> THIRD_MASK = 0xF00
> THIRD_DISCARD = 0x000
> THIRD_KEEP = 0x100
> 
> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are
> aliasing values that don't exist, but it seems intentional and not an error.
> 
> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator to verify that a Flag has no
> missing aliased values that can be used when the programmer thinks it's
> appropriate... but I have no idea what to call it.
> 
> Any nominations?

Exhaustive?

I see two qualitatively different kinds of enums:  those that can/should
be "or"ed together (e.g., RED, GREEN) and those that cannot (e.g.,
FIRST_ROUND, FIRST_CEIL, and FIRST_TRUNC).  The idea of a "missing"
value doesn't seem to apply to the second type (because defining
FIRST_TRUNC as FIRST_ROUND | FIRST_CEIL is nonsensical).  I don't quite
know what that may or may not suggest as far as names go, but it may
give someone else an idea.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not found in the documentation

[2QdxY4RzWzUUiLuE]

On 2021-04-26 at 18:24:18 -0700,
elas tica  wrote:

> [...] I was expecting to find [a description of what str returns for
> various types] in the Built-in Types section from the PSL
> documentation. The representation returned by str over a complex
> number is not stated. The same for fraction objects [...]

Assuming that PSL is the Python Standard Library,
https://docs.python.org/3/library/functions.html#func-str says:

[...] str(object) returns object.__str__(), which is the “informal”
or nicely printable string representation of object [...]

IMO, an exhaustive list of exactly what that means for every type, even
the built in types, is unnecessary, and could create maintenance or
compatibility issues.

Is there a reason you need that information?  What would you do with it
if you had it?  Completely speculatively on my part, would repr
(https://docs.python.org/3/library/functions.html#repr) meet your
need(s) better than str?
-- 
https://mail.python.org/mailman/listinfo/python-list