Dataclasses, immutability(?), and ChatGPT
Are dataclasses (or instances thereof) mutable or immutable? - and in what sense? Have been experimenting with ChatGPT. In particular: its possibilities as a trainer, good ideas for methods of introducing new topics, its capability for drawing-up demonstrations or examples, its interpretation of assessment questions (ie evaluating my own work, eg do they test desired specifics, is it possible/likely to misinterpret the question, ...) Conversed with ChatGPT about the differences between (standard) custom-classes and dataclasses, and when one might prefer one over the other. We(?) started discussing how dataclasses might be introduced to trainees currently only familiar with Python's built-ins: "...how they are superior to using built-in data-constructs..." Amongst the four benefits ChatGPT listed was: « Immutable instances: By default, instances of dataclasses are immutable, which means that once created, their attributes cannot be modified. This can help to prevent unintended modifications to the data. » Huh? If we'd been discussing namedtuples over (say) dictionaries, I'd perhaps have accepted the reply. The next step was to write some code to double-check my understanding (reproduced below). No change there. (given that I'm perfect...cough, cough, splutter) Thus, back to ChatGPT to seek clarification: « You said "Immutable instances: By default, instances of dataclasses are immutable, which means that once created, their attributes cannot be modified. This can help to prevent unintended modifications to the data." The attribute-values within a data-class can be changed. In what way are Python dataclasses immutable? » ChatGPT did indeed clarify that: « You're correct that the attribute values within a dataclass can be changed, even though the instance itself is considered immutable. » That's better. The machine is as smart as I am - or I, as smart as it - or something(?) However, the supporting-explanation then appears to argue against its own clarification (and the assertion in the question): « So to clarify, when we say that instances of dataclasses are immutable, we mean that the attributes of an instance cannot be changed after it is created. In other words, if you create an instance of a dataclass, its attributes cannot be modified by any external code. If you want to change the value of an attribute, you need to create a new instance of the dataclass with the updated attribute value. ... [code excised - see below] This is because the instance is considered immutable, and its attributes cannot be changed directly. Instead, we need to create a new instance of the dataclass with the updated attribute value, like this... Now, new_person is a new instance of the Person dataclass with the updated attribute values, while the original person instance remains unchanged. So to summarize, while the attribute values within a dataclass can be changed, instances of dataclasses are considered immutable because their attributes cannot be modified directly once they are created. Any updates to the attributes require the creation of a new instance of the dataclass. » [Note] In and amongst the above explanatory-paragraphs it gives example code-snippets. Those are condensed into: >>> from dataclasses import dataclass >>> >>> @dataclass ... class Person: ... name: str ... age: int ... >>> person = Person(name='Alice', age=20) >>> >>> person.name = 'Bob' # raises AttributeError: can't set attribute >>> person.age = 21 # raises AttributeError: can't set attribute - note the erroneous comments about exceptions being raised (they weren't/aren't)! Here's a home-grown version illustrating all the points made during the investigation, by way of proof/disproof: """ PythonTraining:dataclass.py Prove/disprove claim made by Chat-GPT. """ __author__ = "dn, IT Consultant" __python__ = "3.11" __created__ = "PyCharm, 12 Apr 2023" __copyright__ = "Copyright © 2023~" __license__ = "MIT" # PSL from dataclasses import dataclass @dataclass class Coordinates(): """Sample dataclass. """ x:int y:int if __name__ == "__main__": print( "\nCommencing execution\n" ) coordinates = Coordinates( 1, 2, ) print( coordinates, id( coordinates ), ) coordinates.x = 3 print( coordinates, id( coordinates ), ) coordinates.z = 4 print( coordinates, id( coordinates ), ) print( coordinates.x, coordinates.y, coordinates.z, ) ### output: Commencing execution Coordinates(x=1, y=2) 140436963150928 Coordinates(x=3, y=2) 140436963150928 Coordinates(x=3, y=2) 140436963150928 3 2 4 Terminating ### Not only are a dataclass instance's attribute-values mutable, but further attributes can be dynamically-added to the object-instance! Yes, if the code included: coordinates = Coordinates( 5, 6, ) the new "coordinates" identifier would point to a different id() 'address', ie a fresh immutable-instance. The 'book of
Re: Initialising a Config class
On 12/04/2023 02.29, Loris Bennett wrote:
Hi,
Having solved my problem regarding setting up 'logger' such that it is
...
My reading suggests that setting up a module with a Config class which
can be imported by any part of the program might be a reasonable approach:
...
However, in my config file I am using sections, so 'config' is a dict of
dicts. Is there any cleverer generic way of initialising the class than
...
This seems a bit clunky, because I'll end up with something like
...
So the question is: How can I map a dict of dicts onto class attributes
in a generic way such that only code which wants to use a new
configuration parameter needs to be changed and not the Config class
itself? Or should I be doing this differently?
Note that the values from ConfigParser are all strings, so I am fine
with the attributes being strings - I'll just convert them as needed at
the point of use (but maybe there is also a better way of handling that
within a class).
Good progress!
The first achievement has been related to the (OO) concept of
"encapsulation" - collecting related data into one place.
The second, has been the making of this, globally-accessible within the
application.
The balancing-act may now have become: making sub-sets of the data
available.
Thus, describing which database server and schema/view to use is part of
the application's environment/config, just as much as the labels, eg
company name, used in the GUI or reporting. Such data has been collected
together (into a single 'source of truth'), but will be used in quite
separate and/or disparate functionality within the application.
The config file has been (sensibly) split into sections - when the code
is dealing with the DB it does not need to be concerned with
GUI-settings - or vice-versa.
Accordingly, and like any other class (encapsulation), having been
collected en-masse (or 'amassed', eg cmdLN options combined with a
JSON/YAML/.ini file's settings) the data should be delivered
appropriately. Thus, a 'getter' method (or property) to deliver the name
of the company (likely a string). The one for the database may deliver a
dict or key-value pairs which can be immediately 'pasted' into some
db-open function-call...
Such retrieval-methods will be targeted to the sub-systems of the
application. They can perform formatting and coercion tasks, as
necessary, eg construct full-name from two or more separate data-items,
eg first_name and family_name, or perhaps providing floats where the
config-collection only receives strings. (best to 'hide' all that within
the class, than require the application to deal with the 'clunkiness').
Plus, they could?should provide whatever combination of data-items is
appropriate to THAT part of the application's need for config-data or
constraints. (etc)
Stuff as much as is possible into the config class - how to collect
environment-data, and satisfying any/all demands for its use. Then, the
application can be relieved of all detail ("give me what I want"), only
asking for whatever it requires, when it requires, and in the format it
requires - tailored and ready for immediate-use...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
RE: Initialising a Config class
Not sure if I'm fully understanding the question. But one option instead of
making everything class attributes is to just define __getattr__ for when it
doesn't find an attribute.
Won't work for every single valid section and option name (because of spaces,
name overlaps, etc) but should cover most things.
For example, you could use a dunder to separate section and option. Then
something like this?
import configparser
class Config:
def __init__(self, configFile):
self._config = configparser.ConfigParser()
self._config.read(configFile)
def __getattr__(self, option):
if "__" in option:
section, option = option.split("__", 1)
else:
section = self._config.default_section
return self._config[section][option]
c = Config("SomeConfigFile.txt")
print(c.uids__minimum_uid) #Will check for the option "minimum_uid" in the
"uids" section
print(c.minimum_uid) #Will check the default section
Not sure if that works as you said the Config class itself should not need to
be changed
> Hi,
>
> Having solved my problem regarding setting up 'logger' such that it is
> accessible throughout my program (thanks to the help on this list), I
> now have problem related to a slightly similar issue.
>
> My reading suggests that setting up a module with a Config class which
> can be imported by any part of the program might be a reasonable approach:
>
>
> import configparser
>
> class Config:
>
> def __init__(self, config_file):
>
> config = configparser.ConfigParser()
> config.read(config_file)
>
>
> However, in my config file I am using sections, so 'config' is a dict of
> dicts. Is there any cleverer generic way of initialising the class than
>
>
> self.config = config
>
>
> ?
>
> This seems a bit clunky, because I'll end up with something like
>
>
>import config
>...
>c = config.Config(config_file)
>uids = get_uids(int(c.config["uids"]["minimum_uid"]))
>
>
> rather than something like, maybe
>
>
>uids = get_uids(int(c.minimum_uid))
>
>
> or
>
>
>uids = get_uids(int(c.uids_minimum_uid))
>
>
> So the question is: How can I map a dict of dicts onto class attributes
> in a generic way such that only code which wants to use a new
> configuration parameter needs to be changed and not the Config class
> itself? Or should I be doing this differently?
>
> Note that the values from ConfigParser are all strings, so I am fine
> with the attributes being strings - I'll just convert them as needed at
> the point of use (but maybe there is also a better way of handling that
> within a class).
>
> Cheers,
>
> Loris
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 4/11/23 11:48, Oscar Benjamin wrote: > You can hardly blame a lot of people for doing this. A seb search for > "download python" gives this as the first hit: > https://www.python.org/downloads/ Very true, but it points to the difference between how people install Python on Windows compared to Linux, which is what Chris was probably referring to when he said Windows was a nightmare to support. Usually when a full version bump of python hits my distros, all the other packages that need to be rebuilt get rebuilt and install along with the new python package. Or often the older version of Python is patched and continued to be used, not requiring new packages. So most linux users never have to go searching for an appropriate version of Numpy, etc. Whereas Windows only recently has gained a package manager, and as near as I can tell is not widely used outside of serious developers who use Visual Studio. And to make matters worse, MS offers Python in the Windows Store, which is its own thing and causes much confusion with users who often end up with more than one version of Python installed. And nevermind the MingW/MSVC split that affects the distribution of pre-built binaries, although MS's move to the universal C runtime dll system might fix this finally (unless C++ is involved). These are all extremely hard problems to solve, and every solution has its drawbacks, including the packaging systems used by Linux. Especially by an open source organization like the PSF. -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 4/11/23 11:48, Oscar Benjamin wrote: On Tue, 11 Apr 2023 at 14:55, Mats Wichmann wrote: On 4/11/23 06:03, Roel Schroeven wrote: Op 11/04/2023 om 12:58 schreef Chris Angelico: Python itself is fine, but a lot of third-party packages are hard to obtain. So if you need numpy, for instance, or psycopg2, you might need to find an alternative source. These days I use pip to install packages, and so far for the things I need it simply works. "pip install numpy" works, same for psycopg2, pillow, pandas, and other packages I use. Conda should work too, for those who use the Anaconda Python distribution. I honestly don't even know how it's done: are there some kind souls who provide the wheels (binary packages) for all those things, or if there is maybe a build farm that does the hard work to make things easy for us. In the past I've used Christoph Gohlke's site and I'm very grateful for the service it provided, but these days I don't really need it anymore, luckily. The deal really is, the instant a new Python version drops (3.11, 3.12, etc.) a million people rush to install it, some of whom should know better and be more patient. 3rd party packages are their own projects, some have binary wheels ready on Python release day, some soon after, some months after. You can hardly blame a lot of people for doing this. A seb search for "download python" gives this as the first hit: https://www.python.org/downloads/ I am guessing that the release process automatically updates that page so that the minute 3.12 gets released the big yellow button will suggest downloading 3.12.0 as the default option. Yes, you're quite right about that. Perhaps it is really package authors who should be getting a release out that is compatible with Python 3.12 before 3.12 itself is released. It's tricky though because as a maintainer it makes more sense to wait until you see the finished 3.12 product before making a release that is fully tested with it (even if you are testing the alphas etc in CI and making incremental fixes before 3.12 is released). If you can find the incantation there are often pending builds for packages that need binary wheels, it may be "pip --pre" or it may be pointing to test.pypi.org... or there may not be. The projects may not tell you. And for many less experienced users (and yes this is a known issue), they have no idea they need to look. The other option could be changing the downloads page so that it does not suggest 3.12.0 as the default option until it is clear that at least some baseline of widely used packages have uploaded compatible wheels. There's been some suggestion of that before. Apparently the choice of what goes there is at least a bit political. Like many projects, I believe python prefers to recommend "the latest and best release", while user prudence (and especially organizational prudence) tends to say "hold off for a while until it's been fully vetted, and the ecosystem catches up". I don't think we can cast too much blame on either: I don't expect Microsoft will say "Don't download Windows 12 for the first six months", even if they know perfectly well that many enterprise customers will take an approach like that. Not sure there's any really good answer, TBH. -- https://mail.python.org/mailman/listinfo/python-list
Initialising a Config class
Hi, Having solved my problem regarding setting up 'logger' such that it is accessible throughout my program (thanks to the help on this list), I now have problem related to a slightly similar issue. My reading suggests that setting up a module with a Config class which can be imported by any part of the program might be a reasonable approach: import configparser class Config: def __init__(self, config_file): config = configparser.ConfigParser() config.read(config_file) However, in my config file I am using sections, so 'config' is a dict of dicts. Is there any cleverer generic way of initialising the class than self.config = config ? This seems a bit clunky, because I'll end up with something like import config ... c = config.Config(config_file) uids = get_uids(int(c.config["uids"]["minimum_uid"])) rather than something like, maybe uids = get_uids(int(c.minimum_uid)) or uids = get_uids(int(c.uids_minimum_uid)) So the question is: How can I map a dict of dicts onto class attributes in a generic way such that only code which wants to use a new configuration parameter needs to be changed and not the Config class itself? Or should I be doing this differently? Note that the values from ConfigParser are all strings, so I am fine with the attributes being strings - I'll just convert them as needed at the point of use (but maybe there is also a better way of handling that within a class). Cheers, Loris -- This signature is currently under constuction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 14:55, Mats Wichmann wrote: > > On 4/11/23 06:03, Roel Schroeven wrote: > > Op 11/04/2023 om 12:58 schreef Chris Angelico: > > >> Python itself is fine, but a lot of third-party packages are hard to > >> obtain. So if you need numpy, for instance, or psycopg2, you might > >> need to find an alternative source. > > These days I use pip to install packages, and so far for the things I > > need it simply works. "pip install numpy" works, same for psycopg2, > > pillow, pandas, and other packages I use. Conda should work too, for > > those who use the Anaconda Python distribution. I honestly don't even > > know how it's done: are there some kind souls who provide the wheels > > (binary packages) for all those things, or if there is maybe a build > > farm that does the hard work to make things easy for us. > > > > In the past I've used Christoph Gohlke's site and I'm very grateful for > > the service it provided, but these days I don't really need it anymore, > > luckily. > > The deal really is, the instant a new Python version drops (3.11, 3.12, > etc.) a million people rush to install it, some of whom should know > better and be more patient. 3rd party packages are their own projects, > some have binary wheels ready on Python release day, some soon after, > some months after. You can hardly blame a lot of people for doing this. A seb search for "download python" gives this as the first hit: https://www.python.org/downloads/ I am guessing that the release process automatically updates that page so that the minute 3.12 gets released the big yellow button will suggest downloading 3.12.0 as the default option. Perhaps it is really package authors who should be getting a release out that is compatible with Python 3.12 before 3.12 itself is released. It's tricky though because as a maintainer it makes more sense to wait until you see the finished 3.12 product before making a release that is fully tested with it (even if you are testing the alphas etc in CI and making incremental fixes before 3.12 is released). The other option could be changing the downloads page so that it does not suggest 3.12.0 as the default option until it is clear that at least some baseline of widely used packages have uploaded compatible wheels. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 4/11/23 06:03, Roel Schroeven wrote: Op 11/04/2023 om 12:58 schreef Chris Angelico: Python itself is fine, but a lot of third-party packages are hard to obtain. So if you need numpy, for instance, or psycopg2, you might need to find an alternative source. These days I use pip to install packages, and so far for the things I need it simply works. "pip install numpy" works, same for psycopg2, pillow, pandas, and other packages I use. Conda should work too, for those who use the Anaconda Python distribution. I honestly don't even know how it's done: are there some kind souls who provide the wheels (binary packages) for all those things, or if there is maybe a build farm that does the hard work to make things easy for us. In the past I've used Christoph Gohlke's site and I'm very grateful for the service it provided, but these days I don't really need it anymore, luckily. The deal really is, the instant a new Python version drops (3.11, 3.12, etc.) a million people rush to install it, some of whom should know better and be more patient. 3rd party packages are their own projects, some have binary wheels ready on Python release day, some soon after, some months after. That's the main hole this site filled in more recent times: for people who feel they must jump forward but their key packages were not yet ready, they were probably here. (I should add - it's not always impatience, sometimes folks are also being proactive and want to test Python betas, etc. so they're prepared, and they'll of course hit the same problem of some wheels not being available). There's even a "readiness" site folks can check (also volunteer-run), https://pyreadiness.org/ but often the lure of the new shiny thing just wins out. I predict we'll have a flood of anguish again in the fall when 3.12.0 comes out. -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 4/11/2023 6:58 AM, Chris Angelico wrote: On Tue, 11 Apr 2023 at 20:15, Jim Schwartz wrote: What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks Python itself is fine, but a lot of third-party packages are hard to obtain. So if you need numpy, for instance, or psycopg2, you might need to find an alternative source. I've noticed a big change in the last few years in that PyPi has many, many amd-64 packages than it used to in the heyday of Christoph Gohlke's efforts. I haven't needed to go there for some time whereas I used to need to all the time. So if I "need numpy, for instance, or psycopg2" for Windows, I get them from PyPi. Yes, I know that some projects haven't caught up to Python 3.11x yet. And I'm glad I haven't needed to create a binary wheel for Windows myself. But the situation is way better than it used to be. I've had more trouble with Python and Python packages on Linux than on Windows. -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 2023-04-11 12:54:05 +0100, Oscar Benjamin wrote: > Certainly for the more widely used libraries like numpy installing > binaries with pip is not a problem these days on Windows or other > popular OS. I notice that psycopg2 *only* provides binaries for > Windows and not e.g. OSX or Linux For Linux there is a separate package psycopg2-binary on PyPI. That split happened a few years ago and I forgot why it was necessary. For the distributions I use (Debian and Ubuntu) both packages work (but for the source package I need to install the necessary development packages first). 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
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 21:55, Oscar Benjamin wrote: > > Both numpy and psycopg2 have binary wheels for Windows that can be pip > installed from PyPI. Ah good. It's been a long time since I've needed to care about Windows, so I'm a bit out of the loop. That's good news. While not at all detracting from his amazing contributions over the years, I'm delighted that it's less necessary now. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
Op 11/04/2023 om 12:58 schreef Chris Angelico: On Tue, 11 Apr 2023 at 20:15, Jim Schwartz wrote: > > What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks > Python itself is fine, but a lot of third-party packages are hard to obtain. So if you need numpy, for instance, or psycopg2, you might need to find an alternative source. These days I use pip to install packages, and so far for the things I need it simply works. "pip install numpy" works, same for psycopg2, pillow, pandas, and other packages I use. Conda should work too, for those who use the Anaconda Python distribution. I honestly don't even know how it's done: are there some kind souls who provide the wheels (binary packages) for all those things, or if there is maybe a build farm that does the hard work to make things easy for us. In the past I've used Christoph Gohlke's site and I'm very grateful for the service it provided, but these days I don't really need it anymore, luckily. -- "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 12:01, Chris Angelico wrote: > > On Tue, 11 Apr 2023 at 20:15, Jim Schwartz wrote: > > > > What’s the problem now? Is it with python on windows? I use python on > > windows so I’d like to know. Thanks > > > > Python itself is fine, but a lot of third-party packages are hard to > obtain. So if you need numpy, for instance, or psycopg2, you might > need to find an alternative source. Both numpy and psycopg2 have binary wheels for Windows that can be pip installed from PyPI. I haven't used psycopg2 myself and I don't use Windows so I can't say if there is any difficulty using them but I presume that they can install and run just fine. Certainly the numpy wheels have been there for Windows for years and work just fine. Before numpy provided wheels they also provided MSI installers for Windows anyway so there was always an alternative to Christoph's stack. Christoph's Windows binaries project predated the wheel format and so the alternative options have improved massively since then. I presume that there are some projects where Christoph's binaries are still the only non-conda option (besides build yourself). I would not be surprised if all of those are installable by conda though and we are probably talking about projects that would seem obscure to most Python users. Certainly for the more widely used libraries like numpy installing binaries with pip is not a problem these days on Windows or other popular OS. I notice that psycopg2 *only* provides binaries for Windows and not e.g. OSX or Linux but the list of binaries provided by numpy is extensive with the current release listing wheels for all combinations of CPython 3.8-3.11, win32, win amd64, manylinux amd64, manylinux aarch64, OSX x64, OSX arm64: https://pypi.org/project/numpy/1.24.2/#files The difference now since the days when Cristoph started generating and hosting binaries is that it is typically expected that a project like numpy should produce its own binary wheels for popular platforms and host them on PyPI. Of course that is a burden on the numpy maintainers but tooling for this is much better than it used to be with things like cibuildwheel, free CI systems including Windows/OSX runners etc. It is *much* easier for a project to support generating Windows wheels now than it used to be and to a certain extent it just forms part of the normal CI setup that a project like numpy would want to have anyway. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 20:15, Jim Schwartz wrote: > > What’s the problem now? Is it with python on windows? I use python on > windows so I’d like to know. Thanks > Python itself is fine, but a lot of third-party packages are hard to obtain. So if you need numpy, for instance, or psycopg2, you might need to find an alternative source. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
What’s the problem now? Is it with python on windows? I use python on windows so I’d like to know. Thanks Sent from my iPhone > On Apr 11, 2023, at 2:24 AM, Chris Angelico wrote: > > On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst wrote: >> >> It seems Christoph Gohlke has been cut adrift and his extremely valuable >> web page ... >> >> https://www.lfd.uci.edu/~gohlke/pythonlibs/ >> >> ... turned into an archive getting staler by the day. >> >> What does the Python Software Foundation and the community think about this? > > My personal view? Windows is *really really really* hard to support, > and ONE PERSON did a stellar job of supporting the platform for an > incredibly long job. > > I don't know if he'll ever read this, but if he does, thank you > Christoph for your amazing contribution to the community. > > The fact that we have a problem now is a testament to the length of > time that we *didn't* have a problem, thanks to him. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 18:22, Mike Dewhirst wrote: > > On 11/04/2023 5:21 pm, Chris Angelico wrote: > >> My personal view? Windows is *really really really* hard to support, >> and ONE PERSON did a stellar job of supporting the platform for an >> incredibly long job. > > > I have to agree - but what you are really saying is that without Christoph, > Python on Windows is > > *really really really* > > not viable. > This may well be true, but before writing Windows off completely [1], do check out some of the commercial distributions. It may be that it's possible to do everything through Conda, for instance. [1] Much as I would like to, this isn't a good idea -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On 11/04/2023 5:21 pm, Chris Angelico wrote: On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst wrote: It seems Christoph Gohlke has been cut adrift and his extremely valuable web page ... https://www.lfd.uci.edu/~gohlke/pythonlibs/ ... turned into an archive getting staler by the day. What does the Python Software Foundation and the community think about this? My personal view? Windows is *really really really* hard to support, and ONE PERSON did a stellar job of supporting the platform for an incredibly long job. I have to agree - but what you are really saying is that without Christoph, Python on Windows is *really really really* not viable. Mike I don't know if he'll ever read this, but if he does, thank you Christoph for your amazing contribution to the community. The fact that we have a problem now is a testament to the length of time that we *didn't* have a problem, thanks to him. ChrisA -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Christoph Gohlke and compiled packages
On Tue, 11 Apr 2023 at 14:20, Mike Dewhirst wrote: > > It seems Christoph Gohlke has been cut adrift and his extremely valuable > web page ... > > https://www.lfd.uci.edu/~gohlke/pythonlibs/ > > ... turned into an archive getting staler by the day. > > What does the Python Software Foundation and the community think about this? My personal view? Windows is *really really really* hard to support, and ONE PERSON did a stellar job of supporting the platform for an incredibly long job. I don't know if he'll ever read this, but if he does, thank you Christoph for your amazing contribution to the community. The fact that we have a problem now is a testament to the length of time that we *didn't* have a problem, thanks to him. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
