Re: Terminal Emulator (Posting On Python-List Prohibited)

[Karsten Hilbert via Python-list]

Am Sun, May 19, 2024 at 10:45:09PM +0100 schrieb Barry via Python-list:

> > On 18 May 2024, at 16:27, Peter J. Holzer via Python-list 
> >  wrote:
> >
> > I don't think Linux users have to deal with venvs
>
> Modern debian (ubuntu) and fedora block users installing using pip.
> You must use a venv to pip install packages from pypi now.

Which makes one wonder how one is supposed to package Python
applications requiring modules not yet packaged by Debian.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Re: Extract lines from file, add to new files

[Karsten Hilbert via Python-list]

> On Tue, 30 Jan 2024, Karsten Hilbert wrote:
>
> > It doesn't need to. It just sends the (pre-personalized-by-Python) mail 
> > files.
>
> Karsten,
>
> In which case, I might as well have Python format and send the messages. :-)

Certainly. But it seems you are wrestling with Python. Might as well reduce the 
attack surface.

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

Aw: Re: Re: Extract lines from file, add to new files

[Karsten Hilbert via Python-list]

> > Why not foxus on just the part you think you are better off using python,
> > namely personalization ?
> >
> > Create personalized files and send them with your trusted mailx solution ?
>
> Karsten,
>
> Too much time. And while mailx accepts the '-a' option for attachments but
> has none for individual salutations.

It doesn't need to. It just sends the (pre-personalized-by-Python) mail files.

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

Aw: Re: Extract lines from file, add to new files

[Karsten Hilbert via Python-list]

> For 30 years I've used a bash script using mailx to send messages to a list
> of recipients. They have no salutation to personalize each one. Since I want
> to add that personalized salutation I decided to write a python script to
> replace the bash script.

Why not foxus on just the part you think you are better off using python, namely
personalization ?

Create personalized files and send them with your trusted mailx solution ?

That'll take out wrestling with smptlib et al.

Karsten

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

Re: mypy question

[Karsten Hilbert via Python-list]

Am Sat, Jan 13, 2024 at 09:20:00PM +0100 schrieb Karsten Hilbert via 
Python-list:

> > I was wondering if
> > your type hint for queries shouldn't be the following.
> >
> > queries:list[dict[str,str]|dict[str,list]|dict[str,dict[str, dict[str, 
> > Ant]]]

Wait, not really. Let me give an example. Here's three times
the same query (as far as PostgreSQL is concerned, after
having been passed through psycopg2):

queries = [
{
'SQL': 'SELECT 1'
},
{
'SQL': 'SELECT %s',
'args': [1]
},
{
'SQL': 'SELECT %(value)s',
'args': {'value': 1}
}
]

The value for key "SQL" will always be str-like.

The value for "args" can be a list or a dict itself.

If "args" is a dict it will be of type [str, Any].

That's what I am trying to tell mypy.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mypy question

[Karsten Hilbert via Python-list]

Am Fri, Jan 12, 2024 at 02:23:43PM +0100 schrieb Antoon Pardon via Python-list:

> > queries:list[dict[str, str | list | dict[str, Any]]]=None,
> >
> >into
> >
> > "List[Dict[str, Union[str, List[Any], Dict[str, Any"
> >
> >seems accurate. I just don't understand why list[dict[str,
> >str]] should not pass that construct.
>
> Sorry for the late reaction

ne'er mind ya

> I was wondering if
> your type hint for queries shouldn't be the following.
>
> queries:list[dict[str,str]|dict[str,list]|dict[str,dict[str, dict[str, Ant]]]
>
> My impression at this moment is that you are write something like: dict[str, 
> str | int] as
> as shorthand for dict[str, str] | dict[str, int].

I do.

> But those two are different types.

A-ha ! In what way ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mypy question

[Karsten Hilbert via Python-list]

Thanks to all. I ended up using Sequence for the list part
and Mapping for the dict part, which does require "import
typing" which I would rather have avoided.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: mypy question

[Karsten Hilbert via Python-list]

> I'm fairly sure your database queries don't actually give you strings or
> dicts, right?  You probably get lists (or iterators) of tuples and
> somewhere you convert them to the arguments you are feeding to
> run_queries().

Ah, no, those queries are enshrined within the middleware as Python strings
with placeholdders. When in need of being run they are assembled into
a list of dicts-enriched-with-arguments-per-query (and fed to run_queries()).

As to what queries *give* me: I have set up psycopg2 to, indeed, hand
me a list of dicts (DictRow instances, that is). Those are then used
in display rather than being fed to run_queries().

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

Aw: Re: Re: mypy question

[Karsten Hilbert via Python-list]

> It occurs to me that you could simplify things if you converted those
> plain query strings to dicts:
>
> 'SELECT 1' --> {'SQL': 'SELECT 1'}

Ha, indeed. There's likely not that many "simple string SQL queries"
in that codebase so I shall take it as an opportunity to refactor them.

So, at least that much good has come from the mypy hint ;-)

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

Aw: Re: mypy question

[Karsten Hilbert via Python-list]

Dear Thomas,

thanks for taking the time to look into my issue.

Maybe it helps if I explain what I want (sorry that my web mailer does not 
respect
indentation, I will insert dots).

I want a function to run SQL queries:

run_queries(conn, queries):
...for q in queries:
..conn.execute(q)

I now want to add type hints such that my large codebase can
be checked for silly doings. First, queries is to be a list
of the SQL to run:

run_queries(conn, queries:list):

Then, each list entry can be

...a string holding simple, complete SQL (say "SELECT 1")

run_queries(conn, queries:list[str]):

or

...a dict holding the SQL and arguments for parameters

run_queries(conn, queries:list[dict]):

So, taken together:

run_queries(conn, queries:list[str|dict]):

(yes, this is in Python 3.11/3.12)

Now, when it is a list of dicts I want to further constrain the
dicts. Each is to contain the keys "SQL" and "args". So the keys
are of type str. The values for the keys will be of various types,
such that I chose Any as pseudo-type, so that each list entry that
is of type dict should be dict[str, Any], hence:

queries = [{'SQL': 'SELECT %(value)s', 'args': {'value': 1}}]

and

run_queries(conn, queries:list[str|dict[str, Any]]):

If I now call this function with a simple SQL query:

SQL_query = 'SELECT 1'  # should be type str ?
queries = [SQL_query]   # should be type list[str] ?
run_queries(conn, queries = queries)

and run mypy over that (at least inside my complex codebase) I will
get a type mismatch being hinted at.

So far I don't grasp at which point my reasoning above is faulty.

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

Aw: Re: mypy question

[Karsten Hilbert via Python-list]

Hi Greg,

> dict[str, str] is not a subtype of dict[str, str | something_else]
> because you can assign a value of type something_else to the latter
> but not the former.

I understand what you are saying but I do not yet understand why this
applies to my situation.

I don't have Python at hand currently, so I'll write untested pseudocode:

def print_greeting(greeting:int|str):
   print(greeting)

print_greeting('hello')

The above snippet should be equivalent to my more complicated code over
which mypy complains to the equivalent of

   "input" is of type "str"
   but expected type "Union[str,int]

I do understand that "str" is formally more narrow than "Union [str,int]" and
the type system has every right to not consider them equivalent.

However, this seems like a very common use case: "allow passing in either str 
or int
and have type checking pass either input as valid" -- yet mypy doesn't seem
to share that idea.

Or else there's something I haven't wrapped my head around yet. But what ?

Karsten

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

Re: mypy question

[Karsten Hilbert via Python-list]

Am Fri, Dec 29, 2023 at 11:04:59AM -0700 schrieb Mats Wichmann via Python-list:

> >For what it's worth here's the signature of that function:
> >
> > def run_rw_queries (
> > link_obj:_TLnkObj=None,
> > queries:list[dict[str, str | list | dict[str, Any]]]=None,
> > end_tx:bool=False,
> > return_data:bool=None,
> > get_col_idx:bool=False,
> > verbose:bool=False
> > ) -> tuple[list[dbapi.extras.DictRow], dict[str, int] | None]:
> >
> >Given that I would have thought that passing in
> >list[dict[str, str]] for "queries" ought to be type safe.
> >Mypy indicates otherwise which I am not grokking as to why.
>
> ah... didn't grok what you were asking, sorry - ignore my attempt then.

