Feeds

Codementor: Comprehensions in Python

Planet Python - Fri, 2022-01-14 20:19
A short article with examples explaining how to use comprehensions in python to create lists, dicts, sets and generators.
Categories: FLOSS Project Planets

Brett Cannon: Unravelling subscriptions in Python

Planet Python - Fri, 2022-01-14 19:58

For the next post in my syntactic sugar series I want to cover subscriptions. It&aposs quite possible you&aposre not familiar with this formal term, but you are probably familiar with the syntax: the square brackets used for indexing lists and tuples (sequence[4]), accessing the value of a specified dictionary (dictionary["key"]), etc. To cover this topic we will break up into three parts: general subscriptions, slicing, and multiple arguments.

General subscriptions

A subscription can get, set, or delete items from a collection. These three operations have equivalent special methods called __getitem__, __setitem__, and __delitem__, respectively. Due to the fact that if a subscription is done on an object that does not have an appropriate special method, we will re-implement the appropriate functions from the operator module. All three functions take a similar approach, so I will just show how __getitem__ works and let you look at the source code for the other two functions.

def __getitem__(container, index, /): """Return the item in the container at the specified index.""" container_type = type(container) try: getitem_method = debuiltins._mro_getattr(container_type, "__getitem__") except AttributeError: raise TypeError(f"{container_type.__name__!r} object is not subscriptable") return getitem_method(container, index)Implementation of operator.__getitem__

The code:

  1. Gets the type of the container.
  2. Gets the __getitem__ method from the type.
  3. If the method doesn&apost exist, raise TypeError.
  4. Otherwise call the method appropriately.
Slicing

The syntax for slicing maps to the slice class&apos constructor where any empty value is represented by None.

  • :: maps to slice(None, None, None)
  • 1:2:3 maps to slice(1, 2, 3)
  • 1:2 maps to slice(1, 2)
  • : maps to slice(None, None)
  • 1: maps to slice(1, None)
  • :1 maps to slice(None, 1) (maps to slice(1) as well)

The slice object then gets passed into the appropriate special method, so x[1:2:3] is the equivalent of type(x).__getitem__(x, slice(1, 2, 3)).

Multiple arguments

If you don&apost work with the scientific stack and use packages like NumPy, you may not know that you can actually pass in multiple arguments when using the subscription syntax: [1, 2, 3]. The key difference to a function call, though, is all of the values get bundled up into a tuple that gets passed in as the first argument to the appropriate special method. This translates x[1, 2, 3] to type(x).__getitem__((1, 2, 3)). This also means that passing in a tuple with the same values is no different: x[1, 2, 3] == x[(1, 2, 3)].

Categories: FLOSS Project Planets

Daniel Roy Greenfeld: Autodocumenting Makefiles

Planet Python - Fri, 2022-01-14 17:20

A few years ago Fabio da Luz taught me some Makefile tricks. This is an expansion on what he taught me (I added the output list and sort feature).

Using PYSCRIPT to Print Documentation

At the top of your Makefile, put in this code:

.DEFAULT_GOAL := help # Sets default action to be help define PRINT_HELP_PYSCRIPT # start of Python section import re, sys output = [] # Loop through the lines in this file for line in sys.stdin: # if the line has a command and a comment start with # two pound signs, add it to the output match = re.match(r'^([a-zA-Z_-]+):.*?## (.*)$$', line) if match: target, help = match.groups() output.append("%-10s %s" % (target, help)) # Sort the output in alphanumeric order output.sort() # Print the help result print('\n'.join(output)) endef export PRINT_HELP_PYSCRIPT # End of python section help: @python -c "$$PRINT_HELP_PYSCRIPT" < $(MAKEFILE_LIST)

Next, add concise docstrings for every Makefile command. Here's a trio of examples:

env: ## Activate the virtual environment source venv/bin/activate test: ## Runs the test suite python manage.py test --thing=stuff run: ## Start the dev server python manage.py runserver

Notice how each command's docstring starts with two pound signs? The "##"? That's what the auto documenter code needs to find the docstring.

Trying it out!

When I type just make without any arguments, by default that triggers the help function, which runs the Python script at the top of the makefile. What I get is this:

$ make env Activate the virtual environment run Start the dev server test Runs the test suite

The results have been alphabetized, with comments displayed for each command. Very useful!

The Whole File .DEFAULT_GOAL := help # Sets default action to be help define PRINT_HELP_PYSCRIPT # start of Python section import re, sys output = [] # Loop through the lines in this file for line in sys.stdin: # if the line has a command and a comment start with # two pound signs, add it to the output match = re.match(r'^([a-zA-Z_-]+):.*?## (.*)$$', line) if match: target, help = match.groups() output.append("%-10s %s" % (target, help)) # Sort the output in alphanumeric order output.sort() # Print the help result print('\n'.join(output)) endef export PRINT_HELP_PYSCRIPT # End of python section help: @python -c "$$PRINT_HELP_PYSCRIPT" < $(MAKEFILE_LIST) env: ## Activate the virtual environment source venv/bin/activate test: ## Runs the test suite python manage.py test --thing=stuff run: ## Start the dev server python manage.py runserver

Categories: FLOSS Project Planets

MidCamp - Midwest Drupal Camp: MidCamp 2022 Canceled

Planet Drupal - Fri, 2022-01-14 15:48
MidCamp 2022 Canceled

As discussed in October/November we’ve been waiting things out to make further plans for MidCamp 2022. We’re still not confident enough in the state of the world in March to continue making plans for MidCamp and as such the leadership team has decided to cancel the event for this year.

I’d like to thank all of you for your persistence and dedication to MidCamp throughout the pandemic. We’ve pushed the entire Drupal community forward in thinking about virtual events—we made them more inclusive, more fun, and more engaging and we all have a lot to be proud of.

