Feeds

Drupal's success story is written by its community and its users. As the web landscape evolves, understanding the Drupal community's vision for ensuring Drupal remains innovative, adaptable, and inclusive is important. To get a pulse on where Drupal is headed, The Drop Times is launching a special project to gather insights directly from people in the Drupal community and Drupal users. Your perspectives will shape a series of articles focused on "Drupal's Innovation and Future: 2024 and Beyond." In our first article, we connected with diverse experts exploring challenges and opportunities. Now, it's your turn!

 

Python 3.13.0 alpha 4 is now available:

https://www.python.org/downloads/release/python-3130a4/

This is an early developer preview of Python 3.13

Major new features of the 3.13 series, compared to 3.12

Python 3.13 is still in development. This release, 3.13.0a4, is the fourth of six planned alpha releases.

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

During the alpha phase, features may be added up until the start of the beta phase (2024-05-07) and, if necessary, may be modified or deleted up until the release candidate phase (2024-07-30). 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.13 are still being planned and written. Work continues apace on both the work to remove the Global Interpeter Lock , and to improve Python performance. The most notable changes so far:

• In the interactive interpreter, exception tracebacks are now colorized by default .
• A preliminary, experimental JIT was added, providing the ground work for significant performance improvements.
  
• Docstrings now have their leading indentation stripped , reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.)
• PEP 594 (Removing dead batteries from the standard library) scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.
• Many other removals of deprecated classes, functions and methods in various standard library modules.
• New deprecations , most of which are scheduled for removal from Python 3.15 or 3.16.
• C API removals and deprecations. (Some removals present in alpha 1 have been reverted in alpha 2, as the removals were deemed too disruptive at this time.)

(Hey, fellow core developer, if a feature you find important is missing from this list, let Thomas know.)

The next pre-release of Python 3.13 will be 3.13.0a5, currently scheduled for 2023-03-12.

 More resources

• Online Documentation
• PEP 719 , 3.13 Release Schedule
• Report bugs at Issues · python/cpython · GitHub.
• Help fund Python directly (or via GitHub Sponsors), and support the Python community.

 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.

Regards from dusky Amsterdam,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower
Łukasz Langa

We talk with Jim Birch about the Recipes strategic initiative for Drupal. 

URLs mentioned

• Distributions and Recipes strategic initiative 
• Core patch to test recipes
• Config actions contrib module
• NEDCamp presentation on Recipes from Erik Volkernick
• Roadmap
• #distributions-and-recipes Slack channel 

DrupalEasy News

• Professional module development - 15 weeks, 90 hours, live, online course.  
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript 

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Credits

Podcast edited by Amelia Anello.

We are happy to announce the release of Qt Creator 13 Beta!

Choosing the right system-on-chip (SoC) is probably your first consideration when designing an embedded product, followed closely by deciding whether to use an off-the-shelf board or design your own.

The case for commercial boards in initial designs

For the first product in a new line, consider using a commercially available board that features your chosen SoC. This approach may slightly increase the cost per board compared to building a custom board yourself. However, it lets you build on a vendor’s considerable expertise in areas like SoC characteristics, architectural layout, proper bus design, and errata workarounds. Pre-existing boards offer a significant shortcut in getting your product to market as they can minimize prototype iterations and reduce the risk of crucial mistakes in layout. As you gain experience with your chosen silicon and start looking at moving to higher-volume production, you can then consider whether it makes sense to design and manufacture custom boards to reduce costs and introduce custom functionality.

First step: Picking a vendor

Selecting a CPU architecture is your very first step. While ARM is currently dominating the market, Intel x86 and RISC-V are other possible alternatives. Because toolchains like LLVM and GCC can support all these architectures, your decision will usually depend on factors such as vendor and community support, licensing, power consumption, and clock speeds. Once you’ve selected an architecture, comparing features and prices within that family becomes more straightforward.

Evaluating silicon vendor boards

Silicon vendors such as AMD, Intel, Nvidia, NXP, and Renesas all offer eval boards to help you evaluate their SoCs. These boards are excellent starting points but there are things to consider.

• Feature overload. Because eval boards are intended to show off the capabilities of their chips, they are often loaded with features. That can be good for trial, but you don’t want to pay for unnecessary hardware once you move to volume production.
• Limited availability. Eval boards are often intended for very limited distribution, making availability a serious concern. If you’re planning on a very small production run, this might not matter. But it also might force you to move to another platform before you’re ready.
• Hardware consistency. Eval boards may not have the same process consistency as commercial products. That means you could get multiple hardware revs of the same board within a short timeframe, creating potential software compatibility nightmares and in-field surprises.
• Support limitations. Support (either engineering assistance or device drivers) may not be at the level you need to build product. That includes some critical aspects such as OS updates. It’s possible the vendor has the capacity or process for consistently delivering commercial quality drivers for their boards that are compatible with the latest Linux releases, but you’ll likely need to ask.