Never mind, the attempt to help is appreciated.

> So you are passing something that has been typed more
> narrowly than the function parameter.

That would then sort of skirt on violation of the Liskov
principle, of which I learned while trying to research this
mypy behaviour.

However, I would not think the above to be a narrowing-down
as it just *selects* one of the explicitely "legal" options.

list[dict[str, str | list | dict[str, Any]]]

should AFAICT expand to:

list[dict[str, dict[str, Any]]]

OR

list[dict[str, list]]

OR

list[dict[str, str]]

the last of which should provide coverage of

[{'some key': 'some value'}]

> Can you use a TypeGuard here?

Not from what I understand about them...

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mypy question

[Karsten Hilbert via Python-list]

Am Fri, Dec 29, 2023 at 07:49:17AM -0700 schrieb Mats Wichmann via Python-list:

> >I am not sure why mypy thinks this
> >
> >gmPG2.py:554: error: Argument "queries" to "run_rw_queries" has incompatible 
> >type "List[Dict[str, str]]"; expected
> >"List[Dict[str, Union[str, List[Any], Dict[str, Any"  [arg-type]
> > rows, idx = run_rw_queries(link_obj = conn, queries = 
> > queries, return_data = True)
> >   
> > ^~~
> >
> >should be flagged. The intent is for "queries" to be
> >
> >a list
> > of dicts
> > with keys of str
> > and values of
> > str OR
> > list of anything OR
> > dict with
> > keys of str
> > and values of anything
> >
> >I'd have thunk list[dict[str,str]] matches that ?
>
> Dict[str, str] means the key type and value type should both be strings,

Indeed, I know that much, list[dict[str, str]] is what is getting
passed in in this particular invocation of run_rw_queries().

For what it's worth here's the signature of that function:

def run_rw_queries (
link_obj:_TLnkObj=None,
queries:list[dict[str, str | list | dict[str, Any]]]=None,
end_tx:bool=False,
return_data:bool=None,
get_col_idx:bool=False,
verbose:bool=False
) -> tuple[list[dbapi.extras.DictRow], dict[str, int] | None]:

Given that I would have thought that passing in
list[dict[str, str]] for "queries" ought to be type safe.
Mypy indicates otherwise which I am not grokking as to why.

> but in your
> retelling above you indicate lots of possible value types... actually the 
> mypy guess
> seems to be a pretty good recreation of your psuedo-code description.

I agree that mypy's grasp of my intent from

queries:list[dict[str, str | list | dict[str, Any]]]=None,

into

"List[Dict[str, Union[str, List[Any], Dict[str, Any"

seems accurate. I just don't understand why list[dict[str,
str]] should not pass that construct.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: mypy question

[Karsten Hilbert via Python-list]

Am Fri, Dec 29, 2023 at 01:15:29PM +0100 schrieb Karsten Hilbert via 
Python-list:

> I am not sure why mypy thinks this
>
> gmPG2.py:554: error: Argument "queries" to "run_rw_queries" has incompatible 
> type "List[Dict[str, str]]"; expected
> "List[Dict[str, Union[str, List[Any], Dict[str, Any"  [arg-type]
> rows, idx = run_rw_queries(link_obj = conn, queries = 
> queries, return_data = True)
>   
> ^~~
>
> should be flagged. The intent is for "queries" to be
>
> a list
>   of dicts
>   with keys of str
>   and values of
>   str OR
>   list of anything OR
>   dict with
>   keys of str
>   and values of anything
>
> I'd have thunk list[dict[str,str]] matches that ?
>
> This is on Python 3.11.2 with mypy 1.0.1 on Debian.

For completeness, this was the mypy call signature:

mypy --pretty --allow-redefinition --no-strict-optional 
--ignore-missing-imports --follow-imports silent --show-error-codes 
--warn-unused-ignores gmPG2.py

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

mypy question

[Karsten Hilbert via Python-list]

Hi all,

I am not sure why mypy thinks this

gmPG2.py:554: error: Argument "queries" to "run_rw_queries" has incompatible 
type "List[Dict[str, str]]"; expected
"List[Dict[str, Union[str, List[Any], Dict[str, Any"  [arg-type]
rows, idx = run_rw_queries(link_obj = conn, queries = 
queries, return_data = True)
  
^~~

should be flagged. The intent is for "queries" to be

a list
of dicts
with keys of str
and values of
str OR
list of anything OR
dict with
keys of str
and values of anything

I'd have thunk list[dict[str,str]] matches that ?

This is on Python 3.11.2 with mypy 1.0.1 on Debian.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

> > .From all the posts I gather the answer to my question is
> > "simply": unpackaged-but-needed modules need to be packaged.
>
> I think there is one aspect that isn't getting consideration here.  And
> that is whether or not you want these packages installed in the default
> system Python install.  You might not.

Indeed, which is why all the fuzz about how to fill-in a venv from pip while
installing with apt :-)

With "properly" packaged modules one wouldn't risk (that much) system
breakage, at any rate.

>  Maybe you want to get the latest
> possible version of super-dooper-gui-helper, but one of its dependencies
> doesn't play well with the system Python libraries. Or ... but you get
> the point.  There are probably many cases where you want *not* to
> install into the system Python world.  So you would need to come up with
> an APT-based installer that doesn't do that.
>
> Obviously it's not unthinkable;

Certainly not, it's just that I had hoped someone goes: look here
and all of this ...

> it is just one more thing to figure out.

... has been thought through before.

Thanks,
Karsten
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Mon, Nov 06, 2023 at 02:43:47PM -0700 schrieb Mats Wichmann via Python-list:

> >I had just hoped someone here might have a handy pointer for
> >how to deal with modules having to be installed from pip for
> >use with an apt-installed python-based application.
>
> That just shouldn't happen - such packages are supposed to be 
> dependency-complete within
> the packaging universe in question.

Yep, that's the preferable ideal world.

Which doesn't happen (but that's not the fault of anyone
around here, no harm intended).

.From all the posts I gather the answer to my question is
"simply": unpackaged-but-needed modules need to be packaged.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Mon, Nov 06, 2023 at 08:58:00AM +0100 schrieb Dieter Maurer:

> I know that debian packagers create debian packages
> from Python distributions not using the approach sketched above
> and likely they have their reasons.
>
> You might want to discuss this on an `apt` related mailing list.

Yeah, I guess. I know all this stuff about python modules
being packaged for Debian and how apt handles dependencies
etc etc.

I had just hoped someone here might have a handy pointer for
how to deal with modules having to be installed from pip for
use with an apt-installed python-based application.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Mon, Nov 06, 2023 at 01:17:11AM - schrieb Jon Ribbens via Python-list:

> >> >> Are they not available in your system's package manager?
> >> >
> >> > ... this clearly often answers to "no" for applications of
> >> > any complexity.
> >> >
> >> > Is there a suggested proper path to deal with that (Debian is
> >> > of interest to me here) ?
> >>
> >> Yes, as previously mentioned, use virtual environments.
> >>
> > How does one "fill" that venv with packages from pip during
> >
> > apt-get install python3-app-of-interest
> >
> > ?
> >
> > Is the suggested way really to pip-install into this venv
> > during apt-get install ?
>
> I don't know what you mean by that. But if you install the apt packages
> and then create your venv with --system-site-packages then I believe
> your venv should be able to see the apt packages and import them.

The problem is when there's modules not available via apt as
packages. In that case on needs to either package them or pip
them into the venv suggested above.

When they are apt-gettable no venv is needed in the first
place. One would just install the application script like any
other binary, and which loads apt-installed modules just so.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Sun, Nov 05, 2023 at 03:00:41PM + schrieb Chris Green via Python-list:

> >   * contact every single maintainer of every single one of the packages
> > that needs updating and persuade them to update their packages and
> > reassure them that you are getting all the other package maintainers
> > to update their packages accordingly and that you have a plan and
> > that you know what you're doing
> >
> >   ... screen fades to black, title card "3 years later", fade in to ...
> >
> >   * publish your package
> >
> Surely it's not that bad, the vast bulk of Debian, Ubuntu and other
> distributions are installed via systems that sort out dependencies once
> given a particular package's requirements.  Python is surely not
> unique in its dependency requirements.

