Re: Matplotlib "collections" module in recent Python, Matplotlib
On 2025-06-15 04:53, jmhannon.ucdavis--- via Python-list wrote: Greetings. We (the group that I work with) have "inherited" some Python scripts that were written years ago, using Python 2. We're trying to upgrade the scripts so that they work in our current environment: OS: Ubuntu 24.04.2 LTS $ python --version Python 3.11.13 >>> matplotlib.__version__ '3.10.0' The first script that we looked at has a line: cs = plt.contourf(X, Y, data, LevelsNumber, cmap=plt.cm.nipy_spectral, norm=norm).collections If I run that script with python 3, I get a warning: MatplotlibDeprecationWarning: The collections attribute was deprecated in Matplotlib 3.8 and will be removed two minor releases later. cmap=plt.cm.nipy_spectral, norm=norm).collections I also get the following error: paths = cs.get_paths() AttributeError: 'list' object has no attribute 'get_paths' The "paths" object that I get appears to be no more than a collection of geometric factors, i.e., without additional attributes such as color, for instance, and statements such as the following fail: bgra_array = 255*paths[i].get_facecolor()[0] AttributeError: 'Path' object has no attribute 'get_facecolor' Unfortunately, all the suggestions that I've found to remedy this suggest using the "collections" attribute, which is already in the code, and which as I noted above, has been deprecated (maybe eliminated -- 3.10 vs. 3.8) now. If you have any suggestions about this, please pass 'em along. Thanks. Does this help? https://discourse.matplotlib.org/t/collections-attribute-deprecation-in-version-3-8/24164 -- https://mail.python.org/mailman3//lists/python-list.python.org
Matplotlib "collections" module in recent Python, Matplotlib
Greetings. We (the group that I work with) have "inherited" some Python scripts that were written years ago, using Python 2. We're trying to upgrade the scripts so that they work in our current environment: OS: Ubuntu 24.04.2 LTS $ python --version Python 3.11.13 >>> matplotlib.__version__ '3.10.0' The first script that we looked at has a line: cs = plt.contourf(X, Y, data, LevelsNumber, cmap=plt.cm.nipy_spectral, norm=norm).collections If I run that script with python 3, I get a warning: MatplotlibDeprecationWarning: The collections attribute was deprecated in Matplotlib 3.8 and will be removed two minor releases later. cmap=plt.cm.nipy_spectral, norm=norm).collections I also get the following error: paths = cs.get_paths() AttributeError: 'list' object has no attribute 'get_paths' The "paths" object that I get appears to be no more than a collection of geometric factors, i.e., without additional attributes such as color, for instance, and statements such as the following fail: bgra_array = 255*paths[i].get_facecolor()[0] AttributeError: 'Path' object has no attribute 'get_facecolor' Unfortunately, all the suggestions that I've found to remedy this suggest using the "collections" attribute, which is already in the code, and which as I noted above, has been deprecated (maybe eliminated -- 3.10 vs. 3.8) now. If you have any suggestions about this, please pass 'em along. Thanks. -- Michael -- https://mail.python.org/mailman3//lists/python-list.python.org
PEP Idea: Extended import syntax for aliasing module attributes
Hi all, I would like to propose a potential addition to Python's `import` syntax that would improve clarity and ergonomics for cases where developers want both full module access *and* a local alias to a specific attribute within that module. Currently, to get both behaviors, we typically write: import module optimize = module.optimize This works fine, but it is slightly verbose and less explicit in intent. I would like to explore syntax like: import module with module.optimize as optimize or possibly: import module with ( module.optimize as optimize, module.validate as check ) The goal is to import the full module as usual, while simultaneously assigning a local name to a chosen sub-attribute all in a single declaration. This strikes a balance between: *Readability* (makes intensions clearer) *Convenience* (avoids repetitive alias assignments) *Maintainability* (discourages `from module import *`) I am curious to hear whether this type of syntax has been considered before, or if it might be worth formalizing into a PEP. I would be happy to help develop a draft proposal if there is interest. Thank you for reading. -Omar -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Matplotlib "collections" module in recent Python, Matplotlib
On 6/14/25 23:53, jmhannon.ucdavis--- via Python-list wrote: Greetings. We (the group that I work with) have "inherited" some Python scripts that were written years ago, using Python 2. We're trying to upgrade the scripts so that they work in our current environment: https://www.scoutapm.com/blog/automated-tools-and-strategies-to-help-migrate-from-python-2-to-3 Cheers. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:[email protected] VoIP: sip:[email protected] -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
On 17/06/2025 00:19, Omar Ahmed via Python-list wrote: Hi all, I would like to propose a potential addition to Python's `import` syntax that would improve clarity and ergonomics for cases where developers want both full module access *and* a local alias to a specific attribute within that module. Currently, to get both behaviors, we typically write: import module optimize = module.optimize This works fine, but it is slightly verbose and less explicit in intent. I would like to explore syntax like: import module with module.optimize as optimize or possibly: import module with ( module.optimize as optimize, module.validate as check ) The goal is to import the full module as usual, while simultaneously assigning a local name to a chosen sub-attribute all in a single declaration. This strikes a balance between: *Readability* (makes intensions clearer) *Convenience* (avoids repetitive alias assignments) *Maintainability* (discourages `from module import *`) I am curious to hear whether this type of syntax has been considered before, or if it might be worth formalizing into a PEP. I would be happy to help develop a draft proposal if there is interest. Thank you for reading. -Omar If the only module attrributes you want are the ones you list explicitly, you can already write from module import ( optimize, validate as check ) Explicit, convenient, readable and less verbose! Of course if you do this, you will get a NameError if you subsequently do module.someOtherAttribute or even just module So this may or may not meet your use case. If it does, it is arguably an advantage that your namespace is not cluttered by having "module" in it You have explicitly documented which attributes of "module" your code uses, and will get an error if you try to use a different one without listing it. If not, you can just add import module (slightly clunky in that you now have 2 import statements referring to the same module, but as I understand it will not be significantly slower - the module will only be imported once). Best wishes, Rob Cliffe -- https://mail.python.org/mailman3//lists/python-list.python.org
PythonWin
Ahem. Yes, is there a compiled version of this product for 64-bit Python 3.13? (It's still the best IMO.) Or, failing that, anything remotely comparable? -- https://mail.python.org/mailman3//lists/python-list.python.org
