profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/christianbundy/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

christianbundy/best-freelance-contract 17

The best freelance contract.

ahdinosaur/require-style 4

require modules that target css in electron or the browser

christianbundy/2048-AI 2

A simple AI for 2048

christianbundy/atom-dark-flat-ui 1

The default dark ui theme for Atom

christianbundy/1-Two 0

Translate numbers to words in PHP.

christianbundy/2048.cpp 0

🎮 Terminal version of the game "2048" written in C++ 11

christianbundy/42 0

An npm package that returns 42.

christianbundy/aaronson-oracle 0

Press the 'f' and 'd' keys randomly. It's easy. Just use your "free will."

christianbundy/accounts-entry 0

Meteor sign up and sign in pages

christianbundy/acidlisp 0

a lisp that compile to web assembly

PullRequestReviewEvent

issue commentgetsentry/sentry-cli

sentry-cli releases --clear not removing commits

Cool, thank you!

christianbundy

comment created time in 3 days

issue commentsamuelcolvin/pydantic

`pydantic-mypy` plugin is incompatible with `pyproject.toml` config in `mypy>0.900`

Thanks, really excited to see this released.

jrwalk

comment created time in 4 days

issue commentgetsentry/sentry-cli

sentry-cli releases --clear not removing commits

Anything I can do to help move this forward?

I've had a ticket open with Sentry support and they've told me that I'll receive support via this GitHub issue instead (?).

If it helps, I've also used curl to replicate this problem, so I think you're right that the API is misbehaving and it's not just he CLI.

christianbundy

comment created time in 7 days

issue commenthadolint/hadolint

GitHub tag out of sync with DockerHub image in pre-commit config

It's fixed in the default branch (https://github.com/hadolint/hadolint/pull/698), but it looks to me like your version bump commit (https://github.com/hadolint/hadolint/commit/3e13ec6fa67a42fc3be93b85caf2d1451fd1f983) is a manual process.

christianbundy

comment created time in 7 days

issue openedhadolint/hadolint

GitHub tag out of sync with DockerHub image in pre-commit config

  • [x] This is a bug report
  • [ ] This is a feature request
  • [ ] I searched existing issues before opening this one

Expected behavior

pre-commit config in v2.7.0 tag should reference v2.7.0 on DockerHub

Actual behavior

pre-commit config in v2.7.0 tag references v2.6.1 on DockerHub

When you release 2.7.1 would you be able to bump the version in the pre-commit config as well please?

Steps to reproduce the behavior

N/A

Additional environment details (OS, stack version, etc.)

created time in 7 days

issue openedpython/mypy

Implicit instantiation of exceptions with `raise`

<!-- If you're new to mypy and you're not sure whether what you're experiencing is a mypy bug, please see the "Question and Help" form instead. -->

Bug Report

<!-- Note: If the problem you are reporting is about a specific library function, then the typeshed tracker is better suited for this report: https://github.com/python/typeshed/issues -->

Python seems to treat raise ValueError the same way as raise ValueError(), with implicit instantiation, but Mypy doesn't seem to have the same behavior.

To Reproduce

  1. Define subclass of Exception where __init__ has mandatory arguments
  2. raise SomeException
class SomeException(Exception):
    thing: str
    
    def __init__(self, thing: str) -> None:
        self.thing = thing

    def __str__(self) -> str:
        return f"There's a {self.thing} in my boot"
        
# BUG: Mypy does not see this problem.
def a() -> None:
    raise SomeException
    
# Correct: Mypy identifies the problem.
def b() -> None:
    raise SomeException()
    
# Correct: Mypy identifies that there is no problem here.
def c() -> None:
    raise SomeException(thing="snake")

https://mypy-play.net/?mypy=latest&python=3.10&gist=158348310d55f703fc05bacde65af438

Expected Behavior

This should throw an error about missing mandatory arguments.

Actual Behavior

No error.

(Write what happened.)

Your Environment