Oh, Debian does just fine in resolving dependencies it knows
about within its .deb package universe. The problem arises
when there's unpackaged modules required. The only answer
seems to be to package such modules oneself.

If that's been conquered a venv isn't even needed anymore.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Fri, Nov 03, 2023 at 01:53:32PM - schrieb Jon Ribbens via Python-list:

> >> Are they not available in your system's package manager?
> >
> > ... this clearly often answers to "no" for applications of
> > any complexity.
> >
> > Is there a suggested proper path to deal with that (Debian is
> > of interest to me here) ?
>
> Yes, as previously mentioned, use virtual environments.
>
> These days they don't even need to be "activated". For package 'foo'
> for example you could create /usr/local/lib/foo, under which you would
> create a virtual environment and install the 'foo' package inside it,
> and then you could do:
>
> ln -s /usr/local/lib/foo/env/bin/foo /usr/local/bin/foo
>
> and then you could just type 'foo' to run it.

This all being nice and well, but:

How does one "fill" that venv with packages from pip during

apt-get install python3-app-of-interest

?

Is the suggested way really to pip-install into this venv
during apt-get install ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Fri, Nov 03, 2023 at 05:26:06PM +0100 schrieb Dieter Maurer:

> Karsten Hilbert wrote at 2023-11-3 14:47 +0100:
> > ...
> >> Are they not available in your system's package manager?
> >
> >... this clearly often answers to "no" for applications of
> >any complexity.
> >
> >Is there a suggested proper path to deal with that (Debian is
> >of interest to me here) ?
>
> Complex applications may maintain a set of "known workable versions"
> associated with the application's releases.
> They may describe those "known workable versions" in a `pip` constraint file.
> In this case, you can upgrade to a new application release
> by using this constraint file.

Hello Dieter,

do you happen to know where to read up on how to fit a pip
constraint file into a Debian package creation workflow ?

Thanks,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Thu, Nov 02, 2023 at 04:07:33PM -0600 schrieb Mats Wichmann via Python-list:

> >So they now have only python3 and there is no python executable in
> >PATH.
>
> FWIW, for this you install the little stub package python-is-python3. 
> Especially if you
> want to keep a python2 installation around - "python" will still be python3 
> in this
> case.

Since you seem knowledgeable in this area: Do you know of a
resource for learning the *canonical* way of packaging a
Python application for installation via apt which

- needs some packages available via apt
- needs some packages only available via pip
- needs some packages newer than what is available via apt

?

Thanks,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pip/pip3 confusion and keeping up to date

[Karsten Hilbert via Python-list]

Am Thu, Nov 02, 2023 at 09:35:43PM - schrieb Jon Ribbens via Python-list:

Regardless of ...

> Because pip barely plays well by itself, let alone with other package
> managers at the same time.

... being true ...

> > I do only install a few things using pip.
>
> Are they not available in your system's package manager?

... this clearly often answers to "no" for applications of
any complexity.

Is there a suggested proper path to deal with that (Debian is
of interest to me here) ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Re: Any possible type alias that can also set a default value for a function arg?

[Karsten Hilbert via Python-list]

> > As per my recent foray into abusing existence-checking for Singleton 
> > assurance
> > along such lines as
> >
> > >>> try: self.initialized
> > >>> except AttributeError: print('first instantiation'); self.initialized = 
> > >>> True
> >
> > and then changing that to
> >
> > >>> try: self.initialized:bool
>
> But that's not equivalent code.

I learned as much (RHS vs LHS).

But it did not _intuitively_ resonate with the sentiment
"type annotation does not change the running of code".

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

Aw: Re: Re: Any possible type alias that can also set a default value for a function arg?

[Karsten Hilbert via Python-list]

> > > Fundamentally no, at least not without some shenanigans. Type hints do
> > > not affect the regular running of the code,
> >
> > Except when they do ;-)
> >
> > ... depending on what counts as (valid) code ...
> >
> > In Python a distinction can be made between "runnable" and "valid" :-D
> >
>
> Can you give a counter-example?

As per my recent foray into abusing existence-checking for Singleton assurance
along such lines as

>>> try: self.initialized
>>> except AttributeError: print('first instantiation'); self.initialized = True

and then changing that to

>>> try: self.initialized:bool

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

Aw: Re: Any possible type alias that can also set a default value for a function arg?

[Karsten Hilbert via Python-list]

> > or something like that. Basically, any way to avoid writing `= None` over 
> > and over again.
>
> Fundamentally no, at least not without some shenanigans. Type hints do
> not affect the regular running of the code,

Except when they do ;-)

... depending on what counts as (valid) code ...

In Python a distinction can be made between "runnable" and "valid" :-D

Karsten

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

Re: type annotation vs working code

[Karsten Hilbert via Python-list]

Am Wed, Oct 04, 2023 at 05:25:04PM +1300 schrieb dn via Python-list:

> The first question when dealing with the Singleton Pattern is what to do when 
> more than
> one instantiation is attempted:
>
> - silently return the first instance

This, in my case.

> and so, returning to the matter of 'readability':
>
> - the name "Borg" de-railed comprehension
>
> - _instances:dict = {} implied the tracking of more than one

Child classes, yes, each being a Singleton.

> or a Singleton() class defined, which is then sub-classed, ie
>
> class Something( Singleton ):

Could have been but the legacy codebase came with Borg ...

> - from there, plenty of 'templates' exist for Singletons,

...  which was taken from the Web ages ago.

> - this article (https://python-patterns.guide/gang-of-four/singleton/)

Reading.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type annotation vs working code

[Karsten Hilbert via Python-list]

Sorry for having conflated the core of the matter with all
the Borg shenanigans, that's where I found the problem in my
real code, so there :-)

Consider this:

#
class Surprise:
def __init__(self, with_type_annotation=False):
if with_type_annotation:
try:
self.does_not_exist:bool
print('does_not_exist does exist')
except AttributeError:
print('does_not_exist does not exist')
return

try:
self.does_not_exist
print('does_not_exist does exist')
except AttributeError:
print('does_not_exist does not exist')

Surprise(with_type_annotation = False)
Surprise(with_type_annotation = True)
#

Is this how it is supposed to be ?


> ...and so we're addressing the important question: the try-test is for 
> existence, cf for
> some value.
>
> This can also be achieved by using the attribute in a legal expression, eg:
...
> Might this remove the confusion (ref: @Mats):
>
> self.already_initialized:bool == True

Not for me as that would _create_ already_initialized on the
instance. It would not allow me to test for it.

> >Which seems akin constructs for generating compatibility
> >between versions.
>
> versions of ?

Of the language. Sometimes one tests for existence of a given
class in a module and defines said class oneself if it does
not exist. But that's leading astray.

> What is the intent: a class where each instance is aware of every other 
> instance - yet
> the word "Singleton" implies there's only one (cf a dict full of ...)?

The latter.

Regards,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: type annotation vs working code

[Karsten Hilbert via Python-list]

Am Sun, Oct 01, 2023 at 09:04:05AM +1300 schrieb dn via Python-list:

> >class WorkingSingleton(Borg):
> >
> > def __init__(self):
> > print(self.__class__.__name__, ':')
> > try:
> > self.already_initialized
> > print('already initialized')
> > return
> >
> > except AttributeError:
> > print('initializing')
> >
> > self.already_initialized = True
> > self.special_value = 42

> >Where's the error in my thinking (or code) ?
>
> What is your thinking?
> Specifically, what is the purpose of testing self.already_initialized?

The purpose is to check whether the singleton class has been
... initialized :-)

The line

self.already_initialized = True

is misleading as to the fact that it doesn't matter at all
what self.already_initialized is set to, as long as is
exists for the next time around.

> Isn't it generally regarded as 'best practice' to declare (and define a value 
> for) all
> attributes in __init__()? (or equivalent) In which case, it will (presumably) 
> be defined
> as False; and the try-except reworded to an if-else.

I fail to see how that can differentiate between first-call
and subsequent call.

> Alternately, how about using hasattr()? eg
>
> if hasattr( self.already_initialized, 'attribute_name' ):

That does work. I am using that idiom in other children of
Borg. But that's besides the point. I was wondering why it
does not work the same way with and without the type
annotation.

