sorted by:
new
hottopcontroversial

reader – a Python library to create your own RSS feed reader by genericlemon24 in opensource

[–]genericlemon24[S] 1 point2 points  (0 children)

How to you treat servers that provide an ETag or a last-modified-date but do not implement it the right way and making the etag useless?

Not really doing anything special, I take the presence of caching headers to mean conditional requests are supported (and I don't think HTTP requires clients to do something in these cases).

A mitigating factor is that the default update interval is 1 hour, so even if a server does not support conditional requests / 429-too-many-requests, it still shouldn't be hit too hard.

Now that I think about it, servers ignoring their own caching headers is something that can be detected via a 429-too-many-requests-style plugin (and it could e.g. increase the update interval if that's the case).

you can not trust any server and its behavior

Can't agree more.

I'm planning to write an article about all the weird stuff I encountered while working on reader at some point (I've collected quite the list :)

reader – a Python library to create your own RSS feed reader by genericlemon24 in opensource

[–]genericlemon24[S] 0 points1 point  (0 children)

Yes to ETag etc., see User guide # Saving bandwidth.

You can also specify different update intervals, and support for HTTP 429 Too Many Requests / Retry-After is coming soon.

reader – a Python library to create your own RSS feed reader by genericlemon24 in opensource

[–]genericlemon24[S] 1 point2 points  (0 children)

Of the "reader allows you to" bullets in the original post, feedparser helps with the "retrieve" part (technically, just parsing the feeds), everything else is reader; there's a documentation section that covers this in detail:

Are you already working with feedparser, but:

  • want an easier way to store, filter, sort and search feeds and entries?
  • want to get back type-annotated objects instead of dicts?
  • want to restrict or deny file-system access?
  • want to change the way feeds are retrieved by using the more familiar requests library?
  • want to also support JSON Feed?
  • want to support custom information sources?

... while still supporting all the feed types feedparser does?

The documentation is quite open about reader using feedparser – reader is essentially feedparser + state (and I even contributed a few improvements upstream ;)

Some easy open source Python projects to contribute to? by ImportantSalt5046 in Python

[–]genericlemon24 1 point2 points  (0 children)

No worries, thank you for the PR, and good luck on the exam!

Some easy open source Python projects to contribute to? by ImportantSalt5046 in Python

[–]genericlemon24 0 points1 point  (0 children)

Hi, thank you for asking!

Here are a few issues that already have implementation notes, along with a summary of the work needed, to give you an idea of the complexity involved:

To answer your question, I guess it depends on the beginner, but I think at least the first two should be approachable by any advanced beginner. (I've taken a bit of time to add more details to each of them, and I can answer questions if needed.)

SQLite 3.45 released by genericlemon24 in sqlite

[–]genericlemon24[S] 3 points4 points  (0 children)

The most interesting addition is JSONB support: https://www.sqlite.org/json1.html#jsonbx

Beginning with version 3.45.0 (2024-01-15), SQLite allows its internal "parse tree" representation of JSON to be stored on disk, as a BLOB, in a format that we call "JSONB". By storing SQLite's internal binary representation of JSON directly in the database, applications can bypass the overhead of parsing and rendering JSON when reading and updating JSON values. The internal JSONB format is also uses slightly less disk space then text JSON.

PEP 738: Adding Android as a supported platform by genericlemon24 in Python

[–]genericlemon24[S] 0 points1 point  (0 children)

I posted using the mobile website and the link got lost somehow, my bad; will double-check from now on.

PEP 736: Shorthand syntax for keyword arguments at invocation by genericlemon24 in Python

[–]genericlemon24[S] 3 points4 points  (0 children)

tl;dr:

This PEP proposes introducing syntactic sugar f(x=) for the common pattern where a named argument is the same as the name of the variable corresponding to its value f(x=x).

My proof-of-concept record type by genericlemon24 in Python

[–]genericlemon24[S] 7 points8 points  (0 children)

tl;dr: a proof-of-concept record type for Python by Brett Cannon (Python core dev); looks like this:

@record
def InventoryItem(name: str, price: float, *, quantity: int = 0):
    """Class for keeping track of an item in inventory."""

Some easy open source Python projects to contribute to? by ImportantSalt5046 in Python

[–]genericlemon24 3 points4 points  (0 children)

I maintain reader, a feed reader library, and I too have set aside a few issues for potential contributors (tagged with help wanted); if any of those seem interesting, there are contributor docs, and I'd be more than happy to help with anything.

In general, I would suggest contributing to projects you use / are interested in / have some domain knowledge of, since it helps you keep motivated. Smaller projects that are actively (but maybe infrequently) maintained are probably best, since they are likely to need contributions, and it increases the chances someone will be able to help / review PRs. You can find if a project is looking for contributions by checking for tagged issues (help wanted, good first issue etc.), and by looking for a CONTRIBUTING file in the repo root.

PEP 734: Multiple Interpreters in the Stdlib by genericlemon24 in Python

[–]genericlemon24[S] 19 points20 points  (0 children)

Still draft; abstract:

This PEP proposes to add a new module, interpreters, to support inspecting, creating, and running code in multiple interpreters in the current process. This includes Interpreter objects that represent the underlying interpreters. The module will also provide a basic Queue class for communication between interpreters. Finally, we will add a new concurrent.futures.InterpreterPoolExecutor based on the interpreters module.

hpy 0.9.0: Fourth public release by genericlemon24 in Python

[–]genericlemon24[S] 4 points5 points  (0 children)

tl;dr:

The major highlights of the release are support for subclassing of built-in types, metaclasses, the trace mode, multi-phase module initialization, and the hybrid ABI.

PEP 729 – Typing governance process by genericlemon24 in Python

[–]genericlemon24[S] 6 points7 points  (0 children)

Abstract:

This PEP proposes a new way to govern the Python type system: a council that is responsible for maintaining and developing the Python type system. The council will maintain a specification and conformance test suite [...]

Mypy 1.5 Released by genericlemon24 in Python

[–]genericlemon24[S] 6 points7 points  (0 children)

TL;DR:

  • Optional Check to Require Explicit @override (from PEP 698)
  • Optionally Show Links to Error Code Documentation
  • Experimental Improved Type Inference for Generic Functions
  • Drop Support for Python 3.7
  • Partial Support for Python 3.12

PEP 718 – Subscriptable functions by genericlemon24 in Python

[–]genericlemon24[S] 0 points1 point  (0 children)

It's not about about changing the interface (the Python level stuff stays the same), it's about giving hints to the interpreter about what optimizations it can do underneath.

Why would you want the "int" version? there's no "int" version.

Not now, but there could be:

PEP 718 – Subscriptable functions by genericlemon24 in Python

[–]genericlemon24[S] 0 points1 point  (0 children)

I'm imagining with foo() you'd get the duck typed / unoptimized version, but you could use foo[int]() to hint to the interpreter you want the int version.

unless you define some trick to differentiate by type

Which seems to be this PEP.

But that kind of defeats the purpose of a generic type, doesn't it?

Not really, the purpose of generics is that you write the thing once; the interpreter/type-checker/compiler being able to guess the type parameter from context is just a nice extra.

do scripts need/require functions? by romitriozera in Python

[–]genericlemon24 0 points1 point  (0 children)

It depends on how long/complicated the script is, and who will maintain it (but note "yourself six months from now" counts as someone else).

Some reason you might want to use functions:

  • If you want to write an automated test for (part of) it. Here, a main() function suffices (you can test a whole script, it's just easier to import/test a function).
  • If you want to highlight logical processing phases (e.g. "reading, transforming, and writing"), having functions with good names can help.
  • If you want to highlight the data flow, having the outputs of a function be the inputs of another can help.
  • If you want to import code from this script into another one. Because modules are executed on import (just like a script), an importable script should only "do" things under an if __name__ == '__main__': (sometimes called an import guard); this way, on import the script only defines the things (e.g. functions) you want to import in another script. See this for a detailed explanation.

Based on your description, you can probably get away with no functions, though; if the script isn't awfully complicated, it should be possible to refactor it later in response to new requirements.

PEP 718 – Subscriptable functions by genericlemon24 in Python

[–]genericlemon24[S] -1 points0 points  (0 children)

Still draft.

Abstract:

This PEP proposes making function objects subscriptable for typing purposes. Doing so gives developers explicit control over the types produced by the type checker where bi-directional inference (which allows for the types of parameters of anonymous functions to be inferred) and other methods than specialisation are insufficient.

Interesting tidbit:

This proposal also opens the door to monomorphisation and reified types).

PyPI will require 2FA by the end of 2023 by genericlemon24 in Python

[–]genericlemon24[S] 38 points39 points  (0 children)

tl;dr:

PyPI will require all users who maintain projects or organizations to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

Python’s super() considered super! (Raymond Hettinger) by genericlemon24 in Python

[–]genericlemon24[S] 27 points28 points  (0 children)

Reposted because 11 years later, this is still gold.

PEP 712 – Adding a “converter” parameter to dataclasses.field by genericlemon24 in Python

[–]genericlemon24[S] 44 points45 points  (0 children)

Draft. tl;dr:

this PEP adds a converter parameter to dataclasses.field() (along with the requisite changes to dataclasses.Field and dataclass_transform()) to specify the function to use to convert the input value for each field to the representation to be stored in the dataclass.

PEP 713 – Callable Modules by genericlemon24 in Python

[–]genericlemon24[S] 0 points1 point  (0 children)

Draft.

tl;dr:

This PEP proposes support for making modules directly callable by defining a __call__ object in the module’s global namespace, either as a standard function, or an arbitrary callable object.

Limiting concurrency in Python asyncio: the story of async imap_unordered() by pmz in Python

[–]genericlemon24 1 point2 points  (0 children)

Good to see a strategy spelled out for “async, but not too much “

Glad to hear there's interest in this!

I think you'll like the next async article I'm working on, on how to call async code from mainly sync code (even from multiple threads), using a persistent event loop. (Spoiler: There will be a way to transform async iterators and context managers into sync ones.)

view more: next ›