It’s always advisable to consult with a sales representative before using an eval board in a production product. Their feedback can prevent future issues and, if necessary, direct you to distributors for better long-term alternatives.

Choosing a board provider

The other option for using pre-made boards is to go to a board vendor instead of a silicon vendor. They’re creating boards with the intent they’ll be incorporated into products rather than simply for evaluation. When selecting a board provider, consider all aspects, including one of the most important peripherals, the screen. For a more comprehensive guide on selecting hardware, refer to our paper on best practices: Designing Your First Embedded Linux Device: Choosing Your Hardware.

The post Optimizing Embedded Product Design appeared first on KDAB.

Suppose you want to reference a variable in a query in pandas package in Python. This seems to be a straightforward task but it becomes daunting sometimes. Let's discuss it with examples in the article below.

Let's create a sample dataframe having 3 columns and 4 rows. This dataframe is used for demonstration purpose.

import pandas as pd df = pd.DataFrame({"col1" : range(1,5), "col2" : ['A A','B B','A A','B B'], "col3" : ['A A','A A','B B','B B'] }) Filter a value A A in column col2

In order to do reference of a variable in query, you need to use @.

Mention Value Explicitly
newdf = df.query("col2 == 'A A'") Reference Method
myval1 = 'A A' newdf = df.query("col2 == @myval1") How to Pass Column Name in Query

Instead of filtering value we are referring the column which we want to use for filtering.

myvar1 = 'col2' newdf2 = df.query("{0} == 'A A'".format(myvar1)) {0} takes a value of variable myvar1.
"{0} == 'A A'".format(myvar1) returns "col2 == 'A A'" How to Pass Multiple Columns in Query

Incase you want to pass multiple columns as variables in query. Here we are using columns col2 and col3.

myvar1 = 'col2' myvar2 = 'col3' newdf2 = df.query("{0} == 'A A' & {1} == 'B B'".format(myvar1, myvar2))

"{0} == 'A A' & {1} == 'B B'".format(myvar1, myvar2) is equivalent to "col2 == 'A A' & col3 == 'B B'"

How to Handle Space in Column Name

Let's rename column col2 by including a space in between for illustration purpose.

df.rename(columns={'col2':'col 2'}, inplace = True)

By using backticks `` you can pass a column which contains space.

myvar1 = '`col 2`' newdf = df.query("{0} == 'A A'".format(myvar1)) This post appeared first on ListenData

PyCon US 2024 is quickly approaching and we can’t wait to see all of you there! This year, we are reaching out to our community to help support one of our favorite events: the PyLadies Charity Auction. We know our wonderful community is bursting with creative, artsy, and generous folks. That’s why we are sending out a community wide call to donate items to this year’s auction. If you’d like to support PyLadies by making a donation, please fill out the PyLadies Charity Auction donation form. To learn more about the event and what to donate, read on!

What to Donate

Need inspiration? Over the years, we’ve seen that people love to bid on items that are artsy, nerdy, and Python-specific. Art, decor, customized tech, and vintage PyCon or Python related swag are all examples of things that will inspire a friendly bidding war. To get more inspiration search ‘PyLadies Auction’ on social media or check out the PyLadies Instagram.

Items that are personalized or have a story tend to attract bidders– DIYers, artists, crafters, and collectors, this is your time to shine! It's also worth thinking about what will show up well on stage. We have a magnifying camera, but smaller and less colorful items like jewelry and watches might be harder for bidders to see than a big piece of art or an adorable, bright colored snake stuffy! On that note, this year we will be holding a raffle at the PyLadies Auction. If you have smaller items– like vintage swag, stickers, or even pens (iykyk)– they can go into the raffle.

Please note that we cannot accept donations of guns, alcohol, cars, real estate, or houses. We may decline other gifts that are inappropriate or impractical at the PSF’s discretion (for example, sorry, no real pythons!).

If you’ve got an item to contribute that you’d like to share in a sneak preview, feel free to post a photo and tag us on the social media platform of your choice!

Donation details

