<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: nas</title><link>https://news.ycombinator.com/user?id=nas</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 14 May 2026 14:16:08 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=nas" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by nas in "Reverting the incremental GC in Python 3.14 and 3.15"]]></title><description><![CDATA[
<p>If you are using "httpx", it's likely caused by a reference cycle.  I made a PR to fix it but the maintainers haven't applied it. :-(  <a href="https://github.com/encode/httpx/pull/3733" rel="nofollow">https://github.com/encode/httpx/pull/3733</a><p>The reference cycle httpx creates is kind of a worst-case scenario for the incremental GC issue.  Both the generational (3.13 and older) and incremental GC are triggered by the net new "container" objects (objects that have references to others, like lists and not like ints and floats).  The short summary is that you need to create more container objects before the incremental GC triggers.  In the case of the httpx reference cycle, you have a relatively small number of container objects hanging on to a lot of memory, due the SSL context data (which is a big memory hog).<p>Reverting back to the generational GC was the wise thing to do, even though it's a bit scary to do in a  bugfix release.  The incremental GC works for most people but in the minority of cases it doesn't, it uses quite a lot more memory.  I'm pretty sure with some additional tuning, the incremental GC would be fine too but it just didn't get that tuning.  The generational GC has literal decades of real-world use (Guido merged my patch on Jun 2000, Tim Peters did a bunch of tuning after that to optimize it).</p>
]]></description><pubDate>Wed, 13 May 2026 22:46:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=48128597</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=48128597</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48128597</guid></item><item><title><![CDATA[New comment by nas in "Comparing Python Type Checkers: Typing Spec Conformance"]]></title><description><![CDATA[
<p>Just an FYI, for people looking at the low pass rates for mypy and ty and concluding they must not be very useful.  These test suites are checking many odd corners of the typing spec.<p>For "normal" Python code, I find mypy does pretty good.  Certainly I find it helpful, especially on a large code base and when working with other developers of various experience levels.<p>The reason I prefer pyrefly over mypy is mostly because of speed.  Better accuracy is nice but speed it the killer feature.  Given the quality of uv and ruff and the experience of the team working on ty, I'm quite confident it's going to be great in that respect as well.</p>
]]></description><pubDate>Tue, 17 Mar 2026 06:32:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=47409333</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=47409333</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47409333</guid></item><item><title><![CDATA[New comment by nas in "-fbounds-safety: Enforcing bounds safety for C"]]></title><description><![CDATA[
<p>My CS college used Turbo Pascal as a teaching language.  I had a professor who told us "don't turn the range and overflow checking off, even when compiling for production".  That turned out to be very wise advice, IMHO.  Too bad C and C++ compiler/language designers never got that message.  So much wasted to save that less than 1% performance gain.</p>
]]></description><pubDate>Thu, 19 Feb 2026 23:55:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=47081600</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=47081600</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47081600</guid></item><item><title><![CDATA[New comment by nas in "The future of Python web services looks GIL-free"]]></title><description><![CDATA[
<p>I get:<p>3.9: 2.78<p>3.14: 3.86<p>3.14t: 3.91<p>This is a silly benchmark though.  Look at pyperformance if you want something that might represent real script/application performance.  Generally 3.14t is about 0.9x the performance of the default build.  That depends on a lot of things though.</p>
]]></description><pubDate>Sat, 25 Oct 2025 19:17:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=45706263</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=45706263</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45706263</guid></item><item><title><![CDATA[New comment by nas in "DOGE puts $1 spending limit on government employee credit cards"]]></title><description><![CDATA[
<p>The "starve the beast" strategy (<a href="https://en.wikipedia.org/wiki/Starve_the_beast" rel="nofollow">https://en.wikipedia.org/wiki/Starve_the_beast</a>) has been around for a long time and is something that some right wing conservative people want to do.  E.g. Norquist's quote that "My goal is to cut government in half in twenty-five years, to get it down to the size where we can drown it in the bathtub.".<p>As someone else mentioned, this isn't only about improving efficiency of the government but also about it doing less.  So things that currently you would be getting from the government you would no longer be getting.  You might agree or disagree with this idea.<p>Predicting what Trump is going to do is not easy.  I don't think he really knows himself each day what he will get up to.  Mostly draw a lot of attention to himself, seems the main goal.  He's doing fantastic on that front.  Regarding policy, he is a lot more purposeful vs his previous term and he is pretty closely following the Project 2025 playbook:<p><a href="https://old.reddit.com/r/OutOfTheLoop/comments/1itd7xq/whats_the_deal_with_all_these_executive_orders_is/" rel="nofollow">https://old.reddit.com/r/OutOfTheLoop/comments/1itd7xq/whats...</a><p><a href="https://docs.google.com/spreadsheets/d/1RHMnJmuv82n6OuY8KYmJIsoGN3j_DuNEmOIEyBhKfyA/edit?gid=0#gid=0" rel="nofollow">https://docs.google.com/spreadsheets/d/1RHMnJmuv82n6OuY8KYmJ...</a><p>Enacting government policy primarily through executive orders is an "interesting" approach.  I would say that's not how you want a government to work.  Maybe Trump's extreme use of EOs will prompt some reform or maybe it will become the new norm.  The other branches of the US government don't seem very interested in actually performing their job.</p>
]]></description><pubDate>Thu, 20 Feb 2025 22:22:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=43121093</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=43121093</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43121093</guid></item><item><title><![CDATA[New comment by nas in "Why is hash(-1) == hash(-2) in Python?"]]></title><description><![CDATA[
<p>Every PyObject structure has a ob_type pointer.</p>
]]></description><pubDate>Sat, 11 Jan 2025 07:21:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=42664012</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=42664012</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42664012</guid></item><item><title><![CDATA[New comment by nas in "State of Python 3.13 performance: Free-threading"]]></title><description><![CDATA[
<p>You should probably just read the PEP, which explains these things:<p><a href="https://peps.python.org/pep-0703/#reference-counting" rel="nofollow">https://peps.python.org/pep-0703/#reference-counting</a><p>If by GC you mean the cyclic GC, free-threaded Python currently stops all threads while the cyclic GC is running.</p>
]]></description><pubDate>Wed, 06 Nov 2024 05:42:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=42057401</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=42057401</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42057401</guid></item><item><title><![CDATA[New comment by nas in "State of Python 3.13 performance: Free-threading"]]></title><description><![CDATA[
<p>The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.</p>
]]></description><pubDate>Wed, 06 Nov 2024 01:19:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=42056616</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=42056616</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42056616</guid></item><item><title><![CDATA[New comment by nas in "Tim Peters has returned on the Python Discourse forum"]]></title><description><![CDATA[
<p>There are a whole set of problems, IMHO. The code-of-conduct working-group (CoC WG) members are self selected.  There is no effective oversight mechanism.  No matter if you think they are currently doing a good job or not, it's not a proper way to organize such a group. The steering council (SC) did a poor job in communicating and their tendency towards secretiveness does not inspire confidence that the machinery regarding these things is working correctly.  Part of the justification for secrecy is that they are protecting the banned person.  That is hard to believe since it's trivial to figure out who they are talking about given their initial ban announce posting (X number of posts in a certain topic points to exactly one person).  So it looks more like the secrecy is to avoid answering uncomfortable questions about the decision making and the process and not about actually protecting the accused.<p>Someone made a great analogy about what is happening here. You have a machine that is supposed to make toy dolls.  One day you notice the dolls coming out the machine are deformed and weird looking.  So, you say to the doll factory manager:<p>> I think something is wrong with the doll making machine.<p>They say<p>> No, this is a very high quality doll making machine, look at the specifications on the great looking dolls it will make.  Don't you trust that this machine will make proper dolls?  The manufacturer and people running the machine are all very trustworthy<p>You say:<p>> That might be true but I see the dolls coming out are deformed, something must be wrong.<p>Tim does not get a free pass to behave badly just because he is a long-time Python contributor.  However, given his literal decades of civil behavior in many public forums, it is hard to believe he did something that was justifying a ban.  Based on looking at what the CoC WG shared and what Tim shared, I don't see anything that justifies it.  So, I don't think the "machine" is working correctly.</p>
]]></description><pubDate>Sat, 02 Nov 2024 00:47:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=42023107</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=42023107</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42023107</guid></item><item><title><![CDATA[New comment by nas in "Free-threaded CPython is ready to experiment with"]]></title><description><![CDATA[
<p>Very encouraging news!</p>
]]></description><pubDate>Fri, 12 Jul 2024 20:34:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=40949152</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=40949152</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40949152</guid></item><item><title><![CDATA[New comment by nas in "Origin of BDFL (2008)"]]></title><description><![CDATA[
<p>I think it means it could be a title from a Monty Python skit, not that it necessarily is taken from one.</p>
]]></description><pubDate>Tue, 28 May 2024 03:35:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=40497092</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=40497092</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=40497092</guid></item><item><title><![CDATA[New comment by nas in "Ansel"]]></title><description><![CDATA[
<p>darktable is still being developed.  There are pretty regular releases.  I use it as my main photo processing software (raw-based workflow).<p>As I said in my other comment, Aurélien has strong opinions.  He felt he could not effectively work with the other darktable devs and decided to fork the project.</p>
]]></description><pubDate>Thu, 23 Nov 2023 21:16:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=38397654</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=38397654</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38397654</guid></item><item><title><![CDATA[New comment by nas in "Ansel"]]></title><description><![CDATA[
<p>This is the work of a former "darktable" developer (Aurélien Pierre) who decided to fork the codebase and go it alone. He has strong opinions about the correct way to do things.  I like some of the cleanup on the UI that he has done.  For now, Ansel and darktable are compatible in terms of the underlying database.  So you can easily switch back and forth between them.  If the fork diverges significantly, it would be more difficult to maintain the compatibility.<p>darktable has seen some major changes in the past few years, moving away from a "display-referred" to a "scene-referred" workflow.  Aurélien contributed a lot of code to make that work, most significantly, the Filmic module.  darktable is not as user friendly and as polished as other commercial tools (Lightroom, Affinity, Capture One) but it is capable if you take the time to learn it.</p>
]]></description><pubDate>Thu, 23 Nov 2023 21:13:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=38397623</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=38397623</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38397623</guid></item><item><title><![CDATA[New comment by nas in "The Ashley Book of Knots (1944)"]]></title><description><![CDATA[
<p>You can make due with only a couple of good knots.  Very short list: the reef knot (square knot, avoid the granny version) and the alpine butterfly (don't use reef knot for joining two ropes, i.e. a "bend").  The alpine butterfly is more useful to know than the bowline, IMHO.<p>If you want to expand your list a little, here are some additional useful ones: double fisherman's, adjustable grip hitch, sheet bend, trucker's hitch.<p>Edit: I suppose this is more useful with a little additional commentary.  The reef knot is so common that you should know it and know how to avoid the granny knot and also when not to use it (e.g. as a bend).  You can use the alpine butterfly as a bend and also for quite few other things.  It is more versatile than the bowline (e.g. if you need a loop that doesn't slip) and works fine as a bend (very smiilar to the Zeppelin bend).</p>
]]></description><pubDate>Wed, 27 Sep 2023 19:57:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=37680392</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=37680392</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=37680392</guid></item><item><title><![CDATA[New comment by nas in "Free42 – An HP-42S Calculator Simulator"]]></title><description><![CDATA[
<p>The 41C came out about 10 years before the 42S.  Each would have their fans.  The 42S doesn't have the hardware expand-ability but is generally faster and a bit more refined.  If I wanted a nice handheld calculator today, I'd prefer the HP-42S or the Swiss Micro version.  However, Swiss Micros have a 41C clone as well, if you prefer that.</p>
]]></description><pubDate>Fri, 12 May 2023 04:11:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=35911805</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=35911805</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35911805</guid></item><item><title><![CDATA[New comment by nas in "Farmers ‘crippled’ by satellite failure as GPS-guided tractors grind to a halt"]]></title><description><![CDATA[
<p>Nothing insurmountable.  You need a receiver that supports RTK.  Typically the hardware receiver can do it but you have pay to unlock the functionality (typically about 3000 USD per device).  You need an RTK base station (or one you can use that's not too far away) and a way to get the correction signal (local radio system or over Internet with cellular data).<p>With DGPS corrections, like you get with the satellite that failed, you get about 10 cm positional accuracy.  For dryland crop farming, that's often good enough.  It is more accurate than what most human operators can achieve and reduces operator fatigue.  So many ag GPS systems are setup to use it out of the box.<p>There are other solutions, in addition to RTK.  Trimble has "CenterPoint".  There are Omnistar corrections (different sats, better accuracy than DGPS).  Novatel has "GLIDE" but I've never seen it in use.</p>
]]></description><pubDate>Thu, 20 Apr 2023 23:46:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=35648089</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=35648089</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35648089</guid></item><item><title><![CDATA[New comment by nas in "PEP 684 was accepted – Per-interpreter GIL in Python 3.12"]]></title><description><![CDATA[
<p>This is great and was a huge effort by Eric Snow and collaborators to make it happen.<p>To be clear, this is not "PEP 703 – Making the Global Interpreter Lock Optional in CPython", by Sam Gross.  PEP 703 is more ambitious and add quite a bit of complexity to the CPython implementation.  PEP 684 mostly cleans things up and encapsulates global state better.  The most distruptive change is to allow immortal objects.  I hope PEP 703 can go in too, even with the downsides (complexity, bit slower single threaded performance).</p>
]]></description><pubDate>Sat, 08 Apr 2023 20:06:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=35497075</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=35497075</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35497075</guid></item><item><title><![CDATA[New comment by nas in "Python Basics Onepager"]]></title><description><![CDATA[
<p>A variable is not a container.  That would imply you can only put an object in one container. In Python, a variable is a label for an object.  There can be multiple labels on a single object.  If the object is mutable, you can tell it's the same object (or use id()).</p>
]]></description><pubDate>Sat, 11 Mar 2023 02:41:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=35104579</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=35104579</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35104579</guid></item><item><title><![CDATA[New comment by nas in "Python 3.11.0 final"]]></title><description><![CDATA[
<p>Pablo (the release manager) did his PhD on black hole physics.</p>
]]></description><pubDate>Tue, 25 Oct 2022 16:25:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=33332741</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=33332741</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=33332741</guid></item><item><title><![CDATA[New comment by nas in "TIL–Python has a built-in persistent key-value store (2018)"]]></title><description><![CDATA[
<p>ZODB is awesome and overlooked, IMHO.  I'm biased I guess because I was involved in making Durus which is inspired by ZODB.  The ZODB model is not appropriate for all applications (optimistic concurrency control) but for the applications it works for, it's great.  Very easy to develop with (no relational-to-OO mismatch) and performance can be great if you design your model carefully.  The client caching of data is great.  It is a bit like memcache but the data is already there as objects in RAM.  The database server will invalidate the cache for you, no manual invalidation needed.</p>
]]></description><pubDate>Thu, 15 Sep 2022 20:30:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=32858041</link><dc:creator>nas</dc:creator><comments>https://news.ycombinator.com/item?id=32858041</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=32858041</guid></item></channel></rss>