Going forward, the Chicago Drupal community could really use some new leadership. If you're interested in answering the call, join the conversation on the MidCamp Slack.

What’s next is up to you. I appreciate you all. Be safe.

Best,
Avi

Categories: FLOSS Project Planets

Python Insider: Python 3.10.2, 3.9.10, and 3.11.0a4 are now available

Planet Python - Fri, 2022-01-14 13:11

Before we begin the usual round of release notes, please do note that the three new versions of Python released today do not contain Windows installers yet. This is temporary, due to a more complex than expected code signing certificate renewal.

We’ve held the releases all week while the situation is getting resolved but the urgency of 3.10.2 in particular made us release without the Windows installers after all. We apologize for the inconvenience and are doing everything we can to put the Windows installer in place as soon as possible.

We’re rooting for both Ee Durbin and Steve Dower who are helping us resolve this. Thanks for your hard work! Hopefully, by this time next week, this will only be a footnote in release management history.

The releases you’re looking at were all cursed in some way. What a way to start 2022! Besides the certificate hold up, Python 3.10.2 is an expedited release (you’ll want to upgrade, read below!), Python 3.11.0a4 had almost 20 (sic, twenty!) release blockers before being finally green, and Python 3.9.10 was made from a new M1 Mac on macOS Monterey which made the usually boring process quite a ride. We’re hoping 2022 won’t be this intense all year!

Python 3.10.2

Get it here: https://www.python.org/downloads/release/python-3102/

This is a special bugfix release ahead of schedule to address a memory leak that was happening on certain function calls when using Cython. The memory leak consisted of a small constant amount of bytes in certain function calls from Cython code. Although in most cases this was not very noticeable, it was very impactful for long-running applications and certain usage patterns. Check bpo-46347 for more information.

Upgrading existing Python 3.10 installations is highly recommended. Even though this is an expedited release, it still contains over 100 other bug fixes. See the change log for details.

The next Python 3.10 maintenance release will be 3.10.3, currently scheduled for 2022-04-04.

Python 3.9.10

Get it here: https://www.python.org/downloads/release/python-3910/

Python 3.9.10 is the ninth maintenance release of the legacy 3.9 series. Note: Python 3.10 is now the latest feature release series of Python 3.

Python 3.9 micro-releases enter double digits! There’s been 130 commits since 3.9.9 which is a higher number of fixes for this stage of the life cycle compared to 3.8. See the changelog for details on what changed.

As a reminder, on macOS, the default installer is now the new universal2 variant. It’s compatible with Mac OS X 10.9 and newer, including macOS 11 Big Sur and macOS 12 Monterey. Python installed with this variant will work natively on Apple Silicon processors.

The next Python 3.9 maintenance release will be 3.9.11, currently scheduled for Pi Day '22 (2022-03-14).

Python 3.11.0a4

Get it here: https://www.python.org/downloads/release/python-3110a4/

Python 3.11 is still in development. This release, 3.11.0a4, is the fourth of seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of new features and bug fixes by the community, as well as to test the release process.

During the alpha phase, features may be added up until the start of the beta phase (2022-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2022-08-01). Please keep in mind that this is a preview release and its use is not recommended for production environments.

Many new features for Python 3.11 are still being planned and written. Among the new major new features and changes so far:

  • PEP 657 – Include Fine-Grained Error Locations in Tracebacks
  • PEP 654 – Exception Groups and except*
  • The Faster CPython Project is already yielding some exciting results: this version of CPython 3.11 is ~ 19% faster on the geometric mean of the PyPerformance benchmarks, compared to 3.10.0.
  • (Hey, fellow core developer, if a feature you find important is missing from this list, let Pablo know.)

The next pre-release of Python 3.11 will be 3.11.0a5, currently scheduled for Wednesday, 2022-02-02.

Python 3.6 is pining for the fjords

Python 3.6 is no more. It’s an ex-Python. It has ceased to be. On December 23rd 2021 is has reached its end-of-life phase after five successful years.

It’s been the first truly popular Python 3 release, introducing f-strings to the world and making big improvements to both asyncio (async generators!) and typing (variable annotations!).

We’d like to congratulate Ned Deily @nad on successfully driving the 3.6 series to completion as Release Manager. He’s not fully retired yet, as 3.7, which he is also managing, is still receiving security patches until June 2023.

We hope you enjoy the new releases

Your friendly release team,
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv

Categories: FLOSS Project Planets

Debian Social Team: Some site updates

Planet Debian - Fri, 2022-01-14 13:01
  • Pleroma has been updated to version 2.4.1. We also suffered some downtime during the 11th of January. Upgrading to the latest version fixed our issues.
  • Peertube has been upgraded to version 4.0.0.
  • Jitsi Meet has been upgraded to version 2.0.6726.
  • Mjolnr has been upgraded to 1.2.1.
  • Our upgrade to bullseye is complete, we haven’t encountered any problems upgrading to bullseye \o/.

Categories: FLOSS Project Planets

SFXR-Qt 1.4.0 is out!

Planet KDE - Fri, 2022-01-14 11:47

Last release of SFXR-Qt was in September 2019. I kept using it for Pixel Wheels, it had its quirks and bugs but I did not have the time and motivation to work on it, so the poor app was left on its own for more than two years.

Fast forward to November 2021: SFXR-Qt was added to Debian! It always feels good to see an app getting more widespread, with the minor issue that I learned about it because tests did not pass on big-endian machines... Working on that bug was a bit frustrating because I do not own a big-endian machine and failed to setup a working big-endian VM to test my changes on, but after a few blind fixes I eventually got it fixed. Kudos to Alex Myczko, the bug reporter, for the responsiveness in testing my changes.

Entering Debian probably gave a bit more exposure to the app, because I then received a bug report for that crash I had known for a long time but never got to fix... Now that someone else reported it, I finally fixed it.

