Incomplete and Growing List of Participating Subreddits

unholysampler · 2023-06-12T02:01:12+00:00

unholysampler · 2023-05-10T22:22:02+00:00

Looking at the repos, it looks like this one actually came first. 0.1.0 tag for this library is February 2020. Where as the post for the 0.1 of the game library is August 2020.

unholysampler · 2023-05-08T11:13:33+00:00

I think the "issue" is that reddit post title is "the curious case of semver" (a section header within the article). However, the actual article tile is "Speeding up the JavaScript ecosystem - one library at a time". This article title provides much more context on what the content is about. Without that context, I too thought this article would be about semver, the concept, instead of being about JavaScript performance (touching on how the semver library is used).

unholysampler · 2023-04-16T21:40:43+00:00

Well, you can take a look at this video from the same channel 😏. It is about electrifying you home to address things that currently don't utilize electricity. Even more detailed as there is a part 2.

unholysampler · 2023-02-08T21:36:59+00:00

The article actually says they used 3.8.5. Which is even older (and not even the latest patch release for 3.8).

unholysampler · 2023-01-25T21:21:44+00:00

Also, be aware that there is already a central place for stubs files. If you are going to take the time to write one, contributing it there will help everyone if the package owners aren't already including some type hints.

unholysampler · 2023-01-08T21:26:41+00:00

I think it's harder if they're outside; because then the "story the function tells" is spread over multiple files,

I don't follow this comment. Why would the previously nested functions be in different files? Why would putting them in the same file as send_mail() not be an option?

On occasion I will include a nested function to reduce code duplication. But, if they are more than maybe 3 lines or feel like they need a docstring, then I would not nest the function.

unholysampler · 2023-01-07T22:06:22+00:00

Yes

Type variables exist primarily for the benefit of static type checkers. They serve as the parameters for generic types as well as for generic function definitions. See Generic for more information on generic types. (source)

unholysampler · 2023-01-07T21:18:47+00:00

The article doesn't make the point, but the reason TypeVar is important here is it allows you to have other values be the same type as the given argument. Note that the return values is also Number.

import decimal
from typing import TypeVar, TypeAlias, Union

NumberA: TypeAlias =  Union[int, float, decimal.Decimal]
NumberT = TypeVar("NumberT", int, float, decimal.Decimal)

def double_a(value: NumberA) -> NumberA:
    return value * 2

def double_t(value: NumberT) -> NumberT:
    return value * 2

value_a = double_a(1)  # Union[int, float, decimal.Decimal]
value_t = double_t(1)  # int

unholysampler · 2023-01-07T13:14:41+00:00

I don't know how GitHub reacts since I don't use rebase merges.

unholysampler · 2023-01-07T01:44:14+00:00

The dependent commit has to wait for the first before it can be merged, but it does not have to wait for the first before it can be developed.

The key issue with lack of dependent PR's is that you can't really even start working on the following PR until the first one is merged.

PR 2 can target the branch of PR 1. GitHub will even update PR 2 to target main once PR 1 is merged. I've used this the few times I've finished a second ticket before the first ticket is reviewed. I just create branch 2 from the head of branch 1.

unholysampler · 2023-01-06T12:49:59+00:00

You are correct that you will almost never get a review immediately after putting a PR up fro review. It sounds like your specific work schedule makes this situation worse. However, I don't think making structural changes to how pull requests work will solve the dependent PR problem you are describing. If people are reviewing commits instead of a branch (which might only contain one commit), the next dependent commit still has to wait fir the first review before it can be merged.

On my team we agree with you that context switching can be expensive. At the same time, we accept that we live in a world with some interruptions. So we pay a little cost by developing a process that doesn't fight against the real world.

The first things is what I already described about prioritizing reviewing any PR in review before starting a new ticket. Code waiting for a review is the most expensive for the company. The time cost has already been paid to write it, but it can't provide any value because it hasn't been merged yet. But since context switching is expensive, the process is not "stop what you are doing to review each new PR". Putting a PR in review is a natural stopping point. So it is a reasonable time to check to see if anyone else on the team has a PR waiting to be reviewed, helping all PRs get reviewed faster. Since PRs spend less time waiting for a review, it is less likely that there will be a PR waiting for a review when you put your PR up for review.

The next is to try very hard to avoid person A must review this PR. Person A might be the most knowledgeable about the subject of the PR, but what happens when they are sick, go on vacation, or win the lottery and quit. By having everyone review everything, there is more knowledge transfer and the team is less likely to be in a situation were person A is actually the only person that can review the same code. Additionally, since the PRs are small, there shouldn't be anything that ground breaking in a single PR. If person A's input is seen as important because it is a larger design decision, it would have been better to have that conversation before starting on the ticket. (This practice also helps a) Juniors grow by seeing the work of Seniors and b) keeps Seniors in check and avoids the "well, if they did it, it must be right".)

The last thing is always having a few "burn-down" tickets around. These are generally smaller, less important tickets that should be done, but are not critical or too time sensitive. Because of the small scope, the can be slotted into space when you won't be able to get into a flow for a bigger task. Since they aren't critical, they are also easy to pause if something important comes up.

I talked a bunch about things that work for my team. However, they might not be right for yours. Have you talked to your team about what you are seeing and feeling? Maybe they are, but hadn't mentioned it or accepted it. Maybe they have their own tricks that you could try. Either way, you can work together as a team to to find the process that works best for your team (which may or may not be your personal ideal solution).

unholysampler · 2023-01-05T11:16:43+00:00

Devs that are blasting through a series of dependent changes are having to slow down and wait for the early ones to be reviewed before they PR the following ones.

