Greetings! Time for another combined release of six separate versions of Python!
Please test the 3.12 beta! Downloading it and trying it out helps us a
lot in ensuring Python 3.12.0 will be as polished as possible.
We welcome 3.10 to the prestigious club of security-only releases.
It’s officially an old version of Python now! If you haven’t rewritten
all your if:elif:else:s with pattern matching yet, are you even still writing Python?
At the same time, it looks like 3.7 is reaching end-of-life. Unless
another security release happens in June, 3.7.17 will be the final
release of Python 3.7. I mean, now that I typed it out for all you to
read, I’m sure I jinxed it. But in case I didn’t, I would like to thank
Ned Deily for serving as the release manager of Python 3.6 and Python
3.7. He was my mentor as Release Manager, and continues serving Python
as the provider of Mac installers for new releases. Thank you, Ned!
Speaking of installers, Steve Dower used to be the sole provider of
Windows installers for Python releases for years now. His secret was a
well-automated Azure pipeline that let him build, sign, and publish
releases with minimal manual effort. Now he extended the power to press
the blue “Run pipeline” button to more members of the team. Thank you,
Steve! This is an important bus factor increment. In fact, the Windows
installers for both 3.12.0b2 and 3.11.4 were made by me initiated by me. If there’s anything wrong with them, well, I guess that means I pressed the button wrong.
Updating is recommended due to security content:
urllib.parse.urlsplit()uu.decode() that could allow for directory traversal based on the input if no out_file was specified.http.client.SimpleHTTPRequestHandler.subprocess.Popen now uses a safer approach to find cmd.exe when launching with shell=True.trace.__main__ now uses io.open_code() for files to be executed instead of raw open().tarfile, and shutil.unpack_archive(), have a new filter argument that allows limiting tar features than may be surprising or dangerous, such as creating files outside the destination directory. See Extraction filters for details.threading.local.Get it here: 3.12.0b2
116 new commits since 3.12.0 beta 1.
Get it here: 3.11.4
233 new commits.
Get it here: 3.10.12
Security-only release with no binaries. 20 new commits.
Get it here: 3.9.17
Security-only release with no binaries. 26 commits.
Get it here: 3.8.17
Security-only release with no binaries. 24 commits.
Get it here as it might be the last release of 3.7 ever:
3.7.17
Security-only release with no binaries. 21 commits.
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.
–
Łukasz Langa @ambv
on behalf of your friendly release team,
Ned Deily @nad
Steve Dower @steve.dower
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv
Thomas Wouters @thomas
A detailed explanation on the Linux kern Click to Read More at Oracle Linux Kernel Development
The post The Machine Keyring appeared first on Linux.com.
Sharing knowledge and sharing code has always been a key driver for innovation in Artificial Intelligence. Researchers have gathered together since AI was established as a field to develop and advance novel techniques, from Natural Language Processing to Artificial Neural Networks, from Machine Learning to Deep Learning.
The post <span class=’p-name’>The AI renaissance and why Open Source matters</span> appeared first on Voices of Open Source.
For more insights click here:-
https://www.appsdevpro.com/blog/benefits-of-android-app-for-your-business/
https://www.appsdevpro.com/blog/cost-to-hire-android-app-developer/
https://www.appsdevpro.com/blog/ios-app-vs-android-app/
https://www.appsdevpro.com/blog/why-and-how-to-build-an-android-app/
Follow Us on Social Media:-
Facebook : https://www.facebook.com/appsdevpro
Twitter : https://twitter.com/appsdevpro
LinkedIn : https://www.linkedin.com/company/appsdevpro-usa/
Instagram : https://www.instagram.com/appsdevpro
Author: Source Read more
It’s time to transform and improve the Layout Builder UI experience. What if we could rewrite it using React? Check out our video pitch (made using React), which received the highest average rank in the Pitch-burgh contest at DrupalCon!
At PreviousNext, we enjoy getting curious, tackling challenges and finding innovative solutions for our clients and the wider Drupal community. This constant drive for the future is why we’re such prolific contributors to the Drupal project.
What if we used our curiosity and expertise to explore the concept of a decoupled Layout Builder?
Simply put, we believe creating a better experience for the Layout Builder user interface is possible. Getting there would mean leveraging a modern Javascript framework, like React, that communicates with Drupal over JSON.
We would plan to design an API that describes the future state of how a Decoupled Layout Builder could work, dramatically enhancing the content editor experience and bringing Drupal into the modern era of web UX. It would also strengthen Drupal’s reputation with marketers.
What if Layout Builder could move forward? It’s currently built with Drupal technologies that haven’t significantly progressed in ten years.
Page edits use Drupal’s AJAX API, which requires a round trip back to the server to perform UI updates. The server updates state on the server side and then returns a series of Javascript commands to update the page state.
This round trip is inconsistent with the instant experience users expect from the modern web.
Applications that leverage modern Javascript frameworks perform optimistic updates. They update the UI immediately and then update state on the server in the background.
We want layout retrieval and updates to happen in real time for more dynamic editing. To achieve this, we would rebuild the Layout Builder UI using React and identify the pain points.
This would be a significant jump, similar to the change to the block-based editor in WordPress.
Rather than starting from scratch, we could leverage a lot of prior art from the WordPress community. However, we would also bring our strengths into play, retaining our uniquely Drupal focus on structured data instead of serialising to HTML.
React is the best and most obvious option for the proof of concept. It was selected as the framework of choice for Drupal core development and has a large ecosystem. It was also successful in helping set WordPress up for the future.
What if it’s Drupal’s turn next?
To retain structured data, it would be necessary to provide React versions of our existing formatters and widgets and a way for developers to create their own.
This approach would require a Javascript way of declaring layouts. Again, we could take a lot of this from existing layout plugins but would require a React component for the HTML representation.
We would also need to incorporate a Javascript way of declaring blocks. Much could be derived from our existing structured content modelling. However, assuming there would be a build step where this data is used for scaffolding Javascript code is reasonable.
JSON:API could be leveraged where possible, but we envisage needing to make new JSON endpoints for data that doesn’t map to entities.
Once we had achieved a non-twig way of rendering widgets, formatters, blocks and layouts, we could keep the layout state in the browser, mutate it immediately and persist to the backend in the background.
There are a number of hard problems we’ll need to solve here, such as how we allow modules to ship Javascript that relies on bundling, how we ensure there’s only one version of React loaded into the page, and how we allow modules to rely on other packages from npm. Solving those will be a big part of this work, and even if a React-powered Layout Builder doesn’t make its way from experimental to stable, the lessons learned in the process could solve some long-standing hard problems for Drupal in the front end space.
We decided it would be a fitting way to demonstrate how powerful React is by using it to make our Pitch-burgh video submission.
We received the highest average rank when the video was shown during the Driesnote address at DrupalCon Pittsburgh, and look forward to the next steps for this exciting concept.
Huge shout out to the team who worked on creating the pitch video especially the wizard of words Fiona, frontend Guru Jack and the excellent QA and GIF selection from Kim and Tina.
Enjoy!