Then I received a nice pull request from Linus Vanas implementing command-line export. After a few iterations it got merged, so you can now export sounds from your terminal:

$ sfxr-qt --export tests/fixtures/synthesizer/input/power-up.sfxj --help Usage: sfxr-qt [options] sound_file Options: -h, --help Displays this help. -v, --version Displays version information. --export Creates a wav file from the given SFXR file and exits. -o, --output <path> Specifies the path for the file created with --export. -b, --bits <number> Specifies the bits per sample for the wav file created with --export. Supported values are 8 and 16. -r, --rate <number> Specifies the samplerate for the wav file created with --export. Supported values are 22050 and 44100. Arguments: sound_file File to load. $ sfxr-qt --export --bits 16 --rate 44100 --output power-up.wav power-up.sfxj $ mediainfo power-up.wav General Complete name : power-up.wav Format : Wave File size : 46.9 KiB Duration : 544 ms Overall bit rate mode : Constant Overall bit rate : 706 kb/s Audio Format : PCM Format settings : Little / Signed Codec ID : 1 Duration : 544 ms Bit rate mode : Constant Bit rate : 705.6 kb/s Channel(s) : 1 channel Sampling rate : 44.1 kHz Bit depth : 16 bits Stream size : 46.9 KiB (100%)

I also made some infrastructure improvements, mainly aligning the project structure with the way cookiecutter-qt-app generates projects, so that future improvements to the cookiecutter can be applied to SFXR-Qt as well.

Finally SFXR-Qt gained a "Randomize" button, based on the same feature from the original SFXR.

That's it for this release, sources are available here. There are also deb and rpm packages on the release page. I hope you enjoy creating fun retro sound effects with SFXR-Qt!

Categories: FLOSS Project Planets

Web Review, Week 2022-02

Planet KDE - Fri, 2022-01-14 11:36

Let’s go for my web review for the week 2022-02.

Facebook collecting people’s data even when accounts are deactivated

Tags: tech, facebook, gafam, surveillance

Ever had a Facebook account? Deactivated it since then? Well apparently the surveillance anti-feature is for life… Don’t be fooled, just delete it, which is apparently harder than it sounds.

https://digiday.com/media/why-facebook-keeps-collecting-peoples-data-and-building-their-profiles-even-when-their-accounts-are-deactivated/


Is Google Search Deteriorating? Measuring Google’s Search Quality in 2022

Tags: tech, google, bing, search

Interesting look at the results from two search engines and seeing where they’re good and where they fail.

https://www.surgehq.ai/blog/is-google-search-deteriorating-measuring-search-quality-in-2022


UltraRAM Breakthrough Brings New Memory and Storage Tech to Silicon | Tom’s Hardware

Tags: tech, memory, storage, performance

Still very early days, but if that gets industrialized and the prices are not too horrible, this could bridge the gap in access times between memory and storage.

https://www.tomshardware.com/news/ultraram-implemented-in-silicon-for-first-time


Simplicity of IRC - Susam’s Maze

Tags: tech, irc, low-tech, simplicity

Don’t use it much anymore for various reasons, but I still find the simplicity of IRC still appealing and elegant. It is a really neat protocol.

https://susam.net/maze/simplicity-of-irc.html


Make the Internet Yours Again With an Instant Mesh Network | The Changelog

Tags: tech, networking, ip, decentralized

Looks like a very interesting approach. This is still clearly for techies though, but time will tell.

https://changelog.complete.org/archives/10319-make-the-internet-yours-again-with-an-instant-mesh-network


Perspective · Streaming Analytics via WebAssembly

Tags: tech, data-visualization, web

This looks like a very interesting dataviz framework.

https://perspective.finos.org/


The Optional Chaining Operator, “Modern” Browsers, and My Mom - Jim Nielsen’s Blog

Tags: tech, web, obsolescence, javascript

Or why upgrades need to happen with care, especially with an open platform like the web…

https://blog.jim-nielsen.com/2022/a-web-for-all/


Who wrote this shit? | Philip Heltweg

Tags: tech, programming

Always remember the human beings and the context behind the code you are looking at.

https://www.heltweg.org/posts/who-wrote-this-shit/


The 7 Code Review Manners. Not the code review we need but the code review we deserve

Tags: tech, programming, codereview

Not very profound but definitely useful tips on how to handle reviews.

https://reutsharabani.medium.com/the-7-code-review-manners-f0f0eef4d3e5


Haskell for all: Funding isn’t the problem with open source

Tags: tech, free-software, ethics

Interesting piece which points out (despite its title) that it’s not simply about funding, this is also about the relationship between projects and large companies which try to squeeze value out of them.

https://www.haskellforall.com/2021/12/funding-isnt-problem-with-open-source.html


Toxic Culture Is Driving the Great Resignation

Tags: management, hr, culture

Interesting exploration on why we see a large resignation movement (at least in the US, the study is US centric anyway). It’s clearly not only about wages and they are other even more powerful forces at play. First and foremost: mind your corporate culture.

https://sloanreview.mit.edu/article/toxic-culture-is-driving-the-great-resignation/


Bye for now!

Categories: FLOSS Project Planets

Real Python: The Real Python Podcast – Episode #93: Launching Python, Virtual Environments, and Locking Dependencies With Brett Cannon

Planet Python - Fri, 2022-01-14 07:00

Would you like a simple command to launch your Python programs using the newest version of the language installed on your machine? This week on the show, we continue our conversation with Brett Cannon. Brett discusses his project, the Python Launcher for Unix.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Categories: FLOSS Project Planets

Will McGugan: Weeknotes

Planet Python - Fri, 2022-01-14 06:20

I'm trialing the idea of Weeknotes, a weekly summary of what I've done / learned in the prior week. Inspired by Simon Willison who has an uncanny ability to respond to a tweet with a link to a weeknote of his containing just the information you needed. These will be a little rougher, a little less edited, than my usual content. But the point is to get something out there and to develop the habit of writing.