> try:
> self.already_initialized
>
> line is flagged by the assorted linters, etc, in my PyCharm as:
>
> Statement seems to have no effect.

Well, the linter simply cannot see the purpose, which is
test-of-existence.

> Question: is it a legal expression (without the typing)?

It borders on the illegal, I suppose, as the self-
introspection capabilities of the language are being
leveraged to achieve a legal purpose.

Which seems akin constructs for generating compatibility
between versions.

It seems the answer is being pointed to in Matts response.

It just mightily surprised me.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

type annotation vs working code

[Karsten Hilbert via Python-list]

A type annotation isn't supposed to change what code does,
or so I thought:

#
class Borg:
_instances:dict = {}

def __new__(cls, *args, **kargs):
# look up subclass instance cache
if Borg._instances.get(cls) is None:
Borg._instances[cls] = object.__new__(cls)
return Borg._instances[cls]


class WorkingSingleton(Borg):

def __init__(self):
print(self.__class__.__name__, ':')
try:
self.already_initialized
print('already initialized')
return

except AttributeError:
print('initializing')

self.already_initialized = True
self.special_value = 42


class FailingSingleton(Borg):

def __init__(self):
print(self.__class__.__name__, ':')
try:
self.already_initialized:bool
print('already initialized')
return

except AttributeError:
print('initializing')

self.already_initialized = True
self.special_value = 42

s = WorkingSingleton()
print(s.special_value)

s = FailingSingleton()
print(s.special_value)

#

Notice how Working* and Failing differ in the type annotation
of self.already_initialized only.

Output:

WorkingSingleton :
initializing
42

FailingSingleton :
already initialized <== 
Huh ?
Traceback (most recent call last):
  File 
"/home/ncq/Projekte/gm/git/gnumed/gnumed/client/testing/test-singleton.py", 
line 48, in 
print(s.special_value)
  ^^^
AttributeError: 'FailingSingleton' object has no attribute 
'special_value'


Where's the error in my thinking (or code) ?

Thanks,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP668 / pipx and "--editable" installs

[Karsten Hilbert via Python-list]

Am Sat, Sep 16, 2023 at 02:17:19PM +1200 schrieb Rimu Atkinson via Python-list:

> Everyone uses virtual environments.

Umm, like, no.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Windows Gui Frontend

[Karsten Hilbert]

> The real time consuming stuff in building GUIs is getting
> the basic design right and keeping all the controls,
> keyboard bindings and menus in sync. State management
> in other words.

And cominmg up with sensible design choices _at all_.

> I did a deep dive examination of GUI builders back around
> v2.6 and came away less than enthused. Things may have
> improved since then but I've seen no real evidence of
> that.

Is this available anywhere ?

What GUI builders do (for me) is to make creating the GUI in a WYSIWYM way.

Like LyX for LaTeX.

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

Aw: Re: Standard class for time *period*?

[Karsten Hilbert]

> No, it doesn't.  I already know about timedelta.  I must have explained
> the issue badly, because everyone seems to be fixating on the
> formatting, which is not a problem and is incidental to what I am really
> interested in, namely:
>
> 1. Is there a standard class for a 'period', i.e. length of time
>specified by a start point and an end point?  The start and end
>points could obviously be datetimes and the difference a timedelta,
>but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be
>different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the
>*duration* of both periods is the same.

Not that I know, within the constraints of the standard library.

However:

class CalendarPeriod:
   def __init__(self, start, end):
  self.start = start
  self.end = end

?

For this to be *useful* more needs need to be explained. Until then - YAGNI.

Karsten

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

Aw: Re: Python 3.10 Fizzbuzz

[Karsten Hilbert]

> > I've never tried Black or any other code formatter, but I'm sure we
> > wouldn't get on.
>
> Does this suggest, that because Black doesn't respect other people's
> opinions and feelings, that it wouldn't meet the PSF's Code of Conduct?

That much depends on The Measure Of A Man.

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

Re: TypeError: can only concatenate str (not "int") to str

[Karsten Hilbert]

Am Sun, Feb 26, 2023 at 08:56:28AM -0800 schrieb Hen Hanna:

> so far,  i think  Paul Rubin's post (in another thread) was
> esp. concise, informative, --- but he's also made a comment
> about   'shunting'  beginners  (questions) to a
> concentration camp, and sounded  a bit  like a cold-hearted
> (or warm-hearted)  Nazi  officer / scientist.

Now, I have a lot of sympathy -- not least from a
professional point of view -- and see quite some leeway for
people acting neuro-atypically, but the last line of the
above really isn't necessary to be read on this list.

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pylint scoping question

[Karsten Hilbert]

Am Wed, Feb 08, 2023 at 12:20:48PM +0100 schrieb Karsten Hilbert:

> I have a pylint scoping (or how-to) question.
...
> Objective:
>
> to disable all pylint errors/warnings starting from a
> particular source line until EOF (that part contains
> to-be-run-manually scratch/test code for that file)

This


https://stackoverflow.com/questions/66914050/what-is-the-scope-of-pylint-comments

BTW, is the seemingly closest related information I could
find but it does not explain the difference in scoping
between disable=something and disable=all.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

pylint scoping question

[Karsten Hilbert]

Dear readers,

I have a pylint scoping (or how-to) question.

pylint 2.7.2
astroid 2.5.1
Python 3.9.2 (default, Feb 28 2021, 17:03:44)

Objective:

to disable all pylint errors/warnings starting from a
particular source line until EOF (that part contains
to-be-run-manually scratch/test code for that file)

As an MWE consider this code:

#---
usr/bin/python3
"""MWE"""

print(does_not_exist_1)
# Xpylint: disable=undefined-variable
# Xpylint: disable=all
print(does_not_exist_2)
print(does_not_exist_3)
#---

Pylint docs say that disables are per-scope. Thusly a

# pylint: disable=undefined-variable

inside the file-global scope should (?) disable
undefined-variable for the entire (?) file-global scope.

It does not, however, but rather seems to disable it inside
the file-global scope *from the line of occurrence onwards*.
To see this, remove the X from the relevant disable in the
MWE. This is the behaviour I desire to achieve.

However, when using the "disable=all" it *does* disable all
output, including the

x.py:4:6: E0602: Undefined variable 'does_not_exist_1' 
(undefined-variable)

despite the

# pylint: disable=all

sitting *after* the

print(does_not_exist_1)

So:

Am I doing something wrong ?

Am I misinterpreting the docs ?

Do the docs explain this difference in disable-scoping ?

How should I properly go about my objective (apart from
fixing my code, of course :-D ) ?

Thanks for insights,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are these good ideas?

[Karsten Hilbert]

Am Mon, Nov 14, 2022 at 05:14:05PM + schrieb Stephen Tucker:

> Issue 2 - Passed Parameters
>
> I am now facing another situation where I am wanting to pass 6 or 7
> parameters down through several layers of logic (function A calling
> function B calling ... ) and for results to be passed back.
>
> Having had the idea described above, I am considering using it again to
> save all the parameter-and-results passing.
>
> I see nothing wrong with doing that, but I may well be missing something!

Maybe pass and return a class ?  Maybe even a data class ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Karsten Hilbert]

Am Mon, Nov 14, 2022 at 02:13:34AM + schrieb MRAB:

> But if it's an expression where it's expecting a statement and it's not a 
> call, then
> it's probably a bug.

That "probably" makes it suitable for a linter, as was pointed out.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

"mailcap" to be removed (3.13) -- suggested replacement ?

[Karsten Hilbert]

Dear list,

Python 3.11 marks "mailcap" for removal in 3.13. The
documentation speaks about "mimetypes" being a replacement,
of sorts. I agree with removing dead batteries.

However, I can't really see how "mimetypes" helps in
replacing the functionality of "mailcap" ?

Put another way: what is the suggested way of replacing that
module in existing code ?  The use case is "find the viewer
for any kind of file (by mimetype), as long as the system
knows".

Thanks,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A trivial question that I don't know - document a function/method

[Karsten Hilbert]

Am Sun, Oct 23, 2022 at 05:16:48PM -0400 schrieb Thomas Passin:

> > def make_title_from_headline(self, p, h) -> str:
> >
> > def plot(self, stackposition=MAIN, clearFirst=True) -> None:

