Lingunymous
git.anarchists.space
A tool for concealing writing style to evade linguistic fingerprinting

Everyone has a unique writing style, word choice, sentence structure, punctuation habits and that can be used to identify them. Lingunymous rewrites your text using a local LLM to mask these patterns, making it harder to attribute writing to a specific individual.

Use cases include:

  • Protecting anonymity when publishing sensitive or controversial content
  • Evading authorship attribution and stylometric analysis
  • Separating your personal writing fingerprint from pseudonymous accounts
  • thesmokingman@programming.dev
    14·
    2 days ago

    The pyproject.toml spec is ten years old. Python 3 is almost twenty years old. The community standard moved within the last five years. Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry. If you’ve got GitHub workflows that’s the standard anyway so you should be running something like act locally. Static typing redundancy is a waste of compute.

    If you’re going to be an asshole, make sure you can back everything up. You can’t so I’d recommend taking a breath and going outside.

    Edit: I looked through your GitHub and even though your profile name is “msftcangoblowm” you don’t seem to use .yaml but instead the YAML extension Windows devs use.

    • logging_strict@programming.dev
      2·
      12 hours ago

      Static typing redundancy is a waste of compute.

      Have never encountered anyone suggesting doing less static type checking.

      Static typing finds bugs. Especially pyright. Especially within tests. Separating the static type checking into stubs reduces any performance impact from typing related imports.

      With py315, there will be soft|lazy import. Excess imports will have minimal impact cuz import proxy will be created but not executed until the import is actually used…

    • logging_strict@programming.dev
      1·
      11 hours ago

      Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry.

      No it can’t. They are two different things. tox can be replaced with nox. In the past, nox was promoted in this community. Looked into it and couldn’t, for the life of me, figure out how it added value?

      You mentioned Poetry, so i get to belittle Poetry. If you hadn’t mentioned it, Would have keep my mouth shut. So this is on you!

      Poetry only reason for being is to bring all the requirements files into TOML. The author loves TOML format. I get it. But at the expense of removing the constraint and requirement files hierarchy. Or a sane way of dealing with requirements of multiple venv. Or a sane clean way of managing dependency imposed lowerbound pins. Which come and go, so need to attribute which dependency imposed which set of lowerbound pins and most importantly why! Over time, the why is lost and with all the pins imposed by from various now unknown dependencies mixed into one insane pot.

      Poetry is fine if you are the author of one package (and live in a utopia and not clownworld or fight club). And you have one venv. Lets scale that up to being the prolific author or maintainer of 10 or 100 inter-dependent packages each package having multiple venv. Now you are good and fck’ed cuz Poetry doesn’t handle that situation. In fact, nothing does.

      wreck tracks requirements by venv and syncs all the requirements as best it can. My intention was to eventually sync across multiple packages. But never got around to writing that level.

      Poetry is unnecessary from the day the author first sat down to write it. And is the source of frustration to end users cuz Poetry encourages author/maintainers to create dependency upperbound pins.

      So tell me again how wonderful Poetry is. Go on defend it!

    • logging_strict@programming.dev
      1·
      12 hours ago

      The pyproject.toml spec is ten years old. Python 3 is almost twenty years old.

      To my knowledge, for TOML spec, strict validating against a schema is not a thing. So it’s not used with very likely dangerous user input.

      So the spec could be 100,000 years old, for obvious security vulnerability reasons, would still not touch it.

      Recommend taking a read through the strictyaml authors documentation on shortcomings of various user supplied input file formats.

      You are in for a treat:

      specifically Why not TOML

    • logging_strict@programming.dev
      1·
      10 hours ago

      First thank you for taking a look and holding my feet to the fire.

      Have several packages based on strictyaml. What matters is YAML files are validated against a schema. Whether use .yml or .yaml is personal preference. My personal preference is typing less characters. Both should be allowed.

      Share your hatred of Windows and don’t even see it as a serious OS. So was actually surprised that .yml has some association with Windows or MSFT.

      If while using any of below packages, you find the .yaml suffix is not recognized, that would be a bug. In which case, create an issue.

      These published packages could be affected:

      logging-strict

      pytest-logging-strict

      sphinx-external-toc-strict

      To actually confirm has bug status, would have to review the unit tests and see if .yaml is not tested nor recognized. Otherwise it’s mere conjecture. It’s an unconfirmed possibility. Maybe you are right, maybe not. Or maybe you are on to something.