The investment for Textualize landed at the end of last year, just before Christmas. Naturally I was on a bit of a high. This last week-and-a-half I've come down to earth and settled in to a routine of going in to the office every day (something I swore I'd never do again). And it's not so bad.

I'm joined by @_darrenburns as my first employee. We will be working on Rich / Textual and the as-yet-unannounced Textualize we service.

This week we (mostly Darren) discovered two issues related to emojis in terminals.

Terminals have patchy support for multi-codepoint emojis. There are certain emojis which are composed of multiple codepoints that when combined produce a single glyph. Run the following code to illustrate this:

a = "🤚" b = "👨‍👩‍👧‍👧" print(len(a)) print(len(b)) print(a) print(b)

The output of the last two lines is highly dependent on which terminal you are using. It is not correlated to the unicode database used by the terminal. Some terminals just don't know how to render these emojis. It's unfortunate, but there isn't much that Rich or Textual could do to guarantee these render correctly.

The second discovery is more positive. Darren discovered that wcwidth has an error in transcribing certain emoji widths from the unicode database. Consequently a large number of emojis were being reported as 1 cell width that render as 2 cell widths. The emojis in question probably represented the majority of the emoji issues in the Rich repo. The fix will be in the next version of Rich.

I have been working on the server that will power our web service. I chose FastAPI as the stack for that because it has a really elegant way of exposing a REST API, and because it is built on Starlette which claims good support for websockets. The product I have in mind will really put that claim to the test.

One of the first tasks in this web service is to define packets that will be sent over the wire by websockets. There will be a large number of these packets, each of which require a class definition. Writing these out by hand is tedious and error prone. I'd rather use a declarative approach as championed by dataclasses, namedtuples, attrs, PyDantic, and friends. For my packets classes, I chose "none of the above".

My solution might horrify some folks, but I settled on code generation. I have a yml file that describes the packets, which is parsed and run through a Jinja2 template, processed by black, and finally spits out packets.py. This resulting file is precisely what I need, as though I had hand written each class. But without any magic, which means there is no runtime cost when you import it, and future developers can see exactly how each class works.

The only downside is that I run a build step whenever I change the yml file, but it is a small price to pay. If anyone wants to talk me out of it, I will refer them to this tweet:

I like the auto-generated class idea.

— David Beazley (@dabeaz) January 12, 2022

Next week I am going to tackle implementing a Windows driver for Textual, which is the most common request I get. In theory it will be relatively straightforward. Textual has an abstract "Driver" class which I can replace with a Windows version. There are also a number of TUI related Python projects I can refer to.

Follow @willmcgugan for more Weeknotes and Textual updates.

Categories: FLOSS Project Planets

Ned Batchelder: Cog resurgence

Planet Python - Fri, 2022-01-14 06:05

My cog tool has been having a resurgence of late: a number of people are discovering it’s useful to run a little bit of Python code inside otherwise static files.

It took cog 17 years to become an overnight success :)
(first posted Feb 2004: https://t.co/Zmtrdy0by9) https://t.co/DON9THZ5wh

— Ned Batchelder (@nedbat) November 22, 2021

Hynek Schlawack used it to de-duplicate his pyproject.toml:

As a test balloon, I’ve switched structlog from https://t.co/PihDrIF58S to flit w/ pyproject.toml in combination with @nedbat’s cog to maintain some deduplication. I think I like it! Sharp tools that do one thing well FTW.https://t.co/w2RM4Ckyke

— Hynek Schlawack (@hynek) November 17, 2021

Automator extraordinaire Simon Willison started using it to keep docs up to date:

I’ve been solving so many documentation problems with @nedbat’s cog tool recently - it’s fantastic for keeping documentation automatically up-to-date, in Markdown or rST)

Here’s a new page of sqlite-utils docs showing --help for every CLI command! https://t.co/Dwef9p2h8P pic.twitter.com/8tyfyfe7AT

— Simon Willison (@simonw) January 11, 2022

Brett Cannon even called it trendy!

A quick, public thanks to @nedbat for creating Cog; I did the “trendy” thing and used Cog to automate the README for the Python Launcher for Unix (instead of using my home-grown solution). Makes editing the README simple again!https://t.co/F5jnqgW7cG

— Brett Cannon (@brettsky) December 31, 2021

Of course, some people were using it before it was cool.

With all this buzz(!), Tobias Macey invited me on podcast.__init__ to talk about it: Episode 347: Generate Your Text Files With Python Using Cog. It was fun to talk about this little tool I wrote nearly 18 years ago that has been plugging away all this time, and is now being re-discovered.

Even I am finding new uses for cog. I started using it to keep coverage.py docs up to date, I built my crazy over-engineered GitHub profile (source) with it, and I even used it on the source file of this blog post to pull in the tweets!

Categories: FLOSS Project Planets

ItsMyCode: [Solved] Pandas TypeError: no numeric data to plot

Planet Python - Fri, 2022-01-14 04:30

ItsMyCode |

In Pandas, we can only plot values with the numeric data type. If you try to plot with any other Data Type other than numeric data, Python will raise TypeError: no numeric data to plot.

In this article, we will see what exactly “TypeError: no numeric data to plot” means and how to resolve this with examples.

What is TypeError: no numeric data to plot?

The error occurs mainly when you attempt to plot values from pandas DataFrame, but it turns out there are no numeric values present in DataFrame.

The common mistake developers make is to assume that a certain column in the DataFrame is numeric, but actually, it will be of a different type.

Let us take a simple example to reproduce this issue.

In the below example, we have cricket teams, and we will create a line plot for the columns points, runrate, and wins using Pandas DataFrame.