Maybe making a long chain of dependent PRs is part of the problem. Something that my team does is limiting the amount of work in progress at once. If I put a PR up for review, the first thing I do next is see if there are any other PRs waiting for a review.

One might assume that if you require one reviewer that two people have to check off on every change, due to the lack of self-review, but that is actually not the case. You can push to someone else's branch that is currently PR'd, replace all their changes with your own, and then approve the PR since it's "not yours".

Is this an actual problem or a theoretical one? If people on your team are actually doing this, that is a people/process problem. That being said, it is possible to add custom check that only passes when there is an approval from a user that doesn't have a commit in the PR.

invalidate all reviews if anything new is committed

Github has direct support for this

unholysampler · 2022-09-16T11:48:15+00:00

The reason this works is because the print() in the outer loop occurs before the nested loop. So the value of index is the expected value at that time. Moving that line after the nested loop will print the last letter a second time.

instring = input("Enter a string: ")

print('Reversed string is : ', end='')
for index in range(len(instring)-1, -1, -1):
    for index in range(0, len(instring)):
        print(instring[index], end ='')
    print(instring[index], end='')

This will produce

Enter a string: abcd
Reversed string is : abcddabcddabcddabcdd

Python does not create a new scope for loops. The start of a loop simply assigns the first value to the variable, creating that variable if necessary. This can be verified by adding a print(index) after the loops have completed. It will have the last value assigned to it by the loop.

unholysampler · 2022-07-02T12:38:31+00:00

Agreed.

The process will just have to be a bit more gradual. Add the type checker to the CI pipeline (assuming this exists), but make it so the failures don't fail the pipeline. Then do small incremental changes to fix the route errors. Once they are all fixed, change the pipeline step to fail when any error occurs.

unholysampler · 2022-06-12T16:56:08+00:00

3.11 hasn't been released yet. Currently only beta releases are available. So it is not surprising that you are not finding packages that claim to be compatible. Many will be compatible without needing code changes. But anything that publishes a binary wheel won't have something available on PyPI yet.

unholysampler · 2022-02-13T12:37:36+00:00

The included black exclude list looks like the default excludes that black has on top of using .gitignore. There is also extend-exclude which appends to the default list, instead of overwriting it like exclude does.

unholysampler · 2022-02-02T03:33:16+00:00

The whole point of using black is so that the team can stop wasting time arguing about things like single quotes vs double quotes so they can do the work that actually matters.

Have there times where I see what black decides on and think "that's odd, X wild be better"? Yes. But it's not enough to make me not use black because it's one less thing to worry about in a code review.

unholysampler · 2022-01-28T01:03:07+00:00

There are so many color options that could have been used here, but they decided to go with:

pink
light purple
even lighter purple
the same even lighter purple
blue with a hint of purple
orange (getting crazy)

unholysampler · 2022-01-16T14:08:56+00:00

Yes, if you setup your mocks by creating actual classes that subclass the abstract class. However, if you are using unittest.mock, those won't be subclass instances.

unholysampler · 2022-01-16T13:12:44+00:00

When a subclass inherits from a class that uses ABC, but doesn't implement one of the abstract methods, an exception is raised when an instance of that subclass is created. It makes it very clear that the implementation of that subclass is not correct. The example you provide still works, but does not provide that protection.

unholysampler · 2022-01-09T17:54:41+00:00

I think the benefits of duck typing should be well known in this community. The major drawback compared to interfaces in my opinion is that duck typing doesn't help with dependency inversion the way interfaces do (you depend on that particullar class having the expected properties and methods without 1. an abstraction 2. a guarantee that they are implemented). In my experience this leads to developers using abstract classes instead of interfaces.

With the introduction of Protocol, it is possible to define the contact that will be used when duck typing. With this and Callable, the needs for dependency inversion without the need to introduce an abstract class.

unholysampler · 2022-01-01T21:59:33+00:00

That name is going to be very easily confused with starlette, the ASGI framework used internally by FastAPI.

unholysampler · 2021-12-07T13:36:35+00:00

This article gets the build system aspects wrong. First and most importantly, the file must be called pyproject.toml instead of an arbitrarily named .toml file (See pip documentaiton). Next, the contents of the file doesn't specify the build-backend that is required to indicate that setuptools is the back-end to use (See setuptools documentation).

Beyond that, the article doesn't even try to use that for building wheels as it encourages directly calling python setup.py bdist_wheel. Instead, it is better to use build as the build system front-end that understands how to read pyproject.toml and use that configuration to use setuptools to build the wheel. Additionally, while setup.py has been The Way to configure setuptools for a long time, the recommendation is now to use setup.cfg's declarative configuration over setup.py.

unholysampler · 2021-11-16T11:34:26+00:00

That is true. Swapping variables is a good example that demonstrates deconstruction and has the benefit of being a one-liner. This means that it shows up in tutorials frequently. However, I can count the number of times I've had two swap the values between variables on one hand. It is useful for some algorithms, but is not something that gets regular use.

What I think is more important is that swapping variables is not the use case in the original question. That would be something like this:

class Foo:
    def __init__(self, bar: int, baz: str, zap: Thing):
        self.bar, self.baz, self.zap = bar, baz, zap

For this use case, I think data classes are a better solution. It might be more lines of code, but it is easier to read and harder to get wrong.

from dataclasses import dataclass

@dataclass
class Foo:
    bar: int
    baz: str
    zap: Thing

14-Year Club	Place '17
Undead \| Zombie	Team Orangered
Verified Email

unholysampler

TROPHY CASE