[–] [S] 2 points 2 months ago* (last edited 2 months ago) (2 children)

Sure, but a lot of people incorrectly think the __eq__ and __hash__ are defined based on value not identity, as they are for many other types say float, str, or tuple. But for a class the default __eq__ method is x is y instead of x == y and also __hash__ is based on identity.

Others assume that if you don't define __hash__ for a class, that it doesn't exists (like for list, set, or dict) so that a "TypeError: unhashable type: 'Value'" exception is raised.

I thought it was an interesting exercise to share, but maybe too simple for this audience, or people are just not aware of the basic steps that happen when adding and searching values in a set/dict. Try the same with type int:

v1 = 1001
v2 = 1002
myset = {v1}
print(v1 in myset, end=' ')
v2 = 1001
print(v2 in myset, end=' ')
v1 = 1002
print(v1 in myset, end=' ')

and you see a different output. To do the same with the Value class add methods:

def __eq__(self, other):
    return self.value == other.value

def __hash__(self):
    return hash(self.value)
  • source
  • parent
  • context
  • [–] 4 points 2 months ago (3 children)

    That's a very complicated way to explain it though.

    1. You basically create two object instances
    2. You then put one of those instances in a variable
    3. No matter what you do to those instances, you don't change the fact of #2.

    It's like putting your friend Sarah on a bike and then giving her Christina's jacket. You haven't changed the fact that Sarah is on the bike and Christina isn't.

  • source
  • [–] 2 points 2 months ago (1 child)

    Often, you must wait a bit for libraries you depend on to support it. First, numpy has to work, then matplotlib a month or two later, then pandas, etc. If you depend on an obscure package or two, you have to wait for basically one guy to learn the new stuff, otherwise they'll pull your whole dependency tree back.

  • source
  • parent
  • context
  • [–] 2 points 3 months ago (2 children)

    lazy imports -- ftw!

    built-in sentinel -- finally

    I'm confused once py315 comes out why to stick with any previous version. As author of multiple packages, why would wait for several years before getting the benefits of lazy imports? This is not a rhetorical question, i'm requesting feedback why would you continue to wait?

    This point is not clear to me.

  • source
  • [–] 1 point 3 months ago

    I don't think you can overwrite files, it was more intended so you can rebuild wheel files against a newer version of python, without having to create a new release.

    e.g. you've built and uploaded: myapp-1.0.0-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl, and then after python 3.14 released you can rebuild your release outputting: myapp-1.0.0-cp314-cp314-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

    Though it's usually only for projects that contain non-python code. Most projects will build into: myapp-1.0.0-py3-none-any.whl.

  • source
  • parent
  • context
  • Remember back in the day ... raw SQL. All the children in unison say, "Woah"!

    There is no avoiding the database part: model module, alembic migrations, static type checking, UDF, UDF rtyping, string PRAGMAs/SET|SHOW. And a beautiful config file to link them all!

    Database work is very time consuming.

    have to reevaluate if async is that important to me or not.

    Why would be concerning yourself about that? Should have both [a]sync support throughout. Discussing this shouldn't even be a topic it should be the norm.

  • source
  • parent
  • context
  • why no one is talking about Django is just rhetorical clickbait title to start a conversation about Django. You are interpreting it literally.

    Once the topic of Django is discussed, may lead into the conversation about SQLAlchemy. Then comparing the two. Then complaining about one or the other.

    Doubt there will be anyone experienced in both. I can talk about SQLAlchemy, but keep my mouth shut about Django. So enjoy to hear what others have to say about Django.

    Let them speak!

  • source
  • parent
  • context
  • [–] 1 point 3 months ago* (last edited 3 months ago)

    Reply to /u/onlinepersona SQLAlchemy crocodile tears.

    Really need a layer between SQLAlchemy and FastAPI (or litestar, ...). Otherwise would be messing around with SQLAlchemy/alembic internals for years. SQLAlchemy is an incredible time sink without that additional layer.

    Created just such a package just never got around to publishing it:

    • static type checking throughout
    • sync and async support throughout
    • alembic support (both async and sync)
    • multiple databases. One per config file!
    • model built from dotted path of (sqlmodel and sqla mixins) components module
    • UDF (user defined functions)
    • database settings (PRAGMA, SHOW, SET, ...)
    • sqlite-[pysqlite|sqlcipher|aiosqlite] and postgresql-[psycopg2|asyncpg] supported
    • config does not store the password

    Issues:

    • retire sqlite-sqlcipher PRAGMA rekey and key. Password in config unsafe
    • authentication by pulling from a password manager not implemented
    • strict validation of postgresql SHOW/SET keys incomplete
  • source
  • parent
  • context
  • [–] [S] 1 point 4 months ago

    What is this "rendering system"?

    Basically, it's a TUI library for getting user input. It has different types of prompts, like text and multiple choice.

    Is it optional or mandatory?

    For use with Package A: Optional. However with Package AB: Mandatory, as this compatibility package would essentially replace certain functions in Package B.

    Why not put the compatibility layer/class/thing inside Package A?

    I don't want Package A having Package B as a dependency when it's not being used. I only want Package B as a dependency when using Package A with Package B (AB).

  • source
  • parent
  • context
  • [–] 1 point 4 months ago (2 children)

    My personal convention in C++ was to use an m prefix on member variables and a g for class variables.

    I guess in Python, I think of _ as equivalent to protected scope in C++ and __ (double underscore) as equivalent to private. Not a perfect analogy, but it works for me.

  • source
  • parent
  • context
  • [–] 2 points 4 months ago (4 children)

    Coming from C++, I initially thought it aggravating that you have to go self. everywhere when working with classes in Python. But I've conceded that it improves code-legibility, and now I'm going this-> everywhere when I'm back in C++.

  • source
  • [–] 2 points 4 months ago (1 child)

    SQLalchemy is horrible, IMO. You have to read so much of its documentation to get a grip on things. And the backwards compatible changes they made while moving to (I think) SQLAlchemy2 make it terribly difficult to tell apart the API. And type hints were an abomination to deal with when they tried adding them (it's better now).

    And don't get me started on migrations with alembic.

    I wish the Django ORM could be extracted from Django and used in other projects, but then I also just want to go back to Django.

  • source
  • parent
  • context
  • [–] 2 points 4 months ago* (last edited 4 months ago) (2 children)

    There is simply nothing better in my opinion.

    Possibly SQLalchemy? But yeah, it's quite good, and there are ways you can bypass the Django ORM and write your own SQL in the cases where it's suboptimal. I've only had to do that a very small number of times during the 20-plus years I've been using Django (I was an early adopter, left Zope like a .38 round leaves a gun).

    It also helps that I have some decent SQL optimization skills: when I was doing consulting, I triggered the resignations of two client DBAs because they insisted that there was no way to significantly improve a query's performance, then I did it. Stupid hill to die on, all they had to have done was to have said "OK, let's prototype it and see" instead of getting all dogmatic about it. Ego's a dangerous thing in software development.

  • source
  • parent
  • context
  • view more: β€Ή prev next β€Ί