# import pandas library import pandas as pd import matplotlib.pyplot as plt # create pandas DataFrame df = pd.DataFrame({'team': ['India', 'South Africa', 'New Zealand', 'England'], 'points': ['10', '8', '3', '5'], 'runrate': ['0.5', '1.4', '2', '-0.6'], 'wins': ['5', '4', '2', '2']}) # print the data frame print(df) df[['points', 'runrate', 'wins']].plot() plt.show()

Output

TypeError: no numeric data to plot

When you run the program, Python will raise TypeError: no numeric data to plot.

If you look at the code at first glance, all the columns represent numeric values. However, if you check the type of each column, you will see that it is of type object.

We can check the data type of each column using the dtpyes function.

print(df.dtypes) # Displays the Data Type of each column in Pandas DataFrame print(df.dtypes) # Output team object points object runrate object wins object dtype: object

If you look at the output, none of the columns in the DataFrame are numeric, and it is of type object.

How to fix TypeError: no numeric data to plot?

We can resolve the TypeError by converting the data to be plotted into numeric data. 

There are 2 methods available to convert the data into numeric values while plotting the DataFrame columns.

Method 1: Using DataFrame.astype() function

The DataFrame.astype() method is used to cast the Pandas object into a specific data type.

Syntax:

df['column_name']= df['column_name'].astype(data_type)

Let us resolve the issue by converting the Pandas object to numeric dtype using astype() function.

# import pandas library import pandas as pd import matplotlib.pyplot as plt # create pandas DataFrame df = pd.DataFrame({'team': ['India', 'South Africa', 'New Zealand', 'England'], 'points': ['10', '8', '3', '5'], 'runrate': ['0.5', '1.4', '2', '-0.6'], 'wins': ['5', '4', '2', '2']}) # print the data frame print(df) # convert the columns to numeric using astype() function df['points']=df['points'].astype(float) df['runrate']=df['runrate'].astype(float) df['wins']=df['wins'].astype(float) df[['points', 'runrate', 'wins']].plot() plt.show()

Output

We are able to plot the lines successfully as the columns are converted to numeric values. We can check the dtypes once again by using dtypes function.

# Displays the Data Type of each column in Pandas DataFrame print(df.dtypes) # Output team object points float64 runrate float64 wins float64 dtype: object Method 2 :Using pandas.to_numeric() function

The pandas.to_numeric() function is used to convert the argument to a numeric type.

The default return dtype is float64 or int64, depending on the data supplied. We can use the downcast parameter to obtain other dtypes.

Syntax:

df['column_name'] = pd.to_numeric(df['column_name'])

Let us resolve the issue by converting the Pandas object to numeric dtype using to_numeric() function.

# import pandas library import pandas as pd import matplotlib.pyplot as plt # create pandas DataFrame df = pd.DataFrame({'team': ['India', 'South Africa', 'New Zealand', 'England'], 'points': ['10', '8', '3', '5'], 'runrate': ['0.5', '1.4', '2', '-0.6'], 'wins': ['5', '4', '2', '2']}) # print the data frame print(df) # convert the columns to numeric using to_numeric() function df['points']=pd.to_numeric(df['points']) df['runrate']=pd.to_numeric(df['runrate']) df['wins']=pd.to_numeric(df['wins']) print(df.dtypes) df[['points', 'runrate', 'wins']].plot() plt.show()

Output

[Solved] TypeError: no numeric data to plot

We are able to plot the lines successfully as the columns are converted to numeric values (int and float). We can check the dtypes once again by using dtypes function.

# Displays the Data Type of each column in Pandas DataFrame print(df.dtypes) # Output team object points int64 runrate float64 wins int64 dtype: object Conclusion

The TypeError: no numeric data to plot occurs mainly when you attempt to plot values from pandas DataFrame, but it turns out there are no numeric values present in DataFrame.

We can resolve the TypeError by converting the data to be plotted into numeric data. There are 2 methods available to convert the data into numeric values while plotting the DataFrame columns.

  • Convert to numeric using DataFrame.astype() function
  • Convert to numeric using pandas.to_numeric() function

The post [Solved] Pandas TypeError: no numeric data to plot appeared first on ItsMyCode.

Categories: FLOSS Project Planets

LakeDrops Drupal Consulting, Development and Hosting: State of ECA: What's new in Drupal's new rules engine with beta-2

Planet Drupal - Fri, 2022-01-14 03:36
State of ECA: What's new in Drupal's new rules engine with beta-2 jurgenhaas Fri, 01/14/2022 - 09:36

in has been intense over the last 4 months, since we first presented this new

What's known as plugin or addon in other platforms, is what we call a module in the Drupal universe. Drupal core itself is a a collection of modules as well and the community has added and maintains tens of thousands of individual modules on top of that.

to the

The enterprise OpenSource content management system which is available for free at https://www.drupal.org where you can find all the details and also references.

Drupal has a very active community with tens of thousands of developers all around the world and they also have a huge focus on standard compliance and on security.

community. Let's catch up with all the features and ideas, that already made it into it.

Who is working on it

In addition to the code maintainers Daniel, Jürgen, Max and Richard we also have supporting team members like Nico who contributed a nice logo, Ralf who helps us to get the word out and provides feedback - and a few others who already started using ECA and report back in the issue queue with issues and feature requests. This helped us a lot to stay focused and move towards a first stable release in such a short period of time.

How we moved forward

Although still in early stage, we optimized the core components by changing how ECA stores its config entities, as well as the caching mechanism to further reduce the performance impact when using ECA in production environments. The overhead ECA brings to your live site is negligible, it only consumes resources if something needs to be done as a result of configured events that your ECA models want to react upon.