> 1. Knowing the type of a parameter isn't all you usually want to know;

Sure, as I said:

> >and use RETURNS (or Returns:) only when what is returned
> >warrants further explanation (say, as to what is returned
> >when).

same for arguments, which *usually* warrant some further
explanation, except for rare cases such as

def format_a_string(string2format:str=None) -> str:

where string2format just might not require further
explanation.

> 2. If the type information isn't in the docstring, it won't be reported by 
> reporting
> tools that use the docstring.

While true such tools could be considered suboptimal (these
days, again as I said).

> Then there are all those cases where the signature hasn't been type-annotated

True but OPs question was *how* to document so there's no
perceived problem with having to document.

> I would say that if the types are annotated, the method is simple enough, and 
> the names
> are clear enough, sure, go ahead and rely on the type annotations.  The most 
> important
> thing is that readers can understand what the arguments and returns are 
> intended to be,
> so some flexibility makes sense.

+1

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A trivial question that I don't know - document a function/method

[Karsten Hilbert]

Am Sat, Oct 22, 2022 at 09:49:55PM -0400 schrieb Thomas Passin:

> def make_title_from_headline(self, p, h):
> """From node title, return title with over- and underline- strings.
...
>RETURNS
>a string
> """

> def plot(self, stackposition=MAIN, clearFirst=True):
> """Plot a 2-D graph.
...
> RETURNS
> nothing
> """

Would it not, these days, be clearer to

def make_title_from_headline(self, p, h) -> str:

def plot(self, stackposition=MAIN, clearFirst=True) -> None:

and use RETURNS (or Returns:) only when what is returned
warrants further explanation (say, as to what is returned
when).

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: for -- else: what was the motivation?

[Karsten Hilbert]

> which had special combinations for all the BASIC keywords). And if you
> go this way, why not go a step further and dissociate the program from
> its linear text representation? Add footnotes, different views,
> hyperlinks, format mathematical expressions like formulas, etc.

http://literateprogramming.com/

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

Re: for -- else: what was the motivation?

[Karsten Hilbert]

Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram:

>   I often follow this rule. For me, it's about readability. Compare:
>
> if not open( disk ):
> error( "Can't open disk" )
> else:
> printf( "now imagine there's some larger block here" )
... ad infinitum 

Should this not be

if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)

as for readability ?

Or even

if not open( disk ):
error( "Can't open disk" )
return what_needs_to_be_returned

do_lots_of_things_with(disk)

The latter version may need some code reorganization, though.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Karsten Hilbert]

Am Sun, Oct 09, 2022 at 07:51:12PM +0200 schrieb Antoon Pardon:

> >But the point is: you can't (there is no way to) be sure the
> >9+ errors really are errors.
> >
> >Unless you further constrict what sorts of errors you are
> >looking for and what margin of error or leeway for false
> >positives you want to allow.
>
> Look when I was at the university we had to program in Pascal and
> the compilor we used continued parsing until the end. Sure there
> were times that after a number of reported errors the number of
> false positives became so high it was useless trying to find the
> remaining true ones, but it still was more efficient to correct the
> obvious ones, than to only correct the first one.
>
> I don't need to be sure. Even the occasional wrong correction
> is probably still more efficient than quiting after the first
> syntax error.

A-ha, so you further defined your context.

Under which I can agree to the objective :-)

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Karsten Hilbert]

Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:

> Op 9/10/2022 om 17:49 schreef Avi Gross:
> >My guess is that finding 100 errors might turn out to be misleading. If you
> >fix just the first, many others would go away.
>
> At this moment I would prefer a tool that reported 100 errors, which would
> allow me to easily correct 10 real errors, over the python strategy which 
> quits
> after having found one syntax error.

But the point is: you can't (there is no way to) be sure the
9+ errors really are errors.

Unless you further constrict what sorts of errors you are
looking for and what margin of error or leeway for false
positives you want to allow.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

[Karsten Hilbert]

Am Sun, Oct 09, 2022 at 05:37:59AM +0100 schrieb Axy via Python-list:

> Python is awesome because it's semantic is clear for the majority, but there 
> are places
> that look odd. In case of "for", "else" looks logically tied with "for" 
> clause, but
> actually it is not. It's tied with "break" statement and I overlooked that 
> even after
> re-reading the language reference. If "else" was named like 
> "never_broken_loop" or
> "nobreak", the semantic would be perfectly clear. But, what's done is done.

Or, "eventually". Sadly, "finally" is already taken, and with
slightly different semantics...

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Subtract n months from datetime [Why?]

[Karsten Hilbert]

> What makes sense depends on where you're looking from.
>
> It's 28 February, you need to keep it for 5 years, therefore you could
> reason that you can dispose of it on 28 February, 5 years hence.
>
> However, that happens to be a leap year.
>
> Should you still have it on 29 February?

Nope because that's *after* the 5 years (they end Feb 28).

If it originates on March 1st, however, you shouldn't dispose of it on Feb 29th 
just yet.

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

Re: How to replace characters in a string?

[Karsten Hilbert]

Am Wed, Jun 08, 2022 at 11:09:05AM +0200 schrieb Dave:

> myString = 'Hello'
> myNewstring = myString.replace(myString,'e','a’)

That won't work (last quote) but apart from that:

myNewstring = myString.replace('e', 'a')

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Automatic Gain Control in Python?

[Karsten Hilbert]

Am Mon, Jun 06, 2022 at 02:08:41PM -0400 schrieb Steve GS:

> Yes, it is real-time play back of a pre-recorded presentation.
...

What all of us around here don't understand is why you insist
on not being able to modify the data to your heart's content
inbetween this ...

> [...] pulling in the programs

... and that ...

> and playing them for an audience.

??

IOW, during the "and" phase.

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pre-Pre-PEP: The datetime.timedeltacal class

[Karsten Hilbert]

Am Sun, Apr 17, 2022 at 11:10:01AM +1200 schrieb Greg Ewing:

> On 17/04/22 9:17 am, Karsten Hilbert wrote:
> > Take this medication for 1 month !
> >
> >is quite likely to mean "take it for 28 days".
>
> Except when your doctor prescribes 90 days worth of tablets,

It *still* means "take for 28 days" :-)

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pre-Pre-PEP: The datetime.timedeltacal class

[Karsten Hilbert]

Am Sat, Apr 16, 2022 at 07:35:51PM +0200 schrieb Peter J. Holzer:

> So I'll start by gathering some feedback
> here with a rough sketch.