<!-- Include as many relevant details about the environment you experienced the bug in -->

  • Mypy version used: 0.910
  • Mypy command-line flags: None
  • Mypy configuration options from mypy.ini (and other config files): None
  • Python version used: 3.10
  • Operating system and version: N/A

created time in 7 days

issue openedtypeddjango/django-stubs

Custom manager causes phantom errors and sometimes crash

Bug report

<!-- Hi, thanks for submitting a bug. We appreciate that.

But, we will need some information about what's wrong to help you. -->

What's wrong

Still working on a minimal repro, but here's my stack trace:

Traceback (most recent call last):
  File "/.venv/bin/mypy", line 8, in <module>
    sys.exit(console_entry())
  File "/.venv/lib/python3.9/site-packages/mypy/__main__.py", line 11, in console_entry
    main(None, sys.stdout, sys.stderr)
  File "mypy/main.py", line 87, in main
  File "mypy/main.py", line 165, in run_build
  File "mypy/build.py", line 179, in build
  File "mypy/build.py", line 229, in _build
  File "mypy/build.py", line 475, in load_plugins
  File "mypy/build.py", line 425, in load_plugins_from_config
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 850, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/.venv/lib/python3.9/site-packages/mypy_django_plugin/main.py", line 8, in <module>
    from django.db.models.fields.related import RelatedField
  File "/.venv/lib/python3.9/site-packages/django/db/models/__init__.py", line 5, in <module>
    from django.db.models.constraints import *  # NOQA
  File "/.venv/lib/python3.9/site-packages/django/db/models/constraints.py", line 4, in <module>
    from django.db.models.sql.query import Query
  File "/.venv/lib/python3.9/site-packages/django/db/models/sql/__init__.py", line 3, in <module>
    from django.db.models.sql.subqueries import *  # NOQA
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 846, in exec_module
  File "<frozen importlib._bootstrap_external>", line 935, in get_code
  File "<frozen importlib._bootstrap_external>", line 1079, in path_stats
  File "<frozen importlib._bootstrap_external>", line 142, in _path_stat

I have a FooManager:

from django.db import models

class FooManager(models.Manager):

    def create_with_foo(self, *args, **kwargs) -> models.Model: # Line 7
        pass

    def save_foo(self, model: models.Model) -> None: # Line 25
        pass

It's often used on models like this:

objects = FooManager.from_queryset(BarQuerySet)()

For some reason, three completely unrelated files are getting these errors:

some_file.py:7: error: Name "models" is not defined  [name-defined]
    )
    ^
some_file.py:25: error: Name "models" is not defined  [name-defined]
            does_not_matter_anything_could_be_here()

I tried adding whitespace to the top of some_file.py but the line numbers didn't change. Odd. I looked through my project for files where lines 7 and 25 referenced models and found my FooManager. I added 1 line to the top of FooManager and the mypy errors incremented by 1. I added 100 lines to the top of FooManager and got this sweet stack trace.

How is that should be

There should be no errors.

System information

  • OS:
  • python version: 3.9.6
  • django version: 3.1
  • mypy version: 0.910
  • django-stubs version: 1.8.0
  • django-stubs-ext version: 0.3.1

created time in 9 days

issue commentpython/mypy

Did Travis die?

I can maybe take a look at this in the next week or so.

hauntsaninja

comment created time in 10 days

issue commentgetsentry/sentry-cli

sentry-cli releases --clear not removing commits

The real problem I'm trying to solve: I'm trying to backfill historical releases with commit metadata, and while the local command succeeds and tells me that it's associating commits... nothing shows up in the web UI. I thought maybe the UI was querying a replica with high latency, but it's been 24+ hours.

My hunch is that maybe the problem is caused by a few releases that I have which somehow have thousands of commits associated. Maybe a commit can only be associated with 1 release at a time? So I've tried to clear all commits from all releases to workaround this potential problem, but then I'm bumping into this bug.

My script, FWIW:

#!/usr/bin/env bash

set -eou pipefail

 for commit_id in $(< commit-list); do
     git reset --hard $commit_id
     sentry-cli releases set-commits --clear $commit_id
