Planet Python
Python Insider: Python 3.13.0 release candidate 3 released
I'm pleased to announce the release of Python 3.13 release candidate 3 (instead of the expected final release).
https://www.python.org/downloads/release/python-3130rc3/
This is the final release candidate of Python 3.13.0
This release, 3.13.0rc3, is the final release preview (no really) of 3.13. This release is expected to become the final 3.13.0 release, barring any critical bugs being discovered. The official release of 3.13.0 is now scheduled for Monday, 2024-10-07.
This extra, unplanned release candidate exists because of a couple of last minute issues, primarily a significant performance regression in specific workloads due to the incremental cyclic garbage collector (introduced in the alpha releases). We decided to roll back the garbage collector change in 3.13 (and continuing work in 3.14 to improve it), apply a number of other important bug fixes, and roll out a new release candidate.
There will be no ABI changes from this point forward in the 3.13 series (and there haven't been any since the beta releases).
Call to actionWe strongly encourage maintainers of Python projects to prepare their projects for 3.13 compatibilities during this phase, and where necessary publish Python 3.13 wheels on PyPI to be ready for the final release of 3.13.0. Any binary wheels built against Python 3.13.0rc1 and later will work with future versions of Python 3.13. As always, report any issues to the Python bug tracker.
Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is not recommended for production environments.
Core developers: time to work on documentation now- Are all your changes properly documented?
- Are they mentioned in What’s New?
- Did you notice other changes you know of to have insufficient documentation?
Some of the new major new features and changes in Python 3.13 are:
New features- A new and improved interactive interpreter, based on PyPy’s, featuring multi-line editing and color support, as well as colorized exception tracebacks.
- An experimental free-threaded build mode, which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well.
- A preliminary, experimental JIT, providing the ground work for significant performance improvements.
- The locals() builtin function (and its C equivalent) now has well-defined semantics when mutating the returned mapping, which allows debuggers to operate more consistently.
- A modified version of mimalloc is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode.
- Docstrings now have their leading indentation stripped, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.)
- The dbm module has a new dbm.sqlite3 backend that is used by default when creating new files.
- The minimum supported macOS version was changed from 10.9 to 10.13 (High Sierra). Older macOS versions will not be supported going forward.
- WASI is now a Tier 2 supported platform. Emscripten is no longer an officially supported platform (but Pyodide continues to support Emscripten).
- iOS is now a Tier 3 supported platform
- Android is now a Tier 3 supported platform as well.
- Support for type defaults in type parameters.
- A new type narrowing annotation, typing.TypeIs.
- A new annotation for read-only items in TypeDicts.
- A new annotation for marking deprecations in the type system.
- 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.
- C API removals and deprecations. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.)
- New deprecations, most of which are scheduled for removal from Python 3.15 or 3.16.
(Hey, fellow core developer, if a feature you find important is missing from this list, let Thomas know.)
For more details on the changes to Python 3.13, see What’s new in Python 3.13. The next release of Python 3.13 will be the official 3.13.0 release, currently scheduled for Monday, 2024-10-07.
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.
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.
Your release team,
Thomas Wouters
Łukasz Langa
Ned Deily
Steve Dower
Real Python: Quiz: When to Use a List Comprehension in Python
In this quiz, you’ll test your understanding of List Comprehension in Python.
By working through this quiz, you’ll revisit how to rewrite loops as list comprehensions, how to choose when to use list comprehensions, how you can use conditional logic in your comprehensions, and how to profile your code to resolve performance questions.
[ 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 ]
Tryton News: Newsletter September 2024
During the last month we mainly focus on bug fixes, behaviour improvements of several things and speeding-up performance issues stepping forward to our next release 7.4 scheduled to the 4th of November. We also added some new features which we would like to introduce to you in this newsletter.
For an in depth overview of the Tryton issues please take a look at our issue tracker or see the issues and merge requests filtered by label.
Changes for the User Sales, Purchases and ProjectsWe add a new sale reporting per promotion.
We add now a relate from promotions to their sales.
We improved the exception handling wizards on sales and purchases. We added two fields to let the user explicitly fill with the records to ignore or to re-create.
Any cancelled record that is not added to one of the fields, will stay in exception state to be proceeded later. Also we changed the view between a MultiSelection to a Many2Many field depending on the number of records in the exception state.
Now, Tryton doesn’t add extra lines on sale orders for inactive products. Also Tryton does no longer recommend inactive products.
We removed the Menu: Parties → Parties → Parties Associated to Sales/Purchases entries, because the result is not limited to sales or purchases in state validated or processing. A draft, quotation or cancelled order doesn’t qualify a party as a customer or supplier. The functionality is already replaced by the reports in Menu: Sales → Reporting → Sales, Sales per Customer and Menu: Purchases → Reporting → Purchases, Purchases per Supplier which adds the ability to filter per state and per period.
Accounting, Invoicing and PaymentsNow we re-launch the update of the payment customer for Stripe and Braintree in case it failed. Also the users can manually initiate the update process.
Stock, Production and ShipmentsNow we round up weights and the other measurements to two decimals for the shipping carriers DPD, Sendcloud and UPS.
We make package measurements read-only once they are closed.
User InterfaceWe remove the favourite management from the favourite menu, because of
several issues [1] [2] and duplicated functionality.
Now we group links with a similar functional scope together.
In Menu: Administration → User Interface the entries
- View Tree Widths,
- View Tree Optionals,
- View Tree States and
- View Searches
are moved to the Open related records toolbar-menu of Menu: Administration → Models → Models.
We improve the widget for MultiSelection fields in the Tryton clients by adding checkboxes which display the selection state of the row. If the users clicks on a row, the selection state will be changed.
Now we visually remove records from Many2Many fields used in Wizard instead of greying them out.
We keep the CSV export dialogue now opened after exporting, to have a better user experience when fixing bugs, export and again fixing bugs.
Since we moved the functionality from product_price_list_dates to product_price_list, you can open price list lines in a new tab to be able to filtering, search or import import them.
New Documentation or NamingWe improved and unified the stock action naming and re-worked documentation:
- Rename “Product Quantities By Warehouse” into “Stock Quantities By Warehouse.”
- Remove “Lots By Warehouse” relate as the same view can be opened from the stock location relate.
- Rename prefix “Locations Quantity” to “Stock Locations”.
- Document viewing stock levels of lots.
- Rename “Products by Locations” into “Products”, as the locations are added to the tab name, there is no need to specify.
We released bug fixes for the currently maintained long term support series
7.0 and 6.0, and for the penultimate series 7.2.
Please update your systems to take care of a security related bug we found last month: trytond allows to execute reports for records for which the user has no read access and also for reports limited to a set of groups that the user is not member of.
Changes for the System AdministratorNow we use a random value for cron next call field when no value is defined.
Now we log the last cron scheduler runs and their durations. A new cron task periodically cleans the log entries. The new cron-section configuration variable clean_days (default 30) sets this period.
Changes for Implementers and DevelopersThe Tryton view-tests now check for some more attributes like sequence and on_write in tree-views or dtstart and dtend in calendar-views.
Now we unify the term “email”, as it is now the most common and recommended form.
We add to all “cost”-terms a “sale”-suffix in sale shipment cost fields to improve the naming convention and to avoid collisions or misinterpretations.
1 post - 1 participant
William Minchin: u202409302311
Summary plugin for Pelican v1.3.0 released! Now keeps internal link indicators (like {filename}) from leaking into summaries. on PyPI #Summary (Pelican) #Pelican Plugins #Releases #Python
William Minchin: u202409301853
CommonMark Pelican reader v2.0.1! Should stop complaining about intra-document links (e.g. #target) on PyPI #CommonMark Reader #Pelican Plugins #Releases #Python
Python Morsels: Converting a string to a datetime
The datetime.strptime class method can parse a date/time string into a datetime object.
Table of contents
- Parsing strings into datetime objects ➡️
- The strptime formatting directives 📑
- Just parse my string please! ⚡
- What time is it? It's "string parse time" ⏱️
- Converting a datetime into a string ⬅️
- strptime parses and strftime formats 🔄
- f-strings for datetime formatting ✨
- strptime for date and time objects? 🤔
- Parse with str-p-time, format with str-f-time 📝
Here's an example of the strptime class method in action:
>>> from datetime import datetime >>> datetime.strptime("Jun 1 2005 1:33PM", "%b %d %Y %I:%M%p") datetime.datetime(2005, 6, 1, 13, 33)Note that strptime is a class method: we're calling it on the datetime class (not an instance of the class).
The strptime formatting directives 📑Those single letter % codes …
Read the full article: https://www.pythonmorsels.com/converting-a-string-to-a-datetime/Kushal Das: Breaking out of algorithm
Many of you already know about my love of photography. I am taking photos for many years, mostly people photos. Portraits in conferences like PyCon or Fedora events. I regularly post photos to wikipedia too, specially for the people/accounts which does not have good quality profile photos. I stopped doing photography as we moved to Sweden, digital camera was old and becoming stable in a new country (details in a different future blog) takes time. But, last year Anwesha bought me a new camera, actually two different cameras. And I started taking photos again.
I started regular photos of the weekly climate protests / demonstrations of Fridays for Future Stockholm group. And then more different street protests and some dance/music events too. I don't have a Facebook account and most people asked me to share over Instagram, so I did that. But, as I covered more & more various protests as a photographer, I noticed my Instagram postos are showing up less in people's feeds. Very less. Was wondering different ways of breaking out of the algorithmic restriction.
Pixelfed is a decentralized, federated ActivityPub based system to share photos. I am going to share photos more on this platform, and hoping people will slowly see more. I started my account yesterday.
You can follow me from any standard ActivityPub system, say your mastodon account itself. Search for @kushal@pixel.kushaldas.photography or https://pixel.kushaldas.photography/kushal in your system and you can then follow it like any other account. If you like the photos, then please share the account (or this blog post) more to your followers and help me to break out of the algorithmic restrictions.
In the technology side, the server runs Debian and containers. On my Fedora system I am super happy to add a few scripts for Gnome Files, they help me to resize the selected images before upload (I will write a blog post tomorrow on this).
Real Python: Python 3.13: Cool New Features for You to Try
Python 3.13 will be published on October 1, 2024. This new version is a major step forward for the language, although several of the biggest changes are happening under the hood and won’t be immediately visible to you.
In a sense, Python 3.13 is laying the groundwork for some future improvements, especially to the language’s performance. As you read on, you’ll learn more about the background for this and dive into some new features that are fully available now.
In this tutorial, you’ll learn about some of the improvements in the new version, including:
- Improvements made to the interactive interpreter (REPL)
- Clearer error messages that can help you fix common mistakes
- Advancements done in removing the global interpreter lock (GIL) and making Python free-threaded
- The implementation of an experimental Just-In-Time (JIT) compiler
- A host of minor upgrades to Python’s static type system
If you want to try any of the examples in this tutorial, then you’ll need to use Python 3.13. The tutorials Python 3 Installation & Setup Guide and How Can You Install a Pre-Release Version of Python? walk you through several options for adding a new version of Python to your system.
In addition to learning more about the new features coming to the language, you’ll also get some advice about what to consider before upgrading to the new version. Click the link below to download code examples demonstrating the new capabilities of Python 3.13:
Get Your Code: Click here to download the free sample code that shows you how to use the new features in Python 3.13.
Take the Quiz: Test your knowledge with our interactive “Python 3.13: Cool New Features for You to Try” quiz. You’ll receive a score upon completion to help you track your learning progress:
Interactive Quiz
Python 3.13: Cool New Features for You to TryIn this quiz, you'll test your understanding of the new features introduced in Python 3.13. By working through this quiz, you'll review the key updates and improvements in this version of Python.
An Improved Interactive Interpreter (REPL)If you run Python without specifying any script or code, you’ll find yourself inside Python’s interactive interpreter. This interpreter is informally called the REPL because it’s based on a read-evaluate-print loop. The REPL reads your input, evaluates it, and prints the result before looping back and doing the same thing again.
The Python REPL has been around for decades, and it supports an explorative workflow that makes Python a beginner-friendly language. Unfortunately, the interpreter has been missing several features you may have come to expect, including multiline editing and efficient pasting of code.
Note: Experienced Python developers often install a third-party interactive interpreter instead of relying on the built-in REPL. You can learn more about the alternatives in these tutorials:
- Unlock IPython’s Magical Toolbox for Your Coding Journey
- Discover bpython: A Python REPL With IDE-Like Features
- Boost Your Coding Productivity With Ptpython
You can also read more about alternative REPLs in the guide to the standard REPL.
Begin by starting the REPL. You can do this by typing python in your terminal. Depending on your setup, you may have to write py, python3, or even python3.13 instead. One way to recognize that you’re using the new interpreter shipping with Python 3.13 is that the prompt consisting of three chevrons (>>>) is subtly colored:
One improvement is that you can now use REPL-specific commands without calling them with parentheses as if they are Python functions. Here are some of the commands and keyboard shortcuts you can use:
- exit or quit: Exit the interpreter
- clear: Clear the screen
- help or F1: Access the help system
- F2: Open the history browser
- F3: Enter paste mode
You can learn more about these options in Python 3.13 Preview: A Modern REPL.
Recalling code you’ve written earlier has been cumbersome in the REPL before Python 3.13, especially if you’re working with a block of code spanning several lines. Traditionally, you’ve had to bring back each line one by one by repeatedly pressing Up. Now in 3.13, you can bring back the whole block of code with a single Up keystroke.
To try this for yourself, enter the following code in your REPL:
Python >>> numbers = range(3, 13) >>> [ ... (number - 3)**3 for number in numbers ... if number % 2 == 1 ... ] [0, 8, 64, 216, 512] Copied!You’re creating a somewhat complex list comprehension that calculates an offset cube of a range of numbers, but only if the numbers are odd. The important part is that for readability, you split the list comprehension over several lines. Now try hitting that Up key! The interpreter recalls all four lines at once, and you can continue to use your arrow keys to move around inside of the expression.
You can make changes to your code and run it again. To execute the updated code, you need to move your cursor to the end of the last line in the code block. If you press Enter inside the expression, you’ll create a new empty line instead:
The ability to recall and edit multiline statements is a huge time-saver and will make you more efficient when working with the REPL.
Another convenience coming in Python 3.13 is proper support for pasting code. In Python 3.12 and earlier, you’d need to make sure that your code doesn’t contain any blank lines before you could copy and paste it. In the new version, pasted code is treated as a unit and executes just as it would inside a script.
Read the full article at https://realpython.com/python313-new-features/ »[ 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 ]
PyCharm: What’s the Big Deal About Endpoints for Python Web Development?
Python has almost 30 years of history doing Python web development. Can you believe it? But 3-tier web projects have gotten really complicated and stressful. You’re busy, everything is all over the place – it’s hard!
But PyCharm is here to help: bring your work together with the Endpoints tool window. I just made a video explainer:
Try the Endpoints tool window!Here are 3 things from the video that I really like about endpoints. Plus a bonus point at the end.
First…where is everything?Python web projects can get really big, really fast. If you’re like me, it can be overwhelming – and exhausting. I really need a “helper brain” – one that deeply understands each web framework – to stitch everything together.
PyCharm has long provided icons to navigate from a view to a template, and vice versa. Endpoints adds icons to jump from a view to the route definition, to the parent context, and generate a request to this API.
I like to use my keyboard instead of the mouse. Good news – endpoints is wired into searchable actions.
Want a birds-eye view of all your endpoints? The Endpoints tool window shows all your APIs, with filtering by subapp, type, and framework.
It’s more than a list. Each entry lets you jump to the endpoint and perform operations.
These operations have framework-specific smarts, such as knowing the “parent context” for Django vs. Flask vs. FastAPI.
I like having this tool window when I’m thinking about the whole application. But I like even more how endpoints brings these operations into the editor, to my cursor, helping me focus.
Bring IDE smarts, into APIsOur IDE has deep insight to connect the dots in Python development. What if we applied that to Python web frameworks?
I can’t remember all my API names. Endpoints gives me autocomplete in the HTTP client and even in JavaScript fetch.
Thanks to endpoints, these routes become symbols. I’m a symbol-first coder, using autocomplete, warnings, and navigation to the max. Now I can apply that with the web framework syntax for APIs.
Discover more powerful web development features Stay in one toolI’ve always liked the “I” in IDE: integrating my important workflows into a single, consistent experience. Web development can mean bouncing around between lots of windows. What if we could bring that workflow into PyCharm?
We already brought best-in-class frontend development from WebStorm and database development from DataGrip.
Using our HTTP Client, you have a productive, mature workflow for issuing HTTP requests. No need to go to the browser or purchase another tool. With endpoints, HTTP Client gets easier and smarter. For example, issue an HTTP request, directly from the API listing.
As shown above, writing these HTTP requests is easier thanks to autocomplete, as endpoints knows your web framework and its route definitions.
You can also browse the OpenAPI documentation of your endpoint without going to a browser.
The “I” in IDE means it is one team that is bringing these features across web frameworks. When I learn a way of working once, I can use it when I shift to a project with another supported web framework. Same features, same UI.
Innovation in Python web developmentPython web development needs fresh new ideas and with it, new thinking in tooling. Endpoints says: “You are going to use multiple frameworks on lots of big projects. Let’s step back, focus on the problem, re-imagine the workflow, and throw a bunch of powerful IDE machinery at it.”
Just this one tool window has so much value in it: a listing of your API, with info about HTTP method, and right-click available for each. Then, tabs for the common operations, keeping you in the IDE and in the flow.
So that’s endpoints, a vision from PyCharm to make API development joyful and productive. Give it a try and let us know what you think.
Try the Endpoints tool window!Python Bytes: #403 A machine learning algorithm walks into a bar…
eGenix.com: Python Meeting Düsseldorf - 2024-10-02
The following text is in German, since we're announcing a regional user group meeting in Düsseldorf, Germany.
Das nächste Python Meeting Düsseldorf findet an folgendem Termin statt:
02.10.2024, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf
- Detlef Lannert:
pyinfra als Alternative zu Ansible - Marc-André Lemburg:
Rapid web app development with Panel - Detlef Lannert:
Low-cost-Objekte als Alternativen zu Dictionaries? - Charlie Clark:
Editieren von ZIP Dateien mit Python
Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden.
Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet
sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden.
Über dem Eingang steht ein großes "Schwimm’ in Bilk" Logo. Hinter der Tür
direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der
Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt.
>>> Eingang in Google Street View
Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet.
Einen guten Überblick über die Vorträge bietet unser PyDDF YouTube-Kanal, auf dem wir Videos der Vorträge nach den Meetings veröffentlichen.Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:
Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion.
Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit HDMI und FullHD Auflösung steht zur Verfügung.(Lightning) Talk Anmeldung bitte formlos per EMail an info@pyddf.de
KostenbeteiligungDas Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet.
Da Tagungsraum, Beamer, Internet und Getränke Kosten produzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst. Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst.
Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.
AnmeldungDa wir nur 25 Personen in dem angemieteten Raum empfangen können, möchten wir bitten, sich vorher anzumelden.
Meeting Anmeldung bitte per Meetup
Weitere Informationen finden Sie auf der Webseite des Meetings:
https://pyddf.de/
Viel Spaß !
Marc-Andre Lemburg, eGenix.com
Zato Blog: Enterprise Python: Integrating with Salesforce
Salesforce connections are one of the newest additions to Zato 3.2, allowing you to look up and manage Salesforce records and other business data. To showcase it, the article will create a sample Salesforce marketing campaign in a way that does not require the usage of anything else except for basic REST APIs combined with plain Python objects, such as dicts.
If you have not done it already, you can download Zato here.
Basic workflowThe scope of our works will be:
- Creating Salesforce credentials for our integration project
- Defining a Salesforce connection in Zato
- Authoring a service that will map input data to the format that Salesforce expects
- Creating a Zato REST channel that will be invoked through curl during tests
- Testing the integration
To be able to create as connection to Salesforce in the next step, we need a few credentials. There is a full article about how to prepare them and this section is the gist of it.
In runtime, based on this information, Zato will obtain the necessary authentication and authorization tokens itself, which means that you will only focus on the business side of the integrations, not on the low-level aspects of it.
The process of obtaining the credentials needs to be coordinated with an administrator of your organization. To assist in that, the screenshots below explain where to find them.
The credentials are:
- Username and password
- Consumer key
- Consumer secret
The username and password are simply the same credentials that can be used to log in to Salesforce:
Consumer key and secret are properties of a connected app - this is a term that Salesforce uses for API clients that invoke its services. If you are already an experienced Salesforce REST API user, you may know the key and secret under their aliases of "client_id" and "client_secret" - these are the same objects.
Note that when a connected app already exists and you would like to retrieve the key and secret, they will be available under the "View" menu option for the app, not under "Edit" or "Manage".
Defining a Salesforce connection in ZatoWith all the credentials in place, we can create a new Salesforce connection in Zato Dashboard, as below.
Authoring an integration service in PythonAbove, we created a connection definition that lets Zato obtain session tokens and establish connections to Salesforce. Now, we can create an API service that will make use of such connections.
In the example below, we are using the POST REST method to invoke an endpoint that creates new Salesforce campaigns. In your own integrations, you can invoke any other Salesforce endpoint, using any REST method as needed, by following the same pattern, which is, create a model with input fields, build a Python dict for the request to Salesforce, invoke it and map all the required from the response from Salesforce to that which your own service returns to its own callers.
Note that we use a datamodel-based SimpleIO definition for the service. Among other things, although we are not going to do it here, this would let us offer definitions for this and other services.
# -*- coding: utf-8 -*- # stdlib from dataclasses import dataclass # Zato from zato.server.service import Model, Service # ########################################################################### if 0: from zato.server.connection.salesforce import SalesforceClient # ########################################################################### @dataclass(init=False) class CreateCampaignRequest(Model): name: str segment: str # ########################################################################### @dataclass(init=False) class CreateCampaignResponse(Model): campaign_id: str # ########################################################################### class CreateCampaign(Service): class SimpleIO: input = CreateCampaignRequest output = CreateCampaignResponse def handle(self): # This is our input data input = self.request.input # type: CreateCampaignRequest # Salesforce REST API endpoint to invoke - note that Zato # will add a prefix to it containing the API version. path = '/sobjects/Campaign/' # Build the request to Salesforce based on what we received request = { 'Name': input.name, 'Segment__c': input.segment, } # .. create a reference to our connection definition .. salesforce = self.cloud.salesforce['My Salesforce Connection'] # .. obtain a client to Salesforce .. with salesforce.conn.client() as client: # type: SalesforceClient # .. create the campaign now .. sf_response = client.post(path, request) # .. build our response object .. response = CreateCampaignResponse() response.campaign_id = sf_response['id'] # .. and return its ID to our caller. self.response.payload = response # ########################################################################### Creating a REST channelNote that we assign HTTP Basic Auth credentials to the channel. In this manner, it is possible for clients of this REST channel to authenticate using a method that they are already familiar which simplifies everyone's work - it is Zato that deals with how to authenticate against Salesforce whereas your API clients use the ubiquitous HTTP Basic Auth method.
Testing
The last step is to invoke the newly created channel:
$ curl http://api:password@localhost:17010/api/campaign/create -d '{"name":"Hello", "segment":"123"}' {"campaign_id":"8901Z3VHXDTebEJWs"} $That is everything - you have just integrated with Salesforce and exposed a REST channel for external applications to integrate with!
More resources➤ Python API integration tutorial
➤ What is an integration platform?
➤ Python Integration platform as a Service (iPaaS)
➤ What is an Enterprise Service Bus (ESB)? What is SOA?
Quansight Labs Blog: Numpy QuadDType: Quadruple Precision for Everyone
Quansight Labs Blog: Polars Plugins: let's make them easier to use
Python⇒Speed: Beyond multi-core parallelism: faster Mandelbrot with SIMD
What do you do when computation is too expensive?
Recently I’ve had a brilliant business idea: Mandelbrot-as-a-Service! Instead of companies calculating their own fractals, I will do it for them, freshly calculated in the cloud, with no work on their part. And by using cloud computing, I will be able to scale to the no-doubt vast number of customers who will be paying for my ingenious new service.
I have two goals:
- Speeding up results: The faster I can return fractals, the happier my customers will be.
- Reducing costs: If I can pay my cloud provider less for computing, my profits will go up!
Unfortunately, since I will only be selling freshly calculated and warm-from-the-CPU Mandelbrots, I can’t rely on caching.
What would you do in this situation?
One obvious approach is parallelism: threading or multiprocessing. This will speed up results, so it’s definitely worth doing, but it won’t reduce my costs. If we use 10 cores instead of 1 core, the service will return results ten times faster, but we’ll have to pay approximately 10× as much, since we’ll be using 10× larger instances.
However, if we can figure out how to speed up calculations on a single core, this will contribute to both our goals. We’ll both get faster results, compounded by any multi-core processing, and reduce compute costs.
In this article we will:
- Quickly go over a standard Mandelbrot implementation, written in Rust.
- Discuss why it can be tricky to optimize the Mandelbrot algorithm on a single CPU core.
- Demonstrate how you can in fact do so, by using masked SIMD operations.
- Trivially add on multi-core parallelism, using Rust’s Rayon library.
- PROFIT!
Mike C. Fletcher: Interesting Memory Leak with Python 3.12 for PyOpenGL-accelerate
So I'm currently trying to figure out why the PyOpenGL 3.12 test suite is failing. There's a particular test that looks for VBO memory leakage and it looks loosely like this:
for i in range(100):
create_a_vbo_and_delete_it()
calculate_total_process_memory()
assert_no_leak()
which shouldn't ever lose more than a few bytes (limit is set to 200 for this test, but it doesn't lose even one normally). This passes fine on python2.7 through 3.11, but on 3.12 the first 75 iterations leak nothing, then on the 76th iteration (always the 76th) iteration there is a substantial memory leak (100s of KB) and then memory usage goes flat again.
My first guess is that there's something in the 3.12 JIT compiler that looks for e.g. 75 iterations, then does lots of analysis and caching and uses the 100s of KBs of RAM to track the behaviour. I can "fix" the test by reducing the iterations below 75, but that doesn't really address the underlying issue of the test, which is that it's using whole-system memory as a proxy for "did this local function leak RAM". Guess I need to find a better "does some RAM leak" test.
Update: always 75th iteration observation is *only* when run with just the single test. When run in the main test suite, the JIT seems to kick in much earlier (likely because of other tests exercising the same paths). That means it's likely to start failing as more tests are added, which reinforces the need to find a better test method.
The Python Coding Blog: The Python Coding Stack’s New Look
The Python Coding Stack has a new look. Here it is:
The Stack has been growing steadily as a standalone publication, separate from The Python Coding Book and The Python Coding Place, and now it has its own identity.
It offers a very different and unique perspective on Python programming, often with a narrative style.
If you’ve not read articles on The Stack yet, have a look at some of the most recent ones, or the top 5.
The post The Python Coding Stack’s New Look appeared first on The Python Coding Book.
Ned Batchelder: Changelog philosophy
I playfully quipped about changelogs, and Sumana Harihareswara thoughtfully responded with Changelogs and Release Notes. I agree with her on some things, and disagree on others.
My point with the meme was that people should put effort into a hand-crafted description of what has changed in each release of their product. It should be focused on what users need to know, and not include internal changes, which can be found in the git commits or pull requests. It’s easy to publish a list of commits or pull requests and call it a changelog, but it’s not that helpful to your users trying to understand what has changed for them. That was the point of the meme.
But Sumana raised the stakes, explaining why projects should produce two hand-crafted descriptions. The first is a changelog which mentions every non-trivial change. The second are release notes which should be user-focused with more details.
I liked the reasons Sumana gave:
- Release notes can include project-level information that doesn’t correspond to a particular change in a release. Maybe you started a new discussion forum, or there’s a shift in maintainer attention, plans for upcoming work, and so on.
- If the release notes are user-focused, then the changelog can be more comprehensive, giving people a fuller picture of the work that goes into producing the project. This can pull back the curtain, helping people understand the inner workings of the project and perhaps find a way to help out.
My problem with separating the changelog and release notes is that I have limited energy to produce them, and perhaps more importantly, people have limited attention to read them. For my projects, I opt instead for a middle ground: my changelogs lean more toward Sumana’s ideal of release notes. They are hand-written, focused on what users of the project need to know, and do not include things like build changes and refactorings.
For large projects like Python and Linux, there are many maintainers and many types of information, so it makes sense to have multiple views of “what’s changed.” For single-maintainer projects, it feels like too much. I applaud people who can do it, but I don’t think I can, and I won’t expect it from others.
Ultimately, each project has to decide for themselves how to balance the effort and the benefit. They know their audience(s), and what resources they have to do the work. Open source is already difficult, the last thing I want to do is add a giant SHOULD to a project.
There’s an inexact nested ratio at work in projects: Most users (say 90%) will only consume, you will never hear from them. You hear from the remaining 10%, but only 10% of those will do something you consider a contribution. For widely used projects like coverage.py, I think the ratio might be more like 1% of 1% instead of 10% of 10%. How does this affect your communication approach? You could look at it two ways: either write for the audience you have (focus on the 90%), or write for the audience you want (focus on the 10%).
In my changelogs now, for fixes I try to describe the bad thing that used to happen and any important changes in behavior. For features, I link to the new docs. I include links to issues and pull requests, and I name the contributors who helped.
So I guess my approach is to write changelogs for the 90%. But I like Sumana’s idea of making the full picture of maintainence more visible to people, so I’m thinking about how to add that without changing the essential character of my changelog. Perhaps something at the end summarizing the changes that aren’t yet mentioned, with a link to the git history? I’m not sure I can automate collecting that information, but I’ll have to play with it.
Real Python: Quiz: Syntactic Sugar: Why Python Is Sweet and Pythonic
Test your understanding of Python’s most common pieces of syntactic sugar and how they make your code more Pythonic and readable.
Take this quiz after reading our Syntactic Sugar: Why Python is Sweet and Pythonic tutorial.
[ 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 ]
Real Python: Quiz: Python 3.13: Cool New Features for You to Try
In this quiz, you’ll test your understanding of Python 3.13: Cool New Features for You to Try. By working through this quiz, you’ll review the key updates and improvements in this version of Python.
[ 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 ]