> [TODO: Research how other systems handle overflow
> (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't exist)],

That is context dependant:

Take this medication for 1 month !

is quite likely to mean "take it for 28 days".

This standing order (Dauerauftrag) is to be run every
months from now on.

will mean "every 1st of the month, regardless of how many
days passed".

Karsten
GNUmed
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Best way to check if there is internet?

[Karsten Hilbert]

> Is there any value whatsoever in a lie?

Do we _know_ it's a lie ?

Does a lie become a Falsed Truth once it becomes known ?

Karsten

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

Aw: PYT - How can I subscribe to a topic in the mailing list?

[Karsten Hilbert]

> Betreff: PYT - How can I subscribe to a topic in the mailing list?

Mailing lists don't subdivide by topic.

Your mailer may allow you to filter by Subject:.

> And h*ow do I set the topic in my messages?*

not applicable

The equivalent would be the Subject: header.

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

Aw: Re: Long running process - how to speed up?

[Karsten Hilbert]

> > I have a cvs file of 932956 row and have to have time.sleep in a Python
> > script.  It takes a long time to process.
> >
> > How can I speed up the processing?  Can I do multi-processing?
> >
> Remove the time.sleep()?

He's attesting to only having "time.sleep" in there...

I doubt removing that will help much ;-)

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

Aw: Re: Best way to check if there is internet?

[Karsten Hilbert]

> Or the internet acquires a new protocol that's designed
> for very-long-latency connections.

That's being worked on already

https://en.wikipedia.org/wiki/NASA_Deep_Space_Network

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

Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed

[Karsten Hilbert]

Am Thu, Dec 30, 2021 at 03:57:25PM -0800 schrieb hongy...@gmail.com:

> > > Then what cases/scenarios can demonstrate the beauty of recursion?
> > >
> > Walking a tree.
>
> There are many type of trees. Do you mean all of them?

Palm trees don't lend themselves to recursion all that much.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to apply a self defined function in Pandas

[Karsten Hilbert]

Am Sun, Oct 31, 2021 at 07:52:18PM + schrieb Shaozhong SHI:

> Well, can you expand the the simplicity?

Not sure how expanding is going to help but here's one way to
do it:

Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> list('simplicity')
['s', 'i', 'm', 'p', 'l', 'i', 'c', 'i', 't', 'y']
>>>

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: The task is to invent names for things

[Karsten Hilbert]

> Karsten Hilbert  writes:
> >ite is the -te form (in some uses like a gerundium) of aru
> >(to go, to walk)
> 
>   This form, "行って", is written with two "t", as "itte",
>   in many transcriptions to convey the gemination (っ) of
>   the "t". There is, however, "ite", "居て", the -te form of
>   "居る" ("iru" - "to be"), which usually is transcribed "ite".

I stand corrected, thanks. Not the first time that ite/itte
slipped :-/

At any rate, it, eh, is rather malleable to word play.

Karsten

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

Aw: Re: The task is to invent names for things

[Karsten Hilbert]

> > I don't know. A mediocre name conveys at least some information, and
> > that seems to be better than none. On the other hand it might be just
> > enough to lead the reader astray which wouldn't happen with a
> > non-sensical name.

I was thinking that a nonsensical name might lead readers to
go beyond the name when trying to understand code, and would
prompt me to improve upon the name upon reading my own code (and
having acquired, likely, a better understanding of the concept
that's to be named).

Karsten

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

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 12:41:56PM +0200 schrieb Karsten Hilbert:

> Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:
>
> > xyzzy = lambda x: 2 * x
> >
> >   . Sometimes, this can even lead to "naming paralysis", where
> >   one thinks excessively long about a good name. To avoid this
> >   naming paralysis, one can start out with a mediocre name. In
> >   the course of time, often a better name will come to one's mind.
>
> In that situation, is it preferable to choose a nonsensical
> name over a mediocre one ?

That one was a genuine question, BTW, not a snark remark.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 10:00:16PM +1100 schrieb Chris Angelico:

> > Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:
> >
> > > Many operations in computing are fully reversible. After you do
> > > something, you can undo it. After you assign, you can unassign. And
> > > after you ite, you can unite!
> >
> > I wonder whether Japanese programmers would agree.
>
> Not sure. My knowledge of Japanese is extremely scanty. Can you elaborate?

ite is the -te form (in some uses like a gerundium) of aru
(to go, to walk)

so, to un-go, revert-the-having-gone-ness, I genuinely wonder ...

On the other hand, Japanese is full of wondrous word-play at
levels undreamt of by us ASCIInarians.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Tue, Oct 26, 2021 at 11:36:33PM + schrieb Stefan Ram:

> xyzzy = lambda x: 2 * x
>
>   . Sometimes, this can even lead to "naming paralysis", where
>   one thinks excessively long about a good name. To avoid this
>   naming paralysis, one can start out with a mediocre name. In
>   the course of time, often a better name will come to one's mind.

In that situation, is it preferable to choose a nonsensical
name over a mediocre one ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The task is to invent names for things

[Karsten Hilbert]

Am Wed, Oct 27, 2021 at 10:20:19AM +1100 schrieb Chris Angelico:

> Many operations in computing are fully reversible. After you do
> something, you can undo it. After you assign, you can unassign. And
> after you ite, you can unite!

I wonder whether Japanese programmers would agree.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Definitive guide for Regex

[Karsten Hilbert]

Am Thu, Sep 30, 2021 at 12:29:16PM +0100 schrieb Shaozhong SHI:

> I am trying to look for a definitive guide for Regex in Python.
> Can anyone help?

If you tell us what you tried in order to look we can
perhaps guide you on how to take a better look.

Spoonfeeding doesn't seem to be a well-liked activity,
neither here nor on the PostgreSQL lists.

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Karsten Hilbert]

Am Tue, Sep 28, 2021 at 12:53:49PM -0500 schrieb Michael F. Stemper:

> This sounds like a suggestion that I hard-code the data into a
> module. I suppose that I could have half-a-dozen modules with
> different data sets and ln them as required:
>
> $ rm GenData.py* FuelData.py*
> $ ln gendata1.py GenData.py
> $ ln fueldata3.py FuelData.py

vi data.py

generators = {}
generators['name1'] = {'fuel': ..., ...}
generators['name2'] = {...}
...

vi simulation.py

import sys
import data

generator = data.generators[sys.argv[1]]
run_simulation(generator)

or some such ?

Your data "format" is ... Python code.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Karsten Hilbert]

Am Fri, Sep 24, 2021 at 08:59:23PM +0200 schrieb Peter J. Holzer:

> JSON: Has a few primitive data types (bool, number, string) and a two
> compound types (list, dict(string -> any)). Still missing many
> frequently used data types (e.g. dates)

But that (dates) at least has a well-known mapping to string,
which makes it usable within JSON.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: googletrans in python

[Karsten Hilbert]

Am Mon, Apr 12, 2021 at 12:48:23PM -0400 schrieb Quentin Bock:

> Can someone explain the basics of googletrans in python?
> I want to make a program that translates stories into English, but I'm not
> sure how to get a translation printed. Also, is this needed to be done in
> an HTML file inside python?
> If so can someone provide basic code for a translation and how that should
> be written and work?

You might want to post the entire homework assignment verbatim.

That way people might better understand which part of it to
help you with in what way.

As to your description of what you want to achieve -- what
did you already try ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: not able to download PyAudio

[Karsten Hilbert]

The same as with speech recognition.

Research.

Karsten

> Gesendet: Freitag, 02. April 2021 um 10:40 Uhr
> Von: "ᗷᑌᑎᑎY" 
> An: "Igor Korot" 
> Cc: "python-list@python.org" 
> Betreff: not able to download PyAudio
>
>Hello  everyone
>I am not able to download PyAudio. I tried by typing pip install in
>PyAudio in cmd but it show's no compatible version availbale. What should
>I do? .
> 
> 
> 
>Y
> 
> 
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: .title() - annoying mistake

[Karsten Hilbert]

Am Mon, Mar 22, 2021 at 09:22:51AM + schrieb Robert Latest via Python-list:

> >> I agree with everything you say. Especially the open source part. But
> >> wouldn't you agree that .title() with all its arbitrary specificity to
> >> appear in the very core of a general purpose language is quite an oddity?
> >
> > No, because it book ends the issue.
> >
> > Upper - Converts everything to uppercase Lower - Converts everything to
> > lowercase
> >
> > Title - Covers the cases in-between upper/lower.
>
> My only issue is that I completely fail to see how this function would be
> useful enough to warrant the inclusion into the *core* of a general-purpose
> language, including its misleading name. The fact that the function's behavior
> is correctly documented doesn't make its very existence less bewildering to 
> me.

Its naming may be unfortunate, its existence may be
bewildering. However, it's now there, and for historical
reasons, supposedly.

It won't be removed or renamed in all likelihood. The best
one can do is to suggest a documentation patch (not fix)
like so:

The algorithm uses a simple language-independent

[...] and context-naive, not locale related, [...]

definition of a word [...]

and life with that wart.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python cannot count apparently

[Karsten Hilbert]

Am Sun, Feb 07, 2021 at 07:47:03PM + schrieb Paul Bryan:

> That's not the only problem with the code. There's a missing close-
> paren and a reference to "string" which I presume was meant to be
> "myString".

I know. I wasn't going to spoil everything right away. The
sort of response we would get from OP would tell us what sort
of help might be most suitable :-)

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python cannot count apparently

[Karsten Hilbert]

Am Sun, Feb 07, 2021 at 08:34:34PM +0100 schrieb Philipp Daher via Python-list:

> I recently coded this snippet of code:
> myString=„hello“

I doubt you have (coded *this* snippet of code) -- because
those quotes wouldn't work.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: open sentinel-2image python

[Karsten Hilbert]

Am Sun, Jan 17, 2021 at 02:20:24AM -0800 schrieb omid mohammadi:

> When I open the sentinel-2 image in Python, I get the following error:
>
> MemoryError: Unable to allocate 115. MiB for an array with shape (5490, 5490) 
> and data type float32
>
> How can I fix it?

You can install more RAM.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> Trust me: it takes 100x getting anything done plus keep up with your prayers, 
> and it takes 100^100x learning anything solid, as in just forget about it.  
> Indeed, consider that we are rather going to the formal verification of 
> programs, software, and even hardware...

I sincerly wish you that your hope becomes reality within your lifetime.

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

Aw: Re: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> > So what you are looking for is the form of a potential
> > "timeout exception" (say, exception name) ?
> >
> > Provoke one and have a look.
> >
> > Then catch what you saw.
>
> 
>
> Programmers don't guess...

I did not suggest guessing.

I suggested gathering scientific evidence by
running a controlled experiment.

Or should I say "Programmers don't trust..." ?

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

Aw: Re: How do you find what exceptions a class can throw?

[Karsten Hilbert]

> > Remember, you get reporting (a traceback) and program cleanup and exit
> > for free.  What will catching an exception *add* to the user experience?
>
> If it's a timeout exception I'm going to delay a little while and then
> try again.  The timeout is probably because the server is busy.

So what you are looking for is the form of a potential
"timeout exception" (say, exception name) ?

Provoke one and have a look.

Then catch what you saw.

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

Re: Post request and encoding

[Karsten Hilbert]

On Mon, Nov 02, 2020 at 06:43:20PM +0100, Hernán De Angelis wrote:

> I see, my mistake was (tacitly) assuming that encode() could work in place.
>
> Now I see that it should work in a previous line as you wrote.
>
> Thank you!

Sure, and excuse my perhaps slightly terse tone in that earlier mail ...

Karsten

--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Post request and encoding

[Karsten Hilbert]

On Mon, Nov 02, 2020 at 06:21:15PM +0100, Hernán De Angelis wrote:

For the record:

> Just reply to myself and whoever might find this useful.
>
> encode() must be done within the request call:

Nope (but it can, as you showed).

> header = {'Content-type':'application/xml', 'charset':'UTF-8'}
> response = requests.post(server, data=request.encode('utf-8'),
> headers=header)
>
> not in a previous separate line as I did.

Your separate line was wrong as much as ayone can guess:

> > I have tried of course adding
> >
> > request.encode('utf-8')
> >
> > before sending the request but it has not lead to a different result.

You would have needed to do:

request = request.encode('utf-8')

because .encode() does not operate in-place.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Python 3 how to convert a list of bytes objects to a list of strings?

[Karsten Hilbert]

> Just appending a message as a raw file to a mailbox, doesn't properly
> add it as a new message. You need to add a From: line to the front, and
> then go through the message and alter any line that begins as "From:"
> (and possibly any line that begins with something like ">From:" or
> ">>From:" depending on which mailbox format is being used. There may be
> a few other small details that needs to happen to.

I see, thanks.

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

Aw: Re: Video file to subtitles file

[Karsten Hilbert]

> I want to extract subtitles from a MPEG video (which does not have any 
> previous subtitles) and then add them to the same video .

I am not sure I parse the above: You want to *extract* subtitles
from a video which *does not have* subtitles ?

I have a feeling you will need to rephrase your objective
to get better help.

Karsten

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

Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?

[Karsten Hilbert]

> However the problem appears to be that internally in Python 3 mailbox
> class there is an assumption that it's being given 'ascii'.

Do you really _need_ the mailbox class ? From what you've
written so far my understanding was that you receive data
(bytes) and want to append that to a file (which happens
to be an mbox).

Can't you "just do that" ?

IOW, read the bytes, open the file, dump the bytes, close the file ?

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

Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?

[Karsten Hilbert]

> I want to transport the message into my mbox and Python 3 won't do it
> without knowing how it's encoded whereas Python 2 just stuffed it in
> there 'as is'.
>
> I want Python 3's mailbox class to juyst put what I tell it (even if
> mis-formatted or mis-encoded) into the mbox.

I guess using the mailbox class already implies that you do _not_
want to "simply put the msgs into an mbox file" but rather want
the class to do what it was designed for: "put proper msgs properly
into an mbox file". We can't have it both ways I fear. If we
simply want to stuff a file with bytes and call that mbox we
should do so: drop the bytes into a file and call it an mbox file.

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

Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?

[Karsten Hilbert]

> > No interpreation requires, since parsing failed. Then you can start
> > dealing with these exceptions. _Do not_ write unparsable messages into
> > an mbox!
> >
> Maybe I shouldn't but Python 2 has been managing to do so for several
> years without any issues.

I am inclined to congratulate you on that sheer amount of luck. I don't
believe there were no issues because everything worked just right under
py2 but rather because py2 cared less than py3 does now.

> Are we saying that Python 3 really can't be made to handle things
> 'tolerantly' like Python 2 used to?

It sure should be possible but it will require *explicit* en/decode()s in
more places than before because AFAICT there's less impliciteness as to
which encoding to apply (regardless of whether it applies).

Karsten



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

Aw: Re: Python 3 how to convert a list of bytes objects to a list of strings?

[Karsten Hilbert]

> >Are you sure you want `str()`?
> >
>  str(b'aaa')
> >"b'aaa'"
> >
> >Probably you want:
> >
> >map(lambda x: x.decode(), bbb)
>
> _And_ you need to know the encoding of the text in the bytes. The above
> _assumes_ UTF-8 because that is the default for bytes.decode, and if
> that is _not_ what is in the bytes objects you will get mojibake.
>
> Because a lot of stuff is "mostly ASCII", this is the kind of bug which
> can lurk until much later when you have less usual data.

As I said, crawl the delivery chain looking for where things
come from (and what they are).

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

Aw: Re: Re: Another 2 to 3 mail encoding problem

[Karsten Hilbert]

> > > Because of this, the Python 3 str type is not suitable to store an email
> > > message, since it insists on the string being Unicode encoded,
> >
> > I should greatly appreciate to be enlightened as to what
> > a "string being Unicode encoded" is intended to say ?
> >
>
> A Python 3 "str" or a Python 2 "unicode" is an abstract sequence of
> Unicode codepoints.

OK, I figured that much. So it was the "encoded" that threw me off.

Being a sequence of Unicode codepoints makes it en-Uni-coded at
a technically abstract level while I assumed the "encoded" is meant
to somehow reference ''.encode() and friends.

Karsten

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

Aw: Re: Another 2 to 3 mail encoding problem

[Karsten Hilbert]

> Because of this, the Python 3 str type is not suitable to store an email
> message, since it insists on the string being Unicode encoded,

I should greatly appreciate to be enlightened as to what
a "string being Unicode encoded" is intended to say ?

Thanks,
Karsten
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Another 2 to 3 mail encoding problem

[Karsten Hilbert]

> Terry Reedy  wrote:
> > On 8/26/2020 11:10 AM, Chris Green wrote:
> >
> > > I have a simple[ish] local mbox mail delivery module as follows:-
> > ...
> > > It has run faultlessly for many years under Python 2.  I've now
> > > changed the calling program to Python 3 and while it handles most
> > > E-Mail OK I have just got the following error:-
> > >
> > >  Traceback (most recent call last):
> > >File "/home/chris/.mutt/bin/filter.py", line 102, in 
> > >  mailLib.deliverMboxMsg(dest, msg, log)
> > ...
> > >File "/usr/lib/python3.8/email/generator.py", line 406, in write
> > >  self._fp.write(s.encode('ascii', 'surrogateescape'))
> > > UnicodeEncodeError: 'ascii' codec can't encode character '\ufeff' in
> > position 4: ordinal not in range(128)
> >
> > '\ufeff' is the Unicode byte-order mark.  It should not be present in an
> > ascii-only 3.x string and would not normally be present in general
> > unicode except in messages like this that talk about it.  Read about it,
> > for instance, at
> > https://en.wikipedia.org/wiki/Byte_order_mark
> >
> > I would catch the error and print part or all of string s to see what is
> > going on with this particular message.  Does it have other non-ascii chars?
> >
> I can provoke the error simply by sending myself an E-Mail with
> accented characters in it.  I'm pretty sure my Linux system is set up
> correctly for UTF8 characters, I certainly seem to be able to send and
> receive these to others and I even get to see messages in other
> scripts such as arabic, chinese, etc.
>
> The code above works perfectly in Python 2 delivering messages with
> accented (and other extended) characters with no problems at all.
> Sending myself E-Mails with accented characters works OK with the code
> running under Python 2.
>
> While an E-Mail body possibly *shouldn't* have non-ASCII characters in
> it one must be able to handle them without errors.  In fact haven't
> the RFCs changed such that the message body should be 8-bit clean?
> Anyway I think the Python 3 mail handling libraries need to be able to
> pass extended characters through without errors.