The code structure got an overhaul too. There is now ECA Core which provides the config entity handling, the ECA processor, all required plugin managers and numerous interfaces, traits and base classes used by the now 10 submodules that comes with ECA:

  • ECA Base: provides access to context, cron, custom events, state system and tokens
  • ECA Config: integrates with Drupal's CMI
  • ECA Content: supports content entities, fields API and more tokens
  • ECA Form: integrates with Drupal's form API
  • ECA Migrate: integrates with events of the migrate module
  • ECA Misc: make available events from Symfony's kernel, Drupal core and the routing system
  • ECA Queue: allows to enqueue tasks for asynchronous or scheduled processing
  • ECA User: integrates with user account related events and actions like login, logout, cancel, account switching and roles
  • ECA Views: allows processing of views with further processing or exporting of the result set
  • ECA

    Working in teams, but also for individuals, it is helpful if not required to define the key processes, especially those that will be repeated, in a structured way. Such a definition is then called a workflow and it serves multiple purposes. First of all it can be used as a checklist such that the people in charge of a task can walk through the workflow and followed the previously specified sequence. In addition, a workflow definition improves quality of output as it almost guarantees the final result of such a process to meet the standards previously defined. And last but not least, such a workflow specification is excellent input for somebody who is in charge of developing the automation of very regular tasks.

    : integrates into Drupal's content moderation framework

Note that all of ECA depends solely on Drupal core and the new remarkable Context Stack module from Max, which we extracted from the ECA code base simply because its functionality is useful for other tools too. This is intentional so that you can easily onboard ECA without the requirement to have any other components being installed or enabled.

General features built into ECA core

With all the submodules enumerated above, you already get comprehensive lists of events, conditions and actions from either ECA or from Drupal core. Additionally, ECA has baked-in support for crucial APIs and functionality, that needs highlighting:

  • Context Stacks: each process triggered by any event as well as any action of such processes get executed within their own (stackable) context, so that ECA can restore the context after execution to the state it was right before processing. This not only makes each process predictable, but also allows to forward the current context into the queue, should a model want to process actions asynchronously.
  • Caching: all ECA models get cached in a special way such that ECA can determine, with almost no overhead, whether any of the triggered events in your Drupal site needed to be processed by ECA.
  • Loops: by default, actions in an ECA model operate on some data object, which often is something like a content entity, a route, an HTTP request or any other arbitrary value. If you provide a list of objects instead of a single instance, then ECA automatically loops over each of them with the subsequent actions in the process model.
  • Logging: everything in ECA is built to provide detailed log information, which is written to Drupal's logger service. It depends on your own setup, if that logging information is being written to watchdog, syslog or elsewhere. To avoid overwhelming logs just from ECA, you can configure the level of log information coming from ECA with a single setting, defaulting to error messages and exceptions only.
  • States: reading and writing from and to Drupal's state system helps to persist some data for later use, even if this is required over a longer timeframe.
  • Tokens: Drupal core's token environment is already pretty powerful. ECA builds on top of it and enhances it by introducing DTOs (Data Transfer Objects). This mechanism allows any event, condition or action in an ECA model to store any data into the token environment so that subsequent components of that model can access that data for further processing if needed.
  • TypedData: one of the most significant features and presumably the most used conditions and actions are around entity fields. Those fields can be more complex than just storing individual values, they can even store values with any cardinality. To allow ECA models generic access to any component of such fields, the TypedData API is the ideal tool provided by Drupal core, which has been utilized by ECA.
  • Recursion prevention: it may happen unintentionally, but ECA models, like any other rule definition, can quickly end up in a recursion. The simplest use case might be an entity update, which results in a process that makes additional modifications to that entity - being another entity update that already starts a recursion. As this would always lead towards an infinite loop, something you prefer not to experience on your production site, ECA inevitably prevents that from happening. Even at the cost of preventing you from building certain models. However, there should always be a way around that - and the issue queue on drupal.org or this Slack channel are great places to seek help in such situations.
Working on test coverage

We've already started building tests, from simple unit test to kernel and functional tests, but also a powerful framework to test any ECA model regardless how complex they are. This helps us to keep moving with ECA development while ensuring that existing functionality remains intact. Having said that, there's a lot that needs to be done to bring the test coverage to the necessary level. This is what we're focussing on in the weeks to come.

Integrating with other modules

Now that ECA core with all its integrated submodules stabilizes its own APIs, the time is right to start working with other maintainers of popular and useful modules, to make their functionality available to ECA and its models. The list of modules, we would like to integrate with, is being tracked in this issue and if anyone wanted to add more modules to the list, this is the right place to get the ball rolling.

Talking about the UI provided by modellers

As powerful and feature rich the ECA framework already is, it still requires the UI component which allows users to create and maintain their models. This is a separate task and completely decoupled from ECA as the backend processor. The component we're talking about here is called a modeller. And there can be more than just one. BPMN as one of the popular standards to describe business processes is supported by a variety of applications that allow to work with such models, two of which have already been integrated with ECA: Camunda and BPMN.iO. But others, even such that are not based on BPMN, can be integrated as well, and we hope to see initiatives who want to get started on such modeller development.

However, what matters to all the existing and future modeller UIs, is a great user experience (UX). This is what we haven't worked on yet for the existing integrations, and that's one of the areas where we have to spend more resources - but we also need help for that. The existing ECA team is busy with all the processing and background tasks. To move more quickly with the UI too, we're seeking for help.

Conclusion

A lot has been achieved! And I mean, A LOT. The team is really proud of it and feedback we receive is very positive too. We even consider ECA very close to being feature-complete for its 1.0 release soon. Yes, we admit, there is a way to go before it will be usable by "mainstream" users. The UI components mentioned above as well as comprehensive documentation are just the 2 main tasks that come to mind.

Having said that, it turns out that ECA not only accomplished its original objective to provide a "Rules" replacement for Drupal 9 and beyond, it also delivers benefits above and beyond that mission with 2 additional wins:

  1. Reduce the likelihood of writing a custom module for a client, only because you required a hook or a form alter function, that can now also been done with ECA.
  2. Eliminate the requirement for a number of helper modules that provide simple functionality like redirects after login or validating, stripping, trimming or otherwise manipulating certain fields.

In other words, the feature set provided by ECA is huge, yet it can reduce the complexity of any Drupal installation out there. And while doing it this way, ECA also improves transparency and maintainability by storing all the rules in one place, where it can be visualized, reviewed and even moderated so that all stakeholders get a better understanding of what's being implemented and configured at any given time. It also increases accessibility for users who understand the business logic implemented into a Drupal site but wouldn't ever be able or willing to dive deep into Drupal logic or even code base.

Let's move on with ECA, it's got that far that we're all very excited and motivated to move it over the finish line. Watch this space to stay up to date - or reach out on drupal.org or in Slack, if you either have ideas, feature requests or resources to help us get all this done.

Tags Tools Drupal Projects ECA: Event - Condition - Action Add new comment
Categories: FLOSS Project Planets

Future of “my” packages in Debian

Planet KDE - Thu, 2022-01-13 21:17

After having been (again) demoted (timed perfectly to my round birthday!) based on flimsy arguments, I have been forced to rethink the level of contribution I want to do for Debian. Considering in particular that I have switched my main desktop to dual-boot into Arch Linux (all on the same btrfs fs with subvolumes, great!) and have run Arch now for several days exclusively, I think it is time to review the packages I am somehow responsible for (full list of packages).

After about 20 years in Debian, time to send off quite some stuff that has accumulated over time.

KDE/Plasma, frameworks, Gears, and related packages

All these packages are group maintained, so there is not much to worry about. Furthermore, a few new faces have joined the team and are actively working on the packages, although mostly on Qt6. I guess that with me not taking action, frameworks, gears, and plasma will fall back over time (frameworks: Debian 5.88 versus current 5.90, gears: Debian 21.08 versus current 21.12, plasma uptodate at the moment).

With respect to my packages on OBS, they will probably also go stale over time. Using Arch nowadays I lack the development tools necessary to build Debian packages, and above all, the motivation.

I am sorry for all those who have learned to rely on my OBS packages over the last years, bringing modern and uptodate KDE/Plasma to Debian/stable, please direct your complaints at the responsible entities in Debian.

Cinnamon

As I have written already here, I have reduced my involvement quite a lot, and nowadays Fabio and Joshua are doing the work. But both are not even DM (AFAIR) and I am the only one doing uploads (I got DM upload permissions for it). But I am not sure how long I will continue doing this. This also means that in the near future, Cinnamon will also go stale.

TeX related packages

Hilmar has DM upload permissions and is very actively caring for the packages, so I don’t see any source of concern here. New packages will need to find a new uploader, though. With myself also being part of upstream, I can surely help out in the future with difficult problems.

Calibre and related packages

Yokota-san (another DM I have sponsored) has DM upload permissions and is very actively caring for the packages, so also here there is not much of concern.

Onedrive

This is already badly outdated, and I recommend using the OBS builds which are current and provide binaries for Ubuntu and Debian for various versions.

ROCm

Here fortunately a new generation of developers has taken over maintenance and everything is going smoothly, much better than I could have done, yeah to that!

Qalculate related packages

These are group maintained, but unfortunately nobody else but me has touched the repos for quite some time. I fear that the packages will go stale rather soon.

isync/mbsync

I have recently salvaged this package, and use it daily, but I guess it needs to be orphaned sooner or later.

CafeOBJ

While I am also part of upstream here, I guess it will be orphaned.

Julia

Julia is group maintained, but unfortunately nobody else but me has touched the repo for quite some time, and we are already far behind the normal releases (and julia got removed from testing). While go stale/orphaned. I recommend installing upstream binaries.

python-mechanize

Another package that is group maintained in the Python team, but with only me as uploader I guess it will go stale and effectively be orphaned soon.

xxhash

Has already by orphaned.

qpdfview

No upstream development, so not much to do, but will be orphaned, too.

Categories: FLOSS Project Planets

Norbert Preining: Future of “my” packages in Debian

Planet Debian - Thu, 2022-01-13 21:17

After having been (again) demoted (timed perfectly to my round birthday!) based on flimsy arguments, I have been forced to rethink the level of contribution I want to do for Debian. Considering in particular that I have switched my main desktop to dual-boot into Arch Linux (all on the same btrfs fs with subvolumes, great!) and have run Arch now for several days exclusively, I think it is time to review the packages I am somehow responsible for (full list of packages).

After about 20 years in Debian, time to send off quite some stuff that has accumulated over time.

KDE/Plasma, frameworks, Gears, and related packages

All these packages are group maintained, so there is not much to worry about. Furthermore, a few new faces have joined the team and are actively working on the packages, although mostly on Qt6. I guess that with me not taking action, frameworks, gears, and plasma will fall back over time (frameworks: Debian 5.88 versus current 5.90, gears: Debian 21.08 versus current 21.12, plasma uptodate at the moment).

With respect to my packages on OBS, they will probably also go stale over time. Using Arch nowadays I lack the development tools necessary to build Debian packages, and above all, the motivation.

I am sorry for all those who have learned to rely on my OBS packages over the last years, bringing modern and uptodate KDE/Plasma to Debian/stable, please direct your complaints at the responsible entities in Debian.

Cinnamon

As I have written already here, I have reduced my involvement quite a lot, and nowadays Fabio and Joshua are doing the work. But both are not even DM (AFAIR) and I am the only one doing uploads (I got DM upload permissions for it). But I am not sure how long I will continue doing this. This also means that in the near future, Cinnamon will also go stale.

TeX related packages

Hilmar has DM upload permissions and is very actively caring for the packages, so I don’t see any source of concern here. New packages will need to find a new uploader, though. With myself also being part of upstream, I can surely help out in the future with difficult problems.

Calibre and related packages

Yokota-san (another DM I have sponsored) has DM upload permissions and is very actively caring for the packages, so also here there is not much of concern.

Onedrive

This is already badly outdated, and I recommend using the OBS builds which are current and provide binaries for Ubuntu and Debian for various versions.

ROCm

Here fortunately a new generation of developers has taken over maintenance and everything is going smoothly, much better than I could have done, yeah to that!

Qalculate related packages

These are group maintained, but unfortunately nobody else but me has touched the repos for quite some time. I fear that the packages will go stale rather soon.

isync/mbsync

I have recently salvaged this package, and use it daily, but I guess it needs to be orphaned sooner or later.

CafeOBJ

While I am also part of upstream here, I guess it will be orphaned.

Julia

Julia is group maintained, but unfortunately nobody else but me has touched the repo for quite some time, and we are already far behind the normal releases (and julia got removed from testing). While go stale/orphaned. I recommend installing upstream binaries.

python-mechanize

Another package that is group maintained in the Python team, but with only me as uploader I guess it will go stale and effectively be orphaned soon.

xxhash

Has already by orphaned.

qpdfview

No upstream development, so not much to do, but will be orphaned, too.

Categories: FLOSS Project Planets

Dirk Eddelbuettel: Rcpp 1.0.8: Updated, Strict Headers

Planet Debian - Thu, 2022-01-13 20:03

The Rcpp team is thrilled to share the news of the newest release 1.0.8 of Rcpp which hit CRAN today, and has already been uploaded to Debian as well. Windows and macOS builds should appear at CRAN in the next few days. This release continues with the six-months cycle started with release 1.0.5 in July 2020. As a reminder, interim ‘dev’ or ‘rc’ releases will alwasys be available in the Rcpp drat repo; this cycle there were once again seven (!!) – times two as we also tested the modified header (more below). These rolling release tend to work just as well, and are also fully tested against all reverse-dependencies.

Rcpp has become the most popular way of enhancing R with C or C++ code. Right now, around 2478 packages on CRAN depend on Rcpp for making analytical code go faster and further, along with 242 in BioConductor.

This release finally brings a change we have worked on quite a bit over the last few months. The idea of enforcing the setting of STRICT_R_HEADERS was prososed years ago in 2016 and again in 2018. But making such a chance against a widely-deployed code base has repurcussions, and we were not ready then. Last April, this was revisited in issue #1158. Over the course of numerous lengthy runs of tests of a changed Rcpp package against (essentially) all reverse-dependencies (i.e. packages which use Rcpp) we identified ninetyfour packages in total which needed a change. We provided either a patch we emailed, or a GitHub pull request, to all ninetyfour. And we are happy to say that eighty cases were resolved via a new CRAN upload, with a seven more having merged the pull request but not yet uploaded.

Hence, we could make the case to CRAN (who were always CC’ed on the monthly ‘nag’ emails we sent to maintainers of packages needing a change) that an upload was warranted. And after a brief period for their checks and inspection, our January 11 release of Rcpp 1.0.8 arrived on CRAN on January 13.

So with that, a big and heartfelt Thank You! to all eighty maintainers for updating their packages to permit this change at the Rcpp end, to CRAN for the extra checking, and to everybody else who I bugged with the numerous emails and updated to the seemingly never-ending issue #1158. We all got this done, and that is a Good Thing (TM).

Other than the aforementioned change which will not automatically set STRICT_R_HEADERS (unless opted out which one can), a number of nice pull request by a number of contributors are included in this release:

  • Iñaki generalized use of finalizers for external pointers in #1180
  • Kevin ensured include paths are always quoted in #1189
  • Dirk added new headers to allow a more fine-grained choice of Rcpp feature for faster builds in #1191
  • Travers Ching extended the function signature generator to allow for a default R argument in #1184 and #1187
  • Dirk extended documentation, removed old example code, updated references and refreshed CI setup in several PRs (see below)

The full list of details follows.

Changes in Rcpp release version 1.0.8 (2022-01-11)
  • Changes in Rcpp API:

    • STRICT_R_HEADERS is now enabled by default, see extensive discussion in #1158 closing #898.

    • A new #define allows default setting of finalizer calls for external pointers (Iñaki in #1180 closing #1108).

    • Rcpp:::CxxFlags() now quotes the include path generated, (Kevin in #1189 closing #1188).

    • New header files Rcpp/Light, Rcpp/Lighter, Rcpp/Lightest and default Rcpp/Rcpp for fine-grained access to features (and compilation time) (Dirk #1191 addressing #1168).

  • Changes in Rcpp Attributes:

    • A new option signature allows customization of function signatures (Travers Ching in #1184 and #1187 fixing #1182)
  • Changes in Rcpp Documentation:

    • The Rcpp FAQ has a new entry on how not to grow a vector (Dirk in #1167).

    • Some long-spurious calls to RNGSope have been removed from examples (Dirk in #1173 closing #1172).

    • DOI reference in the bibtex files have been updated per JSS request (Dirk in #1186).

  • Changes in Rcpp Deployment:

    • Some continuous integration components have been updated (Dirk in #1174, #1181, and #1190).

Thanks to my CRANberries, you can also look at a diff to the previous release. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. Bugs reports are welcome at the GitHub issue tracker as well (where one can also search among open or closed issues); questions are also welcome under rcpp tag at StackOverflow which also allows searching among the (currently) 2822 previous questions.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Reproducible Builds (diffoscope): diffoscope 200 released

Planet Debian - Thu, 2022-01-13 19:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 200. This version includes the following changes:

* Even if a Sphinx .inv inventory file is labelled "The remainder of this file is compressed using zlib", it might not actually be. In this case, don't traceback, and simply return the original content. (Closes: reproducible-builds/diffoscope#299) * Update "X has been modified after NT_GNU_BUILD_ID has been applied" message to, for instance, not duplicating the full filename in the primary diffoscope's output.

You find out more by visiting the project homepage.

Categories: FLOSS Project Planets

Pages