To donate an item, please fill out the PyLadies Charity Auction donation form. This form asks for required information around the person or organization donating, item specifics, and logistics. You will need to indicate if you will ship the item in advance or deliver it in person. You will receive shipping information once you complete the form. The deadline for donations is May 16th, 2024 (that’s the Thursday before the event!).
 

About the PyLadies Charity Auction

The twelfth PyLadies Charity Auction will be held in-person during PyCon US 2024 in Pittsburgh, Pennsylvania. It’s an evening of fun and refreshments while supporting the PyLadies community!

The Entry cover charge of $35.00 includes dinner and a drink ticket, while the Supporter cover charge of $50.00 includes dinner, a drink ticket, and a $15.00 contribution to PyLadies. Everyone who attends will also have access to the cash bar. To save your place at the Auction, add the PyLadies Auction to your PyCon US registration via your dashboard. Last year we sold out quickly, so if you’d like to go, reserve your ticket soon!

PHP Attributes for Drupal Plugins

As of PHP 8.1, the PHP language has native support for attributes that are compatible with Drupal’s plugin system use case. As a result, Drupal will transition from the use of annotations to PHP attributes, to supply metadata and configuration for plugins. This will require developers to learn the new PHP attributes syntax, and update their existing code to use it. For now Drupal will continue to support both annotations and attributes. But the proverbial clock is ticking.

So let’s take a look at how we got here, and what you’ll need to do to update your code for future versions of Drupal.

joe Wed, 02/14/2024 - 19:06

NOTE: The audio is a bit low. I did my best to boost the volume. Sorry for not dialing this in better during recording

Two weeks ago I asked the question again about What Rye should be. There has been one thing that I have not publicly shared before and that is that ever since Rye exists I have also been talking to Charlie Marsh about Python packaging and Python tooling. It turns out that we had some shared ideas of what an ideal Python tooling landscape would look like. That has lead to some very interesting back and forths. To make a potentially very long story short: Together with Astral's release of uv they will take stewardship of Rye. For the details read on.

For me Rye is an exciting test bed of what Python tooling can be. I have been using this test bed to run a of experiments over the last year. I learned a lot about what is missing in the ecosystem by building it and where the challenges are. What I enjoyed the most of working on it so far has been the feedback from various people on it. I wanted to explore what a “cargo for Python” is like and it's becoming ever more evident what that might look like. At the same time from the very start I was very clear in questioning its existence.

Since we were talking I was able to run an experiment which has been to put in Astral's uv as replacement for pip-tools. If you are not familiar with it yet: uv today is a drop-in replacement for pip-tools and venv. The why is pretty clear: it's much faster than pip-tools. Instead of taking 5 seconds to sync a virtualenv, it's almost instant. It's hard to overstate how impactful this is in terms of developer experience.

For entirely unrelated reasons Rye today already picks some of Astral's tools to power other functionality. If you invoke rye fmt and rye check it behind the scenes uses Astral's ruff to do so. They are fast, sufficiently oppinonated and they do not require installing them into the virtualenv of the project. They are quickly becoming the obvious choice if you are used to excellent tooling from other ecosystems. So as it stands, three things that Rye does are either already picking Astral tools, or will soon default to doing so.

This led to a few conversations if it would make sense for Astral to continue the work on Rye and build it out into that “cargo for Python”. I'm very much convinced that there should be such a tool and that is something Charlie from Astral shares. Where we landed is a plan that looks like the following:

Rye will continue to be a test bed for what Python tooling can be. We will move the project under Astral's stewardship with the desire to use it to further explore what a good UX can be and we will be quite liberal in trying different things. For instance now that the package installation process is blazing fast, I really want to see if we can remove the need of calling sync manually. There are also a lot of questions remaining like how to make the most of the indygreg builds or what lock files should look like in a Python world. I also want to go deep on exploring a multi-version Python import system.

Rye will turn into a blessed breeding ground of different things. As the user experience becomes more obvious uv itself will turn from what it is today — low level plumbing — into that higher level tool with a clear migration path of folks using rye to that new uv.

To try Rye on top of uv today install or update to the latest version and enable the experimental uv support:

$ rye config --set-bool behavior.use-uv=true

To learn more about uv and rye head over to GitHub:

• astral-sh/uv
• mitsuhiko/rye

You might have some more questions about this so I compiled a basic FAQ:

Why not make Rye the cargo for Python?

This in many ways might look like the obvious question. The answer is quite simple: Rye as it exists today is unlikely to be the final solution. For a start code wise it's pretty brittle coming from it cobbling together various tools. It's a duck-taped solution that was built to sketch up what can be, for my very own uses. It is however incredibly useful to play and explore possible solutions.

