matplotlib graph white space
I am using the first bar graph listed at this site: https://matplotlib.org/stable/gallery/index.html The problem I have is that there is too much white space around the graph. My data would be better displayed if I could widen the graph into the space to the right and left of the chart. Steve -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2021: Edited videos of the second day available
We’re happy to release another batch of 35 cut videos of EuroPython 2021 covering most of the second day sessions of the conference. Together with the first day videos, we now have 77 videos waiting for you. You can watch them on our YouTube channel: * EuroPython 2021 Playlist * https://www.youtube.com/playlist?list=PL8uoeex94UhFuRtXhkqOrROsdNI6ejuiq We’ll release the final batch of EuroPython 2021 videos next week. In total, we will have more than 115 videos with lots of valuable and interesting content for you, so please stop by and check the playlist for more videos, or subscribe to our YouTube channel. https://europython.tv/ BTW: Our YouTube channel has videos of all EuroPython conferences going back to 2011. Check out more than 1500 Python videos covering 10 conference years. Help spread the word Please help us spread this message by sharing it on your social networks as widely as possible. Thank you ! Link to the blog post: https://blog.europython.eu/europython-2021-edited-videos-of-the-second-day-available/ Tweet: https://twitter.com/europython/status/1445003583116791810 Enjoy, -- EuroPython 2021 Team https://ep2021.europython.eu/ https://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: matplotlib graph white space
> I am using the first bar graph listed at this site: > https://matplotlib.org/stable/gallery/index.html > > The problem I have is that there is too much white space around the graph. > My data would be better displayed if I could widen the graph into the space > to the right and left of the chart. It sounds like you're asking about changing the size and dimension of a graph. Is that right? Then I suggest looking into `figsize` when creating a figure (especially if you are using the object oriented interface). Alternately, you can adjust the size of a figure afterwards with `fig.set_size_inches` (and variants), and you can get the figure if you are using the matlab-style interface with `matplotlib.pyplot.gcf()`. - DLD -- https://mail.python.org/mailman/listinfo/python-list
RE: matplotlib graph white space
Yes, I saw that but it is a change for all sides. Is there a setting to change just the left and right padding? -Original Message- From: Michel Alwan Sent: Monday, October 4, 2021 7:56 AM To: Steve Cc: python-list@python.org Subject: Re: matplotlib graph white space In the plot window, you can click on the settings (up), and select the option "tight layout" by pressing that button... I think this is what you are looking for... On 21/10/04 04:39AM, Steve wrote: > > I am using the first bar graph listed at this site: > https://matplotlib.org/stable/gallery/index.html > > The problem I have is that there is too much white space around the graph. > My data would be better displayed if I could widen the graph into the > space to the right and left of the chart. > > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list -- Michel Alwan ( support Stallman : stallmansupport.org ) -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.10.0 is available
On behalf of the Python development community and the Python 3.10 release team, I’m pleased to announce the availability of Python 3.10.0. Python 3.10.0 is the newest major release of the Python programming language, and it contains many new features and optimizations. https://www.python.org/downloads/release/python-3100/ # Major new features of the 3.10 series, compared to 3.9 Among the new major new features and changes so far: * [PEP 623](https://www.python.org/dev/peps/pep-0623/) -- Deprecate and prepare for the removal of the wstr member in PyUnicodeObject. * [PEP 604](https://www.python.org/dev/peps/pep-0604/) -- Allow writing union types as X | Y * [PEP 612](https://www.python.org/dev/peps/pep-0612/) -- Parameter Specification Variables * [PEP 626](https://www.python.org/dev/peps/pep-0626/) -- Precise line numbers for debugging and other tools. * [PEP 618 ](https://www.python.org/dev/peps/pep-0618/) -- Add Optional Length-Checking To zip. * [bpo-12782](https://bugs.python.org/issue12782): Parenthesized context managers are now officially allowed. * [PEP 632 ](https://www.python.org/dev/peps/pep-0632/) -- Deprecate distutils module. * [PEP 613 ](https://www.python.org/dev/peps/pep-0613/) -- Explicit Type Aliases * [PEP 634 ](https://www.python.org/dev/peps/pep-0634/) -- Structural Pattern Matching: Specification * [PEP 635 ](https://www.python.org/dev/peps/pep-0635/) -- Structural Pattern Matching: Motivation and Rationale * [PEP 636 ](https://www.python.org/dev/peps/pep-0636/) -- Structural Pattern Matching: Tutorial * [PEP 644 ](https://www.python.org/dev/peps/pep-0644/) -- Require OpenSSL 1.1.1 or newer * [PEP 624 ](https://www.python.org/dev/peps/pep-0624/) -- Remove Py_UNICODE encoder APIs * [PEP 597 ](https://www.python.org/dev/peps/pep-0597/) -- Add optional EncodingWarning [bpo-38605](https://bugs.python.org/issue38605): `from __future__ import annotations` ([PEP 563](https://www.python.org/dev/peps/pep-0563/)) used to be on this list in previous pre-releases but it has been postponed to Python 3.11 due to some compatibility concerns. You can read the Steering Council communication about it [here]( https://mail.python.org/archives/list/python-...@python.org/thread/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/) to learn more. # More resources * [Changelog](https://docs.python.org/3.10/whatsnew/changelog.html#changelog ) * [Online Documentation](https://docs.python.org/3.10/) * [PEP 619](https://www.python.org/dev/peps/pep-0619/), 3.10 Release Schedule * Report bugs at [https://bugs.python.org](https://bugs.python.org). * [Help fund Python and its community](/psf/donations/). # And now for something completely different For a Schwarzschild black hole (a black hole with no rotation or electromagnetic charge), given a free fall particle starting at the event horizon, the maximum propper time it will experience to fall into (which happens when it falls without angular velocity) the singularity is `π*M` (in [natural units](https://en.wikipedia.org/wiki/Natural_units)), where M is the mass of the black hole. For Sagittarius A* (the black hole at the center of the milky way) this time is approximately 1 minute. Schwarzschild black holes are also unique because they have a space-like singularity at their core, which means that the singularity doesn't happen at a specific point in *space* but happens at a specific point in *time* (the future). This means once you are inside the event horizon you cannot point with your finger towards the direction the singularity is located because the singularity happens in your future: no matter where you move, you will "fall" into it. # We hope you enjoy the new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ # More resources Online Documentation https://docs.python.org/3.10/ PEP 619 https://www.python.org/dev/peps/pep-0619/, 3.10 Release Schedule Report bugs at https://bugs.python.org https://bugs.python.org/. Help fund Python and its community https://www.python.org/psf/donations/. Your friendly release team, Ned Deily @nad https://discuss.python.org/u/nad Steve Dower @steve.dower https://discuss.python.org/u/steve.dower Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal -- https://mail.python.org/mailman/listinfo/python-list
[ANN] PyYAML-6.0b1 Released
===
Announcing PyYAML-6.0b1
===
A new beta release of PyYAML is now available:
https://github.com/yaml/pyyaml/releases/tag/6.0b1
The previously-deprecated default loader selection in `yaml.load()` has
been removed; `Loader` is now a required argument.
Support for Python 2.7 and 3.5 has been dropped, and support for Python 3.10
added. It now includes libyaml 0.2.5 extension wheels for MacOS M1
(Apple Silicon/arm64), Linux s390x and Linux aarch64.
Numerous other bugfixes and code cleanups are included in this release.
Changes
===
* https://github.com/yaml/pyyaml/pull/327 -- Change README format to
Markdown
* https://github.com/yaml/pyyaml/pull/483 -- Add a test for YAML 1.1 types
* https://github.com/yaml/pyyaml/pull/497 -- fix float resolver to ignore
`.` and `._`
* https://github.com/yaml/pyyaml/pull/550 -- drop Python 2.7
* https://github.com/yaml/pyyaml/pull/553 -- Fix spelling of “hexadecimal”
* https://github.com/yaml/pyyaml/pull/556 -- fix representation of Enum
subclasses
* https://github.com/yaml/pyyaml/pull/557 -- fix libyaml extension compiler
warnings
* https://github.com/yaml/pyyaml/pull/560 -- fix ResourceWarning on leaked
file descriptors
* https://github.com/yaml/pyyaml/pull/561 -- always require `Loader` arg to
`yaml.load()`
* https://github.com/yaml/pyyaml/pull/564 -- remove remaining direct
distutils usage
Resources
=
PyYAML Matrix: https://matrix.to/#/#pyyaml:yaml.io
PyYAML IRC Channel: #pyyaml on irc.libera.chat
PyYAML homepage: https://github.com/yaml/pyyaml
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.org/project/PyYAML/
GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues
YAML homepage: http://yaml.org/
YAML-core mailing list:
http://lists.sourceforge.net/lists/listinfo/yaml-core
About PyYAML
YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter
for
Python.
PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support,
capable extension API, and sensible error messages. PyYAML supports standard
YAML tags and provides Python-specific tags that allow to represent an
arbitrary Python object.
PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistence.
Example
===
```
>>> import yaml
>>> yaml.full_load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: https://github.com/yaml/pyyaml
... keywords: [YAML, serialization, configuration, persistence, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistence',
'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}
>>> print(yaml.dump(_))
name: PyYAML
homepage: https://github.com/yaml/pyyaml
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistence, pickle]
```
Maintainers
===
The following people are currently responsible for maintaining PyYAML:
* Ingy döt Net
* Matt Davis
and many thanks to all who have contributed!
See: https://github.com/yaml/pyyaml/pulls
Copyright
=
Copyright (c) 2017-2021 Ingy döt Net
Copyright (c) 2006-2016 Kirill Simonov
The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.
PyYAML is released under the MIT license.
See the file LICENSE for more details.
--
https://mail.python.org/mailman/listinfo/python-list
pythonpapers.org domain name to lapse in November
The board of editors of the Python Papers has decided to let the pythonpapers.org domain name to lapse. It will not be renewed in November. Anyone interested in it can get in touch. Cheers Mike -- 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. Just ask and I'll send it to you. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: McCabe complexity for just changed files in a commit?
On Sat, Oct 02 2021 at 09:05:47 PM, Dan Stromberg wrote: > Hi folks. > > Is there a way of getting the McCabe Complexity of just the functions and > methods (in Python) changed in a git commit? > > I found radon, and it looks good. But I think it wants to do entire files, > no? > Calculate your metric for this commit, calculate metric for parent commit, and take the difference? That's how we do coverage metrics to report stuff like "change increases/decreases coverage by N%". -- regards, kushal -- https://mail.python.org/mailman/listinfo/python-list
Re: McCabe complexity for just changed files in a commit?
On Tue, Oct 5, 2021 at 3:44 PM Kushal Kumaran wrote: > > On Sat, Oct 02 2021 at 09:05:47 PM, Dan Stromberg wrote: > > Hi folks. > > > > Is there a way of getting the McCabe Complexity of just the functions and > > methods (in Python) changed in a git commit? > > > > I found radon, and it looks good. But I think it wants to do entire files, > > no? > > > > Calculate your metric for this commit, calculate metric for parent > commit, and take the difference? That's how we do coverage metrics to > report stuff like "change increases/decreases coverage by N%". > What if it has multiple parents, like a merge commit that resolves conflicts? (A merge that doesn't make any other changes won't affect coverage or complexity, since it's all done by the commits on either side.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: McCabe complexity for just changed files in a commit?
On Tue, Oct 05 2021 at 03:55:22 PM, Chris Angelico wrote: > On Tue, Oct 5, 2021 at 3:44 PM Kushal Kumaran wrote: >> >> On Sat, Oct 02 2021 at 09:05:47 PM, Dan Stromberg >> wrote: >> > Hi folks. >> > >> > Is there a way of getting the McCabe Complexity of just the functions and >> > methods (in Python) changed in a git commit? >> > >> > I found radon, and it looks good. But I think it wants to do entire files, >> > no? >> > >> >> Calculate your metric for this commit, calculate metric for parent >> commit, and take the difference? That's how we do coverage metrics to >> report stuff like "change increases/decreases coverage by N%". >> > > What if it has multiple parents, like a merge commit that resolves conflicts? > > (A merge that doesn't make any other changes won't affect coverage or > complexity, since it's all done by the commits on either side.) > In my usecases, merges are asymmetric: one of the parents is useful for reporting metric changes, and the others are not. The parent of interest will be whichever parent was on the mainline branch (first parent). Whether the merge commit resolved conflicts or not makes no difference here. In practice, this does not involve doing commit math. The point where this kind of thing is done is in context of a pull request, where it is clearer what commits you're interested in comparing. When merging branch X into branch Y, the tools only need to look at the heads of those branches. https://github.com/vuejs/vue/pull/9373 is a random example of the kind of thing I'm thinking of. -- regards, kushal -- https://mail.python.org/mailman/listinfo/python-list
