Re: What is Install-Paths-To in WHEEL file?
On Sun, 31 Dec 2023 at 00:35, Left Right wrote: > > It's not for you to choose the way I communicate. There are accepted > boundaries, and I'm well within those boundaries. Anything beyond that > is not something I'm even interested in hearing your opinion on. You might not be interested in my opinion but you might want to reflect on the fact that although you consider your behavior to be within "accepted boundaries" the evidence here (and in the forum) suggests that others do not and so your notion of what is "accepted" is not universally shared. I am not going to reply to your other points except to say that if you want to influence anything then I expect that you would have more success with a different approach. To anyone else considering replying in this thread: please don't. I very much doubt that anything good will happen here. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: What is Install-Paths-To in WHEEL file?
> You are conflating several different groups of people. The PyPA are > the people who currently maintain the code for various > libraries/tools. That is very often not the same as the people who > originally wrote the code for the same libraries/tools or for > preceding ones. Neither group is the same as the forum moderators (I > suspect that there is no intersection between the moderators and the > PyPA etc.). I'm sorry to tell you, but you suspect wrong. Unfortunately, it's always the same story. Whenever I or anyone else with a legitimate complaint about larger projects managed by PyPA tries to bring this to public discussion, they get banned and their comments about PyPA activity removed. It's always presented as if whoever is complaining is disrespecting the hard work of the person replying, who usually self-describe as selfless volunteer with limited time and attention they are willing to grant to the one complaining (implying they either are PyPA or are volunteering for them). As if their time was obviously more important than that was spent by the one complaining to research the problem and put together the complaint. This has nothing to do with the original authors of the projects managed by PyPA. I don't know why you decided to bring this up. I haven't mentioned them. > Actually you are wasting the time of others by putting across > inaccurate and unhelpful information in a rude way and at the same > time criticising others without really understanding who you are > criticising and for what. Your contribution is unhelpful mostly (but > not exclusively) because of the way that you choose to communicate. No, I'm not _wasting_ anyone's time. I bring up a legitimate issue that needs solving. What happens is a typical example of gatekeeping, overestimating one's worth or the value of one's contribution. The time I had to waste because of the bad decisions made by PyPA is orders of magnitude more than the time they have spent reading whatever I wrote to them. Point me to inaccurate information please. I'm happy to be corrected. Similarly, point me to where I was rude, and I will apologize. Apparently, I have a better understanding of who I criticize and for what than you do. You need to at least be factual when you make these sorts of claims. It's not for you to choose the way I communicate. There are accepted boundaries, and I'm well within those boundaries. Anything beyond that is not something I'm even interested in hearing your opinion on. > There is some significant irony in you describing the forum as a > "toxic pit" for deleting your posts. I don't always agree with the > moderators and I am not sure that I would have reacted the way that > they did but these threads remind me precisely why moderation > (including deleting posts such as yours) is needed to *prevent* a > forum from turning into a toxic pit. You, as well as the moderators of the toxic pit forum are confused about what it means to have a good discussion. The discussion that is currently happening around PyPA projects and ideas is broken because the PyPA side of the discussion is unwilling to acknowledge how bad they are at doing their job. Whenever any serious criticism of their work surfaces, they deal with it by deleting the criticism, never through addressing the problem. You can be the most polite and humble person in the world, but as soon as you bring up the subject of the quality of their decisions, you are automatically excluded from discussion. The only criticism anyone is allowed to have is the kind that doesn't touch on any major projects. It's possible to point out typos in documentation or to address similarly inconsequential defects at the smaller code unit level, but it's not possible to call for a revision of ideas behind libraries or PEPs. For instance, as soon as you mention the comically awful idea of pyproject.toml in a bad light, you get a ban. I believe this comes from the place of insecurity in one's ideas, and has nothing to do with how polite the criticism is. And that's when instruments like "code of conduct" are called upon to delete the inconvenient criticism. This is what creates toxic communities like StackOverflow or similarly built social networks which endow their moderators with way too much power over other users. The other extreme of anarchy, similar to 4chan, doesn't suffer from this problem, but sometimes results in grotesque gore or other _unpleasant_ things but aren't toxic in the same way gatekeeping is. This is how I understand and use the word "toxic". The dicuss.python.org is just as toxic as StackOverflow -- I don't have a metric precise enough to tell who's worse. I believe that this format is a very unfortunate choice for public discussion where there isn't an inherent division between owners and non-owners. Where giving the keys to the common good to a small group of people creates such a division. -- https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
On 31/12/23 10:06 am, Thomas Passin wrote: my suggestion above does work, *except* that you cannot mix-and-match different DictTypex types Have you tried declaring the argument as a Mapping instead of a dict? Seeing as Thomas Passin's Sequence experiment worked, it seems like this should work too. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Re: mypy question
On 31/12/23 8:05 am, Chris Angelico wrote: Ah, I think you've hit on the problem there. Consider this: def add_item(stuff: dict[str: str | int]): stuff["spam"] = "ham" stuff["vooom"] = 1_000_000 Yep, that's it exactly. It's not the union itself that's the problem, but the fact that there's a *mutable container* containing that type. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
On 12/30/2023 9:14 AM, Thomas Passin via Python-list wrote:
On 12/29/2023 10:02 AM, Karsten Hilbert via Python-list wrote:
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.
I made a tiny test program with your type signature, and got this error
message from mypy:
c:\temp\python\typing_test.py:3: error: X | Y syntax for unions requires
Python 3.10 [syntax]
Aside from that, this variation causes no mypy error (you must use
Sequence instead of List), and is also more clear about what you are
trying to get:
from typing import Union, Sequence, Dict
DictType1 = Dict[str, str]
DictType2 = Dict[str, Sequence]
DictType3 = Dict[str, Dict]
QueryType = Sequence[Union[DictType1, DictType2, DictType3]]
def test_typing(queries:QueryType=None):
print(type(queries))
d1 = {'k1': 'v1', 'k2': 'v2'}
queries = [d1,]
test_typing(queries)
I'm not sure if this captures exactly what you want, but it avoids the
problem where mypy does not regard str and Union[str, list] as
equivalent types. I tested this using Python 3.12.
In doing more testing, I have learned that my suggestion above does
work, *except* that you cannot mix-and-match different DictTypex types
within the same Sequence - meaning within the same query argument. Any
of the Union types is OK but they all have to be the same in any instance.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Aw: Re: mypy question
On Sun, 31 Dec 2023 at 03:38, Thomas Passin via Python-list wrote: > I am not very expert in Python type hints. In working up the example > program I just posted, I got an error message from mypy that remarked > that "list" is invariant, and to try Sequence which is "covariant". I > don't know what that means (and I haven't looked into it yet), but when > I changed from list to Sequence as suggested, mypy stopped complaining. > Ah, I think you've hit on the problem there. Consider this: def add_item(stuff: dict[str: str | int]): stuff["spam"] = "ham" stuff["vooom"] = 1_000_000 Is it valid to pass this function a dict[str: str]? No, because it's going to add an integer into it. Hopefully that helps explain what's going on a bit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
> On 30 Dec 2023, at 15:11, Karsten Hilbert via Python-list
> wrote:
>
> queries = [{'SQL': 'SELECT %(value)s', 'args': {'value': 1}}]
>
> and
>
> run_queries(conn, queries:list[str|dict[str, Any]]):
In cases like this I often use a wrapper class in place of a simple str.
If you have a class SqlString then your type becomes list[SqlString].
You may find that SqlString gains interesting methods over time.
Barry
--
https://mail.python.org/mailman/listinfo/python-list
Aw: Re: Re: mypy question
> 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
Re: mypy question
On 12/29/2023 10:02 AM, Karsten Hilbert via Python-list wrote: 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. Maybe better to ask the mypy people directly. 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
> 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
Re: Aw: Re: mypy question
On 12/30/2023 10:08 AM, Karsten Hilbert via Python-list wrote:
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]):
It occurs to me that you could simplify things if you converted those
plain query strings to dicts:
'SELECT 1' --> {'SQL': 'SELECT 1'}
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(). At least, that is how the standard Python db adapters
work. If you change that conversion step, your arguments to
run_queries() will all be lists of dicts, making your code simpler and
reducing the complexity of the type hints.
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
Re: Aw: Re: mypy question
On 12/30/2023 10:08 AM, Karsten Hilbert via Python-list wrote:
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
I am not very expert in Python type hints. In working up the example
program I just posted, I got an error message from mypy that remarked
that "list" is invariant, and to try Sequence which is "covariant". I
don't know what that means (and I haven't looked into it yet), but when
I changed from list to Sequence as suggested, mypy stopped complaining.
Here is the exact error message, and it has a reference you might want
to follow up with:
c:\temp\python\typing_test.py:16: note: "List" is invariant -- see
https://mypy.readthedocs.io/en/stable/common_issues.html#variance
c:\temp\python\typing_test.py:16: note: Consider using "Sequence"
instead, which is covariant
Before that, mypy insisted that str and Union[str, list] were
incompatible argument types, which is something you are seeing, too.
I suggest that you build up your types as in my example, so that it's
very clear what they are and very easy to change them, and use Sequence
instead of List (or list). See if that will do the job.
--
https://mail.python.org/mailman/listinfo/python-list
Aw: Re: mypy question
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
Re: Are there any easy-to-use Visual Studio C# WinForms-like GUI designers in the Python world for Tk?
On 29/12/2023 01:05, Félix An via Python-list wrote: > I'm used to C# WinForms, which has an easy-to-use drag-and-drop GUI > designer in Visual Studio. Is there anything similar for Tk? How about > Qt? There are any number of them but few that work well. The best I found was Dabo but it uses its own Framework (based, ISTR, on wxPython?) so not much good for integrating with third party widgets etc. I also used a Python fork of SpecTcl but it died a death I think. The Qt Designer tool works with Python but I never took to Qt as a toolkit although once mastered it is very powerful. Probably the best choice for professional class GUI applications using a GUI builder. And on a Mac the standard Apple XCode GUI builder works fine with Python too, but is Mac specific. > What do you recommend as the easiest way to create GUI programs in > Python, similar to the ease of use of C# WinForms? Provided you aren't getting fancy the basic Tkinter toolset and programming by hand works best for me. Once you get used to it its quick, flexible and fairly easy to debug. I also use wxPython if I need something more sophisticated, but again I just type the code I don't use a GUI builder. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: mypy question
On 12/29/2023 10:02 AM, Karsten Hilbert via Python-list wrote:
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.
I made a tiny test program with your type signature, and got this error
message from mypy:
c:\temp\python\typing_test.py:3: error: X | Y syntax for unions requires
Python 3.10 [syntax]
Aside from that, this variation causes no mypy error (you must use
Sequence instead of List), and is also more clear about what you are
trying to get:
from typing import Union, Sequence, Dict
DictType1 = Dict[str, str]
DictType2 = Dict[str, Sequence]
DictType3 = Dict[str, Dict]
QueryType = Sequence[Union[DictType1, DictType2, DictType3]]
def test_typing(queries:QueryType=None):
print(type(queries))
d1 = {'k1': 'v1', 'k2': 'v2'}
queries = [d1,]
test_typing(queries)
I'm not sure if this captures exactly what you want, but it avoids the
problem where mypy does not regard str and Union[str, list] as
equivalent types. I tested this using Python 3.12.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How/where to store calibration values - written by program A, read by program B
Peter J. Holzer wrote: > [-- text/plain, encoding quoted-printable, charset: us-ascii, 40 lines --] > > On 2023-12-29 09:01:24 -0800, Grant Edwards via Python-list wrote: > > On 2023-12-28, Peter J. Holzer via Python-list > > wrote: > > > On 2023-12-28 05:20:07 +, rbowman via Python-list wrote: > > >> On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote: > > >> > The biggest caveat is that the shared variable MUST exist before it can > > >> > be examined or used (not surprising). > > >> > > >> There are a few other questions. Let's say config.py contains a variable > > >> like 'font' that is a user set preference or a calibration value > > >> calculated by A to keep with the thread title. Assuming both scripts are > > >> running, how does the change get propagated to B after it is set in A > > > > > > It isn't. The variable is set purely in memory. This is a mechanism to > > > share a value between multiple modules used by the same process, not to > > > share between multiple processes (whether they run the same or different > > > scripts) > > > > > >> and written to the shared file? > > > > > > Nothing is ever written to a file. > > > > Then how does it help the OP to propogate clibration values from one > > program to another or from one program run to the next run? > > It doesn't. See his second mail in this thread, where he explains it in > a bit more detail. I think he might be a bit confused in his > terminology. > If I am the OP (I suspect I may be) I have gone with JSON stored in a file to provide what I need. The Python json package is very simple to use and with an 'indent=' setting the resulting json is reasonably human readable which is all I need. Thus programs simply read the values from the json file into a dictionary of dictionaries and the 'updater of values' program can write them back after changes. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Aw: Re: mypy question
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: How/where to store calibration values - written by program A, read by program B
On 2023-12-29 09:01:24 -0800, Grant Edwards via Python-list wrote: > On 2023-12-28, Peter J. Holzer via Python-list wrote: > > On 2023-12-28 05:20:07 +, rbowman via Python-list wrote: > >> On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote: > >> > The biggest caveat is that the shared variable MUST exist before it can > >> > be examined or used (not surprising). > >> > >> There are a few other questions. Let's say config.py contains a variable > >> like 'font' that is a user set preference or a calibration value > >> calculated by A to keep with the thread title. Assuming both scripts are > >> running, how does the change get propagated to B after it is set in A > > > > It isn't. The variable is set purely in memory. This is a mechanism to > > share a value between multiple modules used by the same process, not to > > share between multiple processes (whether they run the same or different > > scripts) > > > >> and written to the shared file? > > > > Nothing is ever written to a file. > > Then how does it help the OP to propogate clibration values from one > program to another or from one program run to the next run? It doesn't. See his second mail in this thread, where he explains it in a bit more detail. I think he might be a bit confused in his terminology. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