done

for commit_id in $(< commit-list); do
    git reset --hard $commit_id
    sentry-cli releases set-commits --auto $commit_id --ignore-empty --ignore-missing
done
christianbundy

comment created time in 11 days

issue openedgetsentry/sentry-cli

sentry-cli releases --clear not removing commits

Environment

SaaS (https://sentry.io/)

Version

1.68.0

Steps to Reproduce

  1. sentry-cli releases set-commits "$VERSION" --clear
  2. See "Clearing commits for release" output
  3. Go to release page for $VERSION on sentry.io

Expected Result

Commits are no longer associated.

Actual Result

Commits are still associated. Maybe the bug is caused by the ridiculous number of commits associated with this release? (Trying to enable 'suspect commits' and this single-commit release got thousands of commits accidentally associated.)

image

created time in 11 days

issue commentgetsentry/sentry

sentry-cli releases --clear not removing commits

Oh, I meant to open this in sentry-cli -- could I have this issue moved please?

Also, I've found another reference to the problem: https://github.com/getsentry/sentry-cli/issues/956#issuecomment-844396942

christianbundy

comment created time in 11 days

issue openedgetsentry/sentry

sentry-cli releases --clear not removing commits

Environment

SaaS (https://sentry.io/)

Version

1.68.0

Steps to Reproduce

  1. sentry-cli releases set-commits "$VERSION" --clear
  2. See "Clearing commits for release" output
  3. Go to release page for $VERSION on sentry.io

Expected Result

Commits are no longer associated.

Actual Result

Commits are still associated. Maybe the bug is caused by the ridiculous number of commits associated with this release? (Trying to enable 'suspect commits' and this single-commit release got thousands of commits accidentally associated.)

image

created time in 11 days

issue commenttypeddjango/django-stubs

mypy crashes with `TypeError: Object of type AnyType is not JSON serializable`

@kalekseev That isn't triggering the error for me. Are there any other ways you've been able to reproduce this? I'd love to throw a minimal repro into a test so that we can try to fix it.

kalekseev

comment created time in 12 days

issue commentpython/mypy

Release 0.910 planning

There have been ~180 commits since this release, is there anything I can do to help get another release cut?

(Apologies for the necro-bump, I was going to make a new issue but the issue template says not to make issues for questions.)

JukkaL

comment created time in 12 days

pull request commentsamuelcolvin/pydantic

Replace TypeVarDef with TypeVarType

Just pushed a commit that's passing mypy@master, but I'm still getting three errors on mypy@0.910:

pydantic/mypy.py:354: error: Too many arguments for "TypeVarType"  [call-arg]
pydantic/mypy.py:354: error: Argument 1 to "TypeVarType" has incompatible type "str"; expected "TypeVarDef"  [arg-type]
pydantic/mypy.py:654: error: List item 0 has incompatible type "TypeVarType"; expected "TypeVarLikeDef"  [list-item]

When the new version of Mypy comes out will we need to make a major version bump for this breaking change? I'm worried that this new usage of TypeVarType works on new versions of Mypy, but old versions of Mypy seem to have different behavior.

christianbundy

comment created time in 12 days

push eventchristianbundy/pydantic

Christian Bundy

commit sha 180a9a758957d641564796bd2192baf362f8c4b6

Fix type error from mypy@latest

view details

push time in 12 days

pull request commentsamuelcolvin/pydantic

Replace TypeVarDef with TypeVarType

Looks like maybe this is failing tests? :/

I think the behavior of TypeVarType changed between 0.910 and master, so I'm unsure how we could support both.

christianbundy

comment created time in 12 days

push eventchristianbundy/pydantic

Christian Bundy

commit sha 2b1818b4920abbcf159a45d69d8bad469a33ec6b

Replace TypeVarDef with TypeVarType Problem: While using the Pydantic plugin with bleeding-edge Mypy I realized that Pydantic is using a recently-removed type. Solution: Find two instances of `TypeVarDef` and rename to `TypeVarType`. See-also: https://github.com/python/mypy/pull/9951

view details

push time in 12 days

PR opened samuelcolvin/pydantic

Replace TypeVarDef with TypeVarType

<!-- Thank you for your contribution! --> <!-- Unless your change is trivial, please create an issue to discuss the change before creating a PR --> <!-- See https://pydantic-docs.helpmanual.io/contributing/ for help on Contributing -->

Change Summary

Problem: While using the Pydantic plugin with bleeding-edge Mypy I realized that Pydantic is using a recently-removed type.

Solution: Find two instances of TypeVarDef and rename to TypeVarType.

See-also: https://github.com/python/mypy/pull/9951

Related issue number

N/A

Checklist

  • [ ] Unit tests for the changes exist
  • [ ] Tests pass on CI and coverage remains at 100%
  • [ ] Documentation reflects the changes where applicable
  • [ ] changes/<pull request or issue id>-<github username>.md file added describing change (see changes/README.md for details)
  • [ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers
+2 -3

0 comment

1 changed file

pr created time in 12 days

create barnchchristianbundy/pydantic

branch : christian/type-var-def

created branch time in 12 days

fork christianbundy/pydantic

Data parsing and validation using Python type hints

https://pydantic-docs.helpmanual.io/

fork in 12 days

issue commenttypeddjango/django-stubs

mypy crashes with `TypeError: Object of type AnyType is not JSON serializable`

Thanks! I think the bug is happening during cache write, not cache read, so I had to use --cache-dir=/dev/null instead.

kalekseev

comment created time in 12 days

issue commenttypeddjango/django-stubs

mypy crashes with `TypeError: Object of type AnyType is not JSON serializable`

Confirming the bug here too. Any ideas for a workaround?

kalekseev

comment created time in 12 days

issue commenttypeddjango/django-stubs

Release 1.9 version which supports Django 3.2 (LTS version)

‼️ Thanks so much, upgrading to 1.9.0 now.

DmytroLitvinov

comment created time in 13 days

issue commenttypeddjango/django-stubs

Release 1.9 version which supports Django 3.2 (LTS version)

Is there any chance of getting a release before #608 is resolved? There have been 74 commits since 1.8.0 and I'd love to be able to deploy those without pulling directly from GitHub.

DmytroLitvinov

comment created time in 14 days

issue openedtypeddjango/django-stubs

TypeError: basic_new_typeinfo() missing required argument 'line' (pos 3)

Bug report

<!-- Hi, thanks for submitting a bug. We appreciate that.

But, we will need some information about what's wrong to help you. -->

What's wrong

Traceback (most recent call last):
  File "mypy/semanal.py", line 4872, in accept
  File "mypy/nodes.py", line 1073, in accept
  File "mypy/semanal.py", line 2023, in visit_assignment_stmt
  File "mypy/semanal.py", line 2278, in apply_dynamic_class_hook
  File "/.venv/lib/python3.9/site-packages/mypy_django_plugin/transformers/managers.py", line 22, in create_new_manager_class_from_from_queryset_method
    new_manager_info = semanal_api.basic_new_typeinfo(
TypeError: basic_new_typeinfo() missing required argument 'line' (pos 3)

System information

  • OS:
  • python version: 3.9.6
  • django version: 3.1
  • mypy version: 0.910
  • django-stubs version: 1.8.0

created time in 14 days

issue commentasottile/pyupgrade

TypeError: unsupported operand type(s)

keep this exclusively

remove the rewrite

I think either would be fine, and I appreciate the quick fix! I think an --maybe-dangerous flag, or similar, would also do the trick, but that adds complexity to the API.

christianbundy

comment created time in 18 days

PR opened django/django

Document TEST_MIRROR caveat

Problem: This setting only works in transactions but that isn't documented.

Solution: Add caveat to documentation.

Link: https://code.djangoproject.com/ticket/23718

+2 -1

0 comment

1 changed file

pr created time in 18 days