575 karma · joined February 20, 2019
With Python, you can run your program under pdb, which will automatically enter break on exceptions, and you can easily print locals.
- It took me a while to find the Metadata tab to edit a request's name, I guess because I don't think of the name and description as metadata (even if in a technical sense they are, relative to the request config). My inclination would be to make this the first tab and rename it to Info.
- I somehow managed to save two requests into the same file with no warning/confirmation from the UI.
- When using the up/down arrows to navigate between requests in a collection, I found it counterintuitive to have to hit Enter to actually select the request.
If I was looking to start a band today, I'd definitely give this kind of thing a try.
I use Poetry for all my projects, but I agree that it exacerbates the issue somewhat with its default npm-style version syntax.
I assume the same is true of the other checks Lighthouse does for performance, best practices, etc.
Lighthouse and other such tools are a good starting point, and using them is better than doing nothing, but a thorough understanding of accessibility etc is necessary to create truly accessible and performant sites.
When I embraced formatters, I started spending so much less time and effort keeping the style "correct" and worrying about how other people on the team format code. I love just hitting save in my editor and having the code formatted without having to fiddle with quotes, wrapping, etc.
With regard to bike-shedding about style, it mostly goes away once a team adopts one of the standard formatters for a given language. That's sort of the whole point.
The idea that having cameras on will convey body language like in person conversations seems patently false, partly because of the above and partly because most people moderate their expressions to an extreme while on camera.
I've also temporarily quit nicotine and caffeine when I got sick, and I think part of the reason is that the withdrawal effects are less noticeable and/or maybe you attribute them to the illness. Also, if you get sick enough to take time off from work, that tends to coincide with the worst withdrawal effects, which last about three days in my experience.
Unless you were intending this as a criticism of .NET?
I could see WASM actually pulling this off.
I spent quite a bit of time trying to understand the distinction between these options and when you would choose one over the other, and I would have to disagree that it's a no-brainer choice. Perhaps if you've been in the .NET ecosystem for years and have followed the changes but definitely not if you're new to it.
Besides, all the common languages we use now, whether or old or new, have all gone through a phase like this. I bet people made similar commentary about C back in the day too.
Additionally, there are reasons given in the linked issue. I guess you could debate about whether they're good reasons (they sound reasonable to me), but you can't say they're proposing it for no reason just because you don't like or agree with the reasons.
To that point, as someone who learned a decent amount of C and C++ a long time ago, I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance.
And to be clear, I'm not bashing C/C++ at all. They're venerable and appreciated, but I have little to no interest in working with them, and it seems to me that this is a fairly common sentiment.
EDIT: Thinking about this some more, doing `brew install pipx` would keep pipx from breaking on brew upgrades, but I guess your installed scripts would still fail if you upgrade from Python 3.N to 3.N+1.
So the only solution, I think, is to keep around all the versions of Python you use, assuming you don't want to upgrade all your scripts when upgrading Python.
I use pyenv to manage Python versions rather than Homebrew, and this seems to avoid the issues you're having, because the Python version used to install whichever tool via pipx sticks around until I explicitly uninstall it.
<name>/
pyproject.toml
<name>.py
[tool.poetry]
# NOTE: Set <name> to your project name
name = "<name>"
description = "My Script"
version = "0.0.0"
authors = ["Me <me@example.com>"]
[tool.poetry.dependencies]
python = "^3.11"
requests = "^2.28.2"
[tool.poetry.scripts]
# NOTE: Change <name> to match your package name in [tool.poetry]
<name> = "<name>:main"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
As to the question of whether you should ever use pip to install packages globally, the answer is almost always no. For command line tools, the best option IMO is pipx. The second best option is pip install --user.
If you're developing a library or application, you should always isolate it in a virtualenv, which is something poetry will handle for you when you run `poetry install`.
utf8_bytes: bytes = bytes(input_string, encoding="utf-8")
# Perform the conversion from one encoding to the other.
unicode_string: str = str(utf8_bytes, encoding="utf-8")
ascii_bytes: bytes = bytes(unicode_string, encoding="ascii")
# The conversion could also be written as:
ascii_bytes: bytes = utf8_bytes.decode("utf-8").encode("ascii")
output_string: str = str(ascii_bytes, encoding="ascii")
Perhaps a convenience method would be nice, something like this, but it somewhat obscures the intermediate decode-to-unicode step:
ascii_bytes: bytes = utf8_bytes.convert(to_encoding="ascii")https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...
A simplistic summary is that you always decode to unicode and always encode to bytes.
Another way to think about it is that Unicode is an idealized character model that is reified into a byte encoding, usually UTF-8, for practical usage.
It seems to me that this is something a lot of developers don't think too much about until they run into some obscure encoding/decoding issue, but it's kind of a fundamental aspect of programming that's worth spending some time grokking.
https://docs.djangoproject.com/en/4.1/topics/db/managers/#cu...
from django.db.models import Count, Prefetch
from myproject.models import Post, Comment
# This will fetch the 3 posts first and then the comments for those posts
query = Post.objects.prefetch_related(
Prefetch("comments", queryset=Comment.objects.annotate(Count("votes")))
)
posts = query[:3]
You could also get it down to 1 query using SQL. This is one way to do it based on the schema in the article [postgres, not well tested]:
with
latest_posts as (
select * from post limit 3
),
latest_comments as (
select
c.*, count(v.id) as votes
from
comment c
left join
vote v on v.comment_id = c.id
where
c.post_id in (select id from latest_posts)
group by
c.id, c.content
)
select
p.*, json_agg(c)
from
latest_posts p
left join
latest_comments c on c.post_id = p.id
group by
p.id, p.title, p.content
# NOTE: fixed SQL bug noted by @rurabe
To be clear, I'm not anti-ORM and use them all the time, but it really helps to understand SQL well when using them and to know when it's appropriate to switch to SQL.
>>> def f(): None
...
>>> del f
My other comment in this thread is relevant too: https://news.ycombinator.com/item?id=34197904
def func(g_func, a, b):
g_func(a, b)
def scope():
c = "c"
def anon(a, b):
print(a, b, c)
print(id(anon))
return func(anon, "a", "b")
def func(g_func, a, b):
g_func(a, b)
def scope():
# NOTE: The `|a, b|: (...)` syntax is made up
c = "c"
return func(
|a, b|: (
print(a, b, c)
),
"a", "b"
)
Note that the `anon` function in `scope` is only compiled once. You can verify this by copying the first version to a file named `temp.py` and then running `python -m dis temp.py`. You can also run `scope()` twice in a row and see that the same object ID is printed both times.
That said, for purely aesthetic reasons, I would like it if Python had some kind of syntax like version 2, but that's tricky with significant whitespace, and I've never found the lack of such syntax to be particularly limiting in Python.
It's also possible to repair them to some extent. I've taken the body apart to clean it out, and it seems like it'd be easy enough to replace the battery.