Will Rye retired for uv?

Not today, but the desire is that these tools eventually converge into one.

Will you continue to contribute and maintain Rye?

Short answer: yes. Long answer is that me contributing to my own tool has been a pretty spotty thing over the last year. There was in fact almost a multi month hiatus where the only changes to Rye were bumping Python versions and fixing minor issues and that not because it was perfect. The reason more was that I realized that Rye runs into fundamental issues that are really gnarly to resolve which can be quite frustrating to attack as a side project. So I want to continue to be involved in one way or another, but this is a project much larger than me and I do not have the motivation to give it enough of that push myself.

Will I join Astral?

No :-)

Is there a song about Python packaging?

Thanks to AI there is.

Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• knavalbattle: Fix test for placing a ship vertically (Commit)
• konsole: Show wallpaper on non-translucent top-levels (Commit, fixes bug #477800)
• neochat: Fix saving images (Commit, fixes bug #479053)

Distro and app store packagers should update their application packages.

• 23.08 release notes for information on tarballs and known issues.
• Package download wiki page
• 23.08.5 source info page
• 23.08.5 full changelog

After a lot of work, we moved our website to a new Hugo based platform! A lot of time and energy went into making this new version. There were a number of reasons and issues that we moved the site.

1. Translations - The previous website had a very messy translation process. There was so much manual work creating logins for translators, and uploading files to the web server every time new languages were added. With the new system, translation is built through our KDE translation pipeline. This is the same pipeline that is used for translating the application. This greatly simplifies the experience for both our web master and translation team.
2. Site maintenance - While many updates could previously be done via the CMS, there were a lot of portions that needed special access to the web server files. This made doing updates like releases a coordination between a lot of people to make sure all the pieces in place.
3. Simplify site building and publishing - The new site is only using static files in the end. In the previous CMS, pages were dynamically generated from a database. There were many complicated layers of caching that were needed to make the site responsive and load fast. This created a number of instances where the entire krita.org went down because of some caching snafu.

All the files for the website and information on how our site process works can be found on GitLab instance.

Special Thanks

Special thanks goes out to all the work that was involved in making this transition

• Scott Petrovic: Leading the charge with performing the bulk of the work and taking the project to completion.
• Phu Nguyen: A large amount of help with understanding the inner workings of the Hugo platform as well as many code contributions.
• Wolthera van Hövell: Site fixes and cleanup when porting the content to the new system.
• Alvin Wong: Improvements to the translation and internationalization aspects of the site.
• Ben Cooksley: Helping configure and get the site on a CI/CD process that makes publishing changes seamless.
• All the people that provided feedback on krita-artists.org

Good evening! Tonight I have a brief and unusual post, which is a product review of an electric cargo bike and its accessories for transporting kids. Let’s see if I can get this finished while I wait for my new laptop to finish installing.

So, I have three young kids (5yo, 3yo, 1yo), and I need to get them places. Before the 3rd was born I would use a bike trailer (Thule Chariot Lite single, bought when there was just one kid) and a bike seat (Thule RideAlong Lite, attached on seat-post). That was fine, though sometimes the thought of lugging their ever-increasing kilograms somewhere would give me pause. Then when the third kid arrived, hoo boy; I got a front-mount Thule Yepp Nexxt 2 Mini, to see if I could do three kids on one me-powered bike, but that was too tight to manage; not enough space to kick my leg over when getting on.

In the end we finally broke down and looked at electric cargo bikes. Of course I had looked at these over the years and always bounced off the price. Initially I had thought a front box-bike would be the thing, but then as kids grew up I realized they wouldn’t be comfortable there, and that a long-tail was probably better for the long term. But holy Christ, they are expensive. Happily, Decathlon came out with an electric longtail which is quite acceptable, and for about half the price of something equivalent from elsewhere.

Funny story: a friend got her bike stolen in the center of Geneva one day; thieves came and took all the bikes on a rack. I guess it was a battery-operated angle grinder; apparently that is the modus operandi these days. She moped a bit but then decided to buy the same bike again, from Decathlon as it happens. While she was at the store she entered a raffle. Then the cops called to say they found her bike – I know right?! Turns out some other bike that was stolen had an Apple AirTag on it, and its owner called the cops to tell them where the bike was, and all of the bikes were recovered. In the meantime my friend’s insurance had paid out for her stolen bike, so she had an extra bike. Then the local Decathlon called to tell her she won the raffle, for some kind of electric bike. When she went to pick it up, it was the electric longtail, for free. Anyway, we got to try hers before deciding to get one too.

One of my questions was, can you jam 3 kids on this thing? In terms of weight, yes: it will take 80 kilos on the back, and our kids total 45 kilos. In terms of space it’s OK, but really for the 1yo you need a bike seat, and even for the 3yo she should really be in a seat unless she’s very awake. The back rack has a frame around it, which does help keep kids on, but it’s not sufficient for a sleepy 3yo.

I was hoping to find a quite narrow kid bike seat so I could put on two seats for the young ones and then jam the oldest in somehow. I started with the Thule Yepp Nexxt 2 Maxi, but the release clamp kinda wants to be where the frame around the back rack is, so it’s not so efficient, and not easy to remove. Also the plastic guards so that kids don’t catch their legs in the back wheel aren’t needed on this particular bike, but they do prevent me from effectively accessing the otherwise well-designed panniers (c’est drôle mais ce ne sont pas des panniers, mais des saccoches).

So, with the Thule rear-mount seat I could get one bike seat for the 1yo and then jam in the 3yo and 5yo. It worked fine.

Then, annoyingly, thieves stole our electric longtail. Apparently insurance will pay out for us too—this is a relatively standard feature in France for the kind of insurance you have to have already for your place of residence—but for the last few weeks we have been without our longtail, and it is terrible. In the end we decided just to buy the same bike again: proof that it is good enough.

There are other electric longtails out there. If you can afford it, a pedal motor will be better than the hub motor on the Decathlon model. But if you are willing to accept less than the best, I think the Decathlon bike is quite good for what it is and I am looking forward to picking up the new bike tomorrow. It fits the kids, easily adjusts between different rider heights, and is a real joy to be on as a family. It lets me go places I wouldn’t think of going without the ability to just chuck everybody on the bike and zip away.

As far as bike seats go, I am going to try a new seat, to see if I can avoid the leg covers and to see if it’s more narrow. Ping me on the Mastodon if you want a follow-up. Thoughts welcome below for things that have worked for you. Until next time, happy cycling!

Just a quick one today to document the solution to a problem I ran into earlier today.

I was using Microsoft Planetary Computer to access some Landsat satellite data, and I wanted to run it through the Segment Anything model from Meta, to segment out agricultural fields from the image. I tried to do this using the segment-geospatial Python package.

Unfortunately I got an error that libgl1.so could not be found. Luckily this is documented on the segment-geospatial installation page and you just need to run:

apt update; apt install -y libgl1

But, there’s a problem: Microsoft Planetary Computer does not allow apt access from their container images. I tried every way I could think of to install this, and did a lot of googling, but couldn’t find anything.

Eventually I found the answer in this issue which somehow didn’t appear in my earlier Google searches. It seems that the libgl1 library is a dependency of OpenCV, which segment-geospatial uses interally, and you can get around this dependency by installing the opencv-python-headless package. And it was just that simple – running

pip install opencv-python-headless

completely solved the problem and let me get going running segment-geospatial.

I hope this post helps someone else with the same problem as me – and hopefully turns up better in relevant Google searches.

Selenium 4 has been around now for quite a bit of time. It came out with many new features, some you can directly use while some will benefit you in the background. Despite it is not new anymore but still, not a lot of stuff you can find to learn about it practically. That’s where […]

The post Selenium 4 With Python Guide appeared first on TechBeamers.

New Composer plugin "Remote Bin Scripts" makes it easy to install 3rd party tools. admin Wed, 02/14/2024 - 13:27

Recently we finished a project that was being moved to Pantheon.

We created a couple custom scripts for pushing data into the pantheon environment, and for pulling data down for continuous integration runs.

The scripts require the Terminus CLI tool created by Pantheon to interact with it's service.

Terminus is a composer project, but it's dependencies don't align with the latest Drupal sites. It's best to install it as a phar file and run it that way.

Authored by: Nadiia Nykolaichuk.

Qt for MCUs 2.6.1 has been released and is available for download. As a patch release, Qt for MCUs 2.6.1 provides bug fixes and other improvements, and maintains source compatibility with Qt for MCUs 2.6.x. It does not add any new functionality.

Hosted by Mariano Crivello, join us as Adam Silverstein, from Google and Janez Urevc of Tag1 discuss Google's new metric, Interaction to Next Paint(INP), which is part of the Core Web Vitals being introduced in March 2024 to foster user experience on the web. Adam gives a comprehensive overview. INP focuses on measuring the responsiveness of web pages to user inputs, aiming to capture the quality of interactions beyond just load times. A good INP score is defined as 200 milliseconds or less, with a particular emphasis on mobile performance due to the variability in device capabilities and network conditions. Adam highlighted the shift from First Input Delay (FID) to INP, noting that INP offers a more comprehensive measure of interactivity throughout the entire lifecycle of a page. He also presents data showing the current performance of Drupal sites in relation to Core Web Vitals, emphasizing the importance of focusing on mobile optimization and the impact of INP on future web performance metrics. Don’t miss expert insights for navigating this significant web development shift. --- For a transcript of this video, see :[Shifting from FID to INP: Google's New Metric for Improving...

Read more Mariano Wed, 02/14/2024 - 07:00

While reading the Python documentation, you may have found fragments of BNF notation (Backus–Naur form) that look something like the following:

BNF Grammar name ::= lc_letter (lc_letter | "_")* lc_letter ::= "a"..."z" Copied!

What’s the meaning of all this strange code? How can this help you in understanding Python concepts? How can you read and interpret this notation?

In this tutorial, you’ll get to know the basics of Python’s BNF notation and learn how to take advantage of it to get a deep understanding of the language’s syntax and grammar.

In this tutorial, you’ll:

• Learn what BNF notation is and what it’s used for
• Explore the characteristics of Python’s BNF variation
• Learn how to read the BNF notation in the Python documentation
• Explore some best practices for reading Python’s BNF notation

To get the most out of this tutorial, you should be familiar with Python syntax, including keywords, operators, and some common constructs like expressions, conditional statements, and loops.

Get Your Code: Click here to download the free sample code that shows you how to read Python’s BNF notation.

Getting to Know Backus-Naur Form Notation (BNF)

The Backus–Naur form or Backus normal form (BNF) is a metasyntax notation for context-free grammars. Computer scientists often use this notation to describe the syntax of programming languages because it allows them to write a detailed description of a language’s grammar.

The BNF notation consists of three core pieces:

Component Description Examples Terminals Strings that must exactly match specific items in the input. "def", "return", ":" Nonterminals Symbols that will be replaced by a concrete value. They may also be called simply syntactic variables. <letter>, <digit> Rules Conventions of terminals and nonterminals that define how these elements relate. <letter> ::= "a"

By combining terminals and nonterminals, you can create BNF rules, which can get as detailed as you need. Nonterminals must have their own defining rules. In a piece of grammar, you’ll have a root rule and potentially many secondary rules that define the required nonterminals. This way, you may end up with a hierarchy of rules.

BNF rules are the core components of a BNF grammar. So, a grammar is a set of BNF rules that are also called production rules.

In practice, you can build a set of BNF rules to specify the grammar of a language. Here, language refers to a set of strings that are valid according to the rules defined in the corresponding grammar. BNF is mainly used for programming languages.

For example, the Python syntax has a grammar that’s defined as a set of BNF rules, and these rules are used to validate the syntax of any piece of Python code. If the code doesn’t fulfill the rules, then you’ll get a SyntaxError.

You’ll find many variations of the original BNF notation out there. Some of the most relevant include the extended Backus–Naur form (EBNF) and augmented Backus–Naur form (ABNF).

In the following sections, you’ll learn the basics of creating BNF rules. Note that you’ll use a variation of BNF that matches the requirements of the BNF Playground site, which you’ll use for testing your rules.

BNF Rules and Their Components

As you already learned, by combining terminals and nonterminals, you can create BNF rules. These rules typically follow the syntax below:

BNF Grammar <symbol> ::= expression Copied!

In the BNF rule syntax, you have the following parts:

• <symbol> is a nonterminal variable, which is often enclosed in angle brackets (<>).
• ::= means that the nonterminal on the left will be replaced with the expression on the right.
• expression consists of a series of terminals, nonterminals, and other symbols that define a specific piece of grammar.

When building BNF rules, you can use a variety of symbols with specific meanings. For example, if you’re going to use the BNF Playground site to compile and test your rules, then you’ll find yourself using some of the following symbols:

Symbol Meaning "" Encloses a terminal symbol <> Indicates a nonterminal symbol () Indicates a group of valid options + Specifies one or more of the previous element * Specifies zero or more of the previous element ? Specifies zero or one occurrence of the previous element | Indicates that you can select one of the options [x-z] Indicates letter or digit intervals Read the full article at https://realpython.com/python-bnf-notation/ »

[ 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 ]