Well, '\ufeff' is not a *character* at all in much of any
sense of that word in unicode.

It's a marker. Whatever puts it into the stream is wrong. I guess the
best one can (and should) do is to catch the exception and dump
the offending stream somewhere binary-capable and pass on a notice. What
you are receiving there very much isn't a (well-formed) e-mail message.

I would then attempt to backwards-crawl the delivery chain to
find out where it came from.

Or so is my current understanding.

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

Aw: Python Curses Programming HowTo -reviewers?

[Karsten Hilbert]

> I therefore took it on myself to do a translation of the Linux
> Documentation Project's "Curses HowTo" by Pradeep Padala into Python.
>
> This is now available as a PDF and I'd be interested in review comments.

I'd be interested in having a look, generally.

Will this be available somewhere ?

Thanks,
Karsten

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

Re: SPECIALS CHARACTERS

[Karsten Hilbert]

On Wed, Apr 15, 2020 at 08:45:45AM -0400, Gonzalo V wrote:

> A tiny question.
>  Are there a way to create a new character on python? i need to create some
> kind of arroba @ but with other letter inside. Are there a library for that?

Hello Gonzalo,

this is a font issue, and entirely unrelated to Python
itself.

As for Python libraries that might help in making fonts (or
glyphs, in your case), here's a list:

python3-compreffor - CFF table subroutinizer for FontTools
python3-defcon - UFO based objects for use in font editing applications
python3-fontmake - Python library for compiling fonts from UFO or Glyphs to 
OTF/TTF
python3-fontmath - Objects for performing math operations on font data
python3-fontpens - Classes implementing Pen protocol for manipulating UFO glyphs
python3-fonttools - Converts OpenType and TrueType fonts to and from XML 
(Python 3 Library)
python3-glyphslib - Library for converting between Glyphs files (.glyphs) and 
UFOs
python3-psautohint - Python library for standalone version of the AFDKO 
autohinter
python3-fontconfig - python bindings for the Fontconfig library for Python3
python3-fontconfig-dbg - python bindings for the Fontconfig library for Python3 
(debug build)
python3-qtawesome - iconic fonts in PyQt and PySide applications (Python 3)
python3-xstatic-font-awesome - Font Awesome XStatic support - Python 3.x
python3-xstatic-mdi - Material Design Icons Webfont XStatic support - Python 3.x
python3-xstatic-roboto-fontface - Roboto Fontface XStatic support - Python 3.x
python3-ufo2ft - Bridge from UFOs to fonttools objects
python3-ufolib2 - Unified Font Object (UFO) fonts library
python3-ufonormalizer - Python library to normalize the XML and other data 
inside of a UFO
python3-fontforge - font editor - Python bindings
python3-fontparts - API for interacting with the parts of fonts
python3-freetype - Freetype Python bindings for Python 3
python3-nototools - font support tools from the Noto Fonts project
python3-ufoprocessor - Process and generate Unified Font Object (UFO) files

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confusing textwrap parameters, and request for RE help

[Karsten Hilbert]

On Tue, Mar 24, 2020 at 08:20:32PM +1100, Chris Angelico wrote:

> > > Well um... yes. I think we know that hyphens do indicate word-split
> > > points. That's not really in question.
> >
> > I know you don't mean it like that, but it sounds equally
> > future-proof like "all text is ASCII".
>
> Sure, but I'm not really disputing that part. You can disable it anyway.
>
> I'm trying to figure out a way to handle URLs, and that's something
> that has its own governing standard, so the meanings of characters
> like hyphens is well defined.

Agreed.

More to the point, if anyone knows how to typographically
properly handle this it's the TeX community. Here's a thread:

https://tex.stackexchange.com/questions/3033/forcing-linebreaks-in-url

URL shorteners work but suffer from link rot.

Ellipsised URLs plus footnote would work but don't lend
themselves to textwrap() very well (but perhaps to each
individual application of textwrap()).

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confusing textwrap parameters, and request for RE help

[Karsten Hilbert]

On Tue, Mar 24, 2020 at 08:08:31PM +1100, Chris Angelico wrote:

> Well um... yes. I think we know that hyphens do indicate word-split
> points. That's not really in question.

I know you don't mean it like that, but it sounds equally
future-proof like "all text is ASCII".

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: to continue python

[Karsten Hilbert]

Sure, by all means !

--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Troubleshooting

[Karsten Hilbert]

On Thu, Dec 12, 2019 at 06:40:32PM -0600, catherine morris wrote:

> Good evening,
>
> My son is trying to download python 3.8.0 on my PC, which has Windows 10,
> and it won't install properly. I'm not tech savvy and have no idea where to
> start.

No offense, but, how old is your son ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Aw: Re: Re: Re: Re: stuck on time

[Karsten Hilbert]

> Like this?
>  >>>print_time()
> Traceback (most recent call last)
> File "stdin>", line 1, in 
> File "stdin>", line 2, in print_time
> File "stdin>", line 2, in print_time
> File "stdin>", line 2, in print_time
> [Previous line  repeated 996 more times]
> RecursionError: maximum recursion depth excedded.

Sort of, yes, but since you meanwhile redeclared the function:

def print_time():
   print_time()

to be recursive and then you ran that recursive function
it recursed until it ran out of resources.

However,

> Running the code in a shell , it is displaying the time and now also the  
> date .

That would prove that the code itself is not
the reason why it hangs where you think it
hangs.

I suggest sprinkling print statements about the initial code
and see what it prints to the console to find out where
(and whether) it actually hangs.

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

Aw: Re: Re: Re: stuck on time

[Karsten Hilbert]

> >> In an interactive interpreter:
> >>
> >> def print_time():
> >>  current_time = time.strftime("%I:%M")
> >
> > What happens if you then do
> >
> > print_time()
> >
>
> print_time()
> on it's own returns NameError: name 'print_time' is not defined

Notice the "then" above ?

More precisely: directly one after the other without leaving the interpreter ...

Karsten

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

Aw: Re: Re: stuck on time

[Karsten Hilbert]

> In an interactive interpreter:
>
> def print_time():
> current_time = time.strftime("%I:%M")
>
> returns nothing.

That should be correct.

What happens if you then do

print_time()

inside the interpreter ?

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

Aw: Re: stuck on time

[Karsten Hilbert]

> Sorry, I should have said just the line, and it didn't return anything.

OK, a bit strange, but then that might be due to Thonny.

> Is Thonny an interpreter then.

It sort of is, or at least it runs one. We'd like to take
that out of the equation. I meant to run *just* an interpreter, namely,
the interactive shell built into Python itself.

IOW, run just "python" (or python3) on a command line and a shell
should open in which you can run the line in question.

(remember to define "time" appropriately)

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

Re: stuck on time

[Karsten Hilbert]

On Sat, Dec 07, 2019 at 08:38:20PM +, RobH wrote:

> I have tried the code in Thonny and ran it

Notice how I said "line", not "code".

If you hope to debug anything you need to be precise.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: stuck on time

[Karsten Hilbert]

On Sat, Dec 07, 2019 at 06:56:17PM +, RobH wrote:

> > What happens if your run this line:
> >
> > >   current_time = time.strftime("%I:%M")<<< stays at this line
> >
> > in an interactive Python interpreter ?
> >
> > (after you define "time" appropriately)
>
> The python code is in a terminal window or shell, and when I run it only the
> time is displayed on an oled display, with no indication elsewhere of
> anything else. No errors of any description in the shell. It just appears as
> tho the code has stalled.
>
> Could it be the actual font I am using which is causing the stalling.

That does not sound likely because the line you are asserting
it is stuck on does not output anything so where should
whatever font get involved ?

So, what happens if *you* run the line in an *interactive interpreter* ?

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list