<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Python 3.14 on Nalar</title>
    <link>https://nalar.dev/tags/python-3.14/</link>
    <description>Recent content in Python 3.14 on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 08 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/python-3.14/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Copy and Move Paths with pathlib in Python 3.14</title>
      <link>https://nalar.dev/copy-and-move-paths-with-pathlib-in-python-3-14/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/copy-and-move-paths-with-pathlib-in-python-3-14/</guid>
      <description>&lt;p&gt;Python 3.14 adds high-level copy and move operations directly to &lt;code&gt;pathlib.Path&lt;/code&gt;. &lt;code&gt;Path.copy()&lt;/code&gt;, &lt;code&gt;Path.copy_into()&lt;/code&gt;, &lt;code&gt;Path.move()&lt;/code&gt;, and &lt;code&gt;Path.move_into()&lt;/code&gt; make many filesystem workflows easier to express without switching between &lt;code&gt;pathlib&lt;/code&gt;, &lt;code&gt;shutil&lt;/code&gt;, and &lt;code&gt;os&lt;/code&gt; for basic operations.&lt;/p&gt;&#xA;&lt;p&gt;The convenience is useful, but filesystem mutations still need explicit policy. Overwrites, symbolic links, metadata, cross-filesystem moves, partial failure, and concurrent changes can all affect correctness.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-four-new-operations&#34;&gt;The four new operations&lt;/h2&gt;&#xA;&lt;p&gt;Use &lt;code&gt;copy()&lt;/code&gt; when the destination path itself is known:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Process Template Strings Safely with Python T-Strings</title>
      <link>https://nalar.dev/process-template-strings-safely-with-python-t-strings/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/process-template-strings-safely-with-python-t-strings/</guid>
      <description>&lt;p&gt;Python&amp;rsquo;s f-strings are excellent when the desired result is immediately a string. That same immediacy becomes a limitation when an application needs to inspect interpolated values before deciding how they should be represented.&lt;/p&gt;&#xA;&lt;p&gt;Python 3.14 adds &lt;strong&gt;template string literals&lt;/strong&gt;, usually called &lt;strong&gt;t-strings&lt;/strong&gt;, for that boundary. A t-string looks much like an f-string, but it does not immediately collapse its literal text and interpolated values into one &lt;code&gt;str&lt;/code&gt;. Instead, it produces a structured &lt;code&gt;Template&lt;/code&gt; object from &lt;code&gt;string.templatelib&lt;/code&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Run CPU-Bound Python Work with InterpreterPoolExecutor</title>
      <link>https://nalar.dev/run-cpu-bound-work-with-interpreterpoolexecutor/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/run-cpu-bound-work-with-interpreterpoolexecutor/</guid>
      <description>&lt;p&gt;Python has traditionally offered two familiar high-level choices for parallel work: threads and processes. Python 3.14 adds a third option to &lt;code&gt;concurrent.futures&lt;/code&gt;: &lt;code&gt;InterpreterPoolExecutor&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;It runs workers in separate Python interpreters inside one process. Each worker has its own interpreter state and its own Global Interpreter Lock (GIL), so pure Python code can execute on multiple CPU cores at the same time.&lt;/p&gt;&#xA;&lt;p&gt;That makes the executor interesting for CPU-bound workloads, but it is not a drop-in way to make arbitrary threaded code parallel. Interpreter isolation changes the programming model. Mutable Python objects are not simply shared between workers, submitted work crosses a serialization boundary, imports and module globals are interpreter-local, and extension compatibility deserves deliberate testing.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Use Native Max-Heaps with Python heapq</title>
      <link>https://nalar.dev/use-native-max-heaps-with-python-heapq/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/use-native-max-heaps-with-python-heapq/</guid>
      <description>&lt;p&gt;Python&amp;rsquo;s &lt;code&gt;heapq&lt;/code&gt; module has historically been centered on min-heaps: the smallest element lives at index zero. Developers who needed a max-heap commonly negated numeric priorities before pushing them and negated them again after popping.&lt;/p&gt;&#xA;&lt;p&gt;Python 3.14 makes that workaround unnecessary for many programs. &lt;code&gt;heapq&lt;/code&gt; now exposes a complete max-heap API: &lt;code&gt;heapify_max()&lt;/code&gt;, &lt;code&gt;heappush_max()&lt;/code&gt;, &lt;code&gt;heappop_max()&lt;/code&gt;, &lt;code&gt;heappushpop_max()&lt;/code&gt;, and &lt;code&gt;heapreplace_max()&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The new functions are simple, but using them well still requires understanding heap invariants, fixed-size selection, tie-breaking, and the important difference between push-pop and replace operations.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Use Zstandard Compression with Python compression.zstd</title>
      <link>https://nalar.dev/use-zstandard-compression-with-python-compression-zstd/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/use-zstandard-compression-with-python-compression-zstd/</guid>
      <description>&lt;p&gt;Python applications have long had standard-library support for gzip, bzip2, LZMA, and zlib. Python 3.14 adds another important option: Zstandard support through &lt;code&gt;compression.zstd&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Zstandard is useful when a system needs a practical balance of compression ratio and throughput. The new module means many applications can read and write &lt;code&gt;.zst&lt;/code&gt; data without adding a third-party Python package. But choosing a compression API is not only about calling &lt;code&gt;compress()&lt;/code&gt; and &lt;code&gt;decompress()&lt;/code&gt;. Production code also needs to think about streaming, memory limits, frame boundaries, dictionaries, compatibility, and untrusted input.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
