text:
Feature question: How do I NOT type check anything for duration of a function

My objective is to add runtime type-checking to a library in https://github.com/ansible/django-ansible-base/pull/191
https://beartype.readthedocs.io/en/latest/faq/#how-do-i-not-type-check-something
To spell this out, I have a test test_hash_serializer_data_difference, and this test calls a method hash_serializer_data. The test passes DATA to this method, which is a dict when an object of some other class was expected.
@nobeartype
def test_hash_serializer_data_difference():
    """Test hashing different data changes the hash"""
    assert hash_serializer_data(DATA, DataSerializer) != hash_serializer_data({**DATA, **{"id": 4567}}, DataSerializer)

That still fails in the call to hash_serializer_data
I didn't write this test. I honestly don't even want to think about what this test does. What is important is that:

I am sure this method hash_serializer_data will call another method which also has type checking
the test is "wrong" passing DATA as a dict, but presumably has some useful means that it is pursuing
I'm left with a solid 9 cases like this, where the test calls are wrong. Even if I might be able to fix this test, the others are very likely unfixable tests.

The docs section I link says:

This the common use case for temporarily blacklisting a callable or class.

This seems consistent with the fact that I did @nobeartype and it still failed, because the test method was allowed to take incorrectly typed args, but the methods the test called are not allowed to do this. I also used the other @no_type_check and got same result.
Request: don't check anything under a context manager
I want to turn off all type checking for an entire test. I still want to run the tests, because presumably, there is a reason someone added them. Turning off type checking for these 9 tests would allow me to turn type checking on for the other 700-some tests in the library.
I think typeguard works for this, see https://github.com/ansible/django-ansible-base/pull/177, @suppress_type_checks seems to ignore type checks globally for the duration of the test.

...wow. This is extraordinarily fascinating. The takeaway is that the real world is brutal, huh? You're just trying to death march through a weekend's worth of open-source crunch without blowing an O-ring. Meanwhile, @beartype is oh-snapping in the air and shooting you down with sassy snark like:

"Oh, no you didn'!"

What I'm trying to say here is that you want to do is understandable – yet non-trivial. Lying to static type-checkers like mypy and pyright is a given; they hallucinate about everything, so users need some means of lying to them. Lying to runtime type-checkers like @beartype is another matter altogether; they mostly don't hallucinate, so users ideally should avoid trying to lie to them. Ideally.
That said... this is the real world. Idealism doesn't matter much when 9 friggin' unit tests lay in a shattered heap of rubber tires that is currently on fire.
Let's start from the beginning.

My objective is to add runtime type-checking to a library in https://github.com/ansible/django-ansible-base/pull/191

:partying_face:

I didn't write this test. I honestly don't even want to think about what this test does.

We've all been there. I too know this gut-wrenching pain. I didn't even get a T-shirt for my agony.

the test is "wrong" passing DATA as a dict, but presumably has some useful means that it is pursuing

...is it, though? "Wrong" is definitely being air-quoted here. The test previously passed. Presumably, the test knew what it was doing back then. If the test otherwise still passes in the absence of runtime type-checking, surely the test still knows what it is doing?
Alternatives to suppressing @beartype at test-time include:

Lightly refactoring the original signature of hash_serializer_data() to unconditionally accept dictionaries as well: e.g.,

from beartype.typing import Dict, Union

def hash_serializer_data(data_arg: Union[SomeClass, Dict[str, object]], ...) -> ...: ...

Lightly refactoring the original signature of hash_serializer_data() to conditionally accept dictionaries only when testing with pytest: e.g.,

from beartype.typing import Dict, Union
from sys import modules

# If tests are currently running, allow tests to pass dictionaries below.
# Else, prohibit dictionaries from being passed below.
DataArgHint = (
    Union[SomeClass, Dict[str, object]] if 'pytest' in modules else SomeClass)

def hash_serializer_data(data_arg: DataArgHint, ...) -> ...: ...

Lightly refactoring hash_serializer_data() to conditionally disable type-checking only when testing with pytest: e.g.,

from beartype import beartype, BeartypeConf, BeartypeStrategy
from beartype.typing import Dict, Union
from sys import modules

# If tests are currently running, disable type-checking; else, don't.
maybebeartype = beartype(conf=BeartypeConf(strategy=(
    BeartypeStrategy.O0 if 'pytest' in modules else BeartypeStrategy.O1)))

@maybebeartype
def hash_serializer_data(data_arg: Union[SomeClass, Dict[str, object]], ...) -> ...: ...

Honestly, I'd go with the second option. You're still runtime type-checking, which is good. You're no longer trying to lie to the runtime type-checker, which is good. You're explicitly declaring exactly what you're doing to the next New Guy™ five cubicles down, which is good.
But let's say you hate all of those things. You will bend @beartype to your iron will! :muscle:

This seems consistent with the fact that I did @nobeartype and it still failed, because the test method was allowed to take incorrectly typed args, but the methods the test called are not allowed to do this. I also used the other @no_type_check and got same result.

Exactly. You've got it exactly. Decorators like @nobeartype and @no_type_check only apply to the exact class or callable being decorated. They don't transitively apply to all other classes or callables called by the class or callable being decorated. Emoji cat cries. :crying_cat_face:
You're actually the first user to request this. You're definitely not wrong to want a "temporarily halt all runtime type-checking for the duration of this context manager, unit test, or whatevahs" button. This is a fascinating (and thus valid) use case. But... @beartype probably can't give you what you want. You're in uncharted and shark-infested waters. Let's wade in with some bloody chum.
The issue, really, is that unit tests aren't isolated. Unit tests all run in the same Python interpreter. It's likely that one or more previously run unit tests in your test suite have already imported the hash_serializer_data() method called by your test_hash_serializer_data_difference() test. If that's not the case now, that could certainly be the case in the future. But the point I'm failing to make is that hash_serializer_data() has already been defined and then presumably redefined by @beartype to perform runtime type-checking.
That's already happened. Now, you want that to unhappen. That's hard. In other words, what you really want is your test_hash_serializer_data_difference() test to:

Dynamically unload the module defining hash_serializer_data(). This is hard. Officially, Python doesn't support module unloading. Unofficially, various frameworks (especially web frameworks like Django) have implemented various ad-hoc "hot module reloading" functionality. Sometimes it works. Sometimes it doesn't. But unloading modules from pytest unit tests in a reliable, robust, and portable manner is basically infeasible. It is a hard conundrum.
Temporarily disable @beartype in your test_hash_serializer_data_difference() test. In theory, this is easy. Just call beartype_this_package(conf=BeartypeConf(strategy=O0)) or whatevahs, right?
Reload the module defining hash_serializer_data() with @beartype disabled. Again, this is easy.

It's the module unloading part that's hard. Icky stuff, honestly. You might temporarily get that to sorta kinda maybe work under various edge cases – but it'll definitely explode when you least expect it at 3:43AM on Friday evening. That's not where you want to be in life.

I think typeguard works for this, see https://github.com/ansible/django-ansible-base/pull/177, @suppress_type_checks seems to ignore type checks globally for the duration of the test.

...heh. I have been educated. You're amazing – and so is typeguard, frankly. I'd actually never heard of @typeguard.suppress_type_checks before. That's a mesmerising API he's conjured up there.
Technically, @beartype could implement a similar API. Pragmatically, @beartype can't. Why? Efficiency. @beartype soft-guarantees pseudo-realtime behaviour with no measurable overhead – or overhead less than ~1µs (i.e., one microsecond, one millionth of a second), which for all intents and purposes means "no measureable overhead." That's an extreme (but extremely valuable) constraint.
typeguard is the exact opposite. typeguard is comparatively much less constrained. typeguard isn't quite as obsessed with efficiency as @beartype, which gives it a lot more leeway to get away with this sort of thing.
Unlike typeguard, @beartype dynamically generates optimally efficient type-checking code at decoration time. Implementing a comparable @beartype.suppress_type_checks API would require that @beartype wrap all generated type-checks in some sort of if conditional detecting whether that type-check should be short-circuited by suppression from a parent test. But 99.99% of users would never short-circuit or enable test suppression. So, that if conditional would just needlessly slow down everyone else in the world for an edge case that nobody ever asked for before.
Still... it's an intriguing idea. If test suppression could (hypothetically speaking) be implemented without impacting non-test performance, that would be a clear win for everyone and something absolutely worth doing.
Let me consider this as I stroke my beard stubble. Still, it's probably best to just repair the test and/or type hint to accurately reflect what's actually going on. :thinking:

There is another place beartype could put the check - in get_hint_object_violation() (or just before calling it). Then regular usage would be unaffected, but illegal calls permitted by this suppression would have the penalty of failing the checks, then continuing. This potential API should probably be rarely used, since it's kinda bad practice to be violating your type hints. So it's probably fine to pay that small penalty.
Alternatively, another approach would be to change the way this feature would function. Instead of suppressing all errors, it'd require you to pass in the specific callable you want to suppress. Beartype would use its internal knowledge to generate a new function which just skips all the type checking. It could then swap out the __code__ value of the function for the duration of this context manager. It might even be possible to share this no-op code object, if the number/ order of closure cells is always the same.

Galaxy Brain @TeamSpen210 for the win. @TeamSpen210, where have you been all my coding life!?!?
I no longer need to think or cogitate or ruminate or ponder the Big Questions™. Instead, I summon @TeamSpen210 into every discussion I'm failing at... somehow. That's the hard part. Summoning @TeamSpen210 is a non-deterministic process. I don't how it happens. The magic, although miraculous, is unreliable at best. Summoning questions include:

Where does @TeamSpen210 come from?
Where does @TeamSpen210 go?
What does "TeamSpen210" even mean?

All these questions will remain unanswered. I beg and I plead. Yet, all I get is @TeamSpen210 spontaneously erupting from the thin membrane that separates worlds and solving everything.
Back to this question before I black out from the excitement.

There is another place beartype could put the check - in get_hint_object_violation() (or just before calling it). Then regular usage would be unaffected, but illegal calls permitted by this suppression would have the penalty of failing the checks, then continuing.

That's... ingenious. How did you think of that? How did you even know what get_hint_object_violation() is? Who are you, really!? I'm pretty sure you're GitHub Batman at this point. Please don't hunt me down. Your identity is safe with me, unless I just publicly disclosed it live on GitHub.
We're agreed this is egregiously clever – but it's also not quite that simple. Okay, it's pretty simple – but I'd better document exactly what I need to do here for my future self when he gets back to this in twelve years. Consider this stupendous example:
from beartype import beartype, BeartypeConf

@beartype(conf=BeartypeConf(is_debug=True))
def i_heart_cats(cat_scratch_fever: str) -> int:
    return cat_scratch_fever

Given that, @beartype currently generates type-checking code that looks something like this: WARNING: this is super-boring.
(line 0001) def i_heart_cats(
(line 0002)     *args,
(line 0003)     __beartype_get_violation=__beartype_get_violation, # is <function get_func_pith_violation at 0x7fbc9b543d80>
(line 0004)     __beartype_conf=__beartype_conf, # is "BeartypeConf(is_debug=True)"
(line 0005)     __beartype_func=__beartype_func, # is <function i_heart_cats at 0x7fbc9b954900>
(line 0006)     **kwargs
(line 0007) ):
(line 0008)     # Localize the number of passed positional arguments for efficiency.
(line 0009)     __beartype_args_len = len(args)
(line 0010)     # Localize this positional or keyword parameter if passed *OR* to the
(line 0011)     # sentinel "__beartype_raise_exception" guaranteed to never be passed.
(line 0012)     __beartype_pith_0 = (
(line 0013)         args[0] if __beartype_args_len > 0 else
(line 0014)         kwargs.get('cat_scratch_fever', __beartype_get_violation)
(line 0015)     )
(line 0016)
(line 0017)     # If this parameter was passed...
(line 0018)     if __beartype_pith_0 is not __beartype_get_violation:
(line 0019)         # Type-check this parameter or return against this type hint.
(line 0020)         if not isinstance(__beartype_pith_0, str):
(line 0021)             __beartype_violation = __beartype_get_violation(
(line 0022)                 func=__beartype_func,
(line 0023)                 conf=__beartype_conf,
(line 0024)                 pith_name='cat_scratch_fever',
(line 0025)                 pith_value=__beartype_pith_0,
(line 0026)             )
(line 0027)
(line 0028)             raise __beartype_violation
(line 0029)     # Call this function with all passed parameters and localize the value
(line 0030)     # returned from this call.
(line 0031)     __beartype_pith_0 = __beartype_func(*args, **kwargs)
(line 0032)
(line 0033)     # Noop required to artificially increase indentation level. Note that
(line 0034)     # CPython implicitly optimizes this conditional away. Isn't that nice?
(line 0035)     if True:
(line 0036)         # Type-check this parameter or return against this type hint.
(line 0037)         if not isinstance(__beartype_pith_0, int):
(line 0038)             __beartype_violation = __beartype_get_violation(
(line 0039)                 func=__beartype_func,
(line 0040)                 conf=__beartype_conf,
(line 0041)                 pith_name='return',
(line 0042)                 pith_value=__beartype_pith_0,
(line 0043)             )
(line 0044)
(line 0045)             raise __beartype_violation
(line 0046)     return __beartype_pith_0

The point to my future self is that the get_hint_object_violation() getter underlying the __beartype_get_violation() calls above unconditionally returns an exception. We have two choices here:

As @TeamSpen210 suggests, we could just avoid calling __beartype_get_violation() entirely when test suppression is enabled. This approach produces elegant code and is definitely what I'd do if this code wasn't dynamically generated. But... this code is dynamically generated. Detecting test suppression from within this code would require unconditionally passing a new "hidden" (i.e., optional unpassed) __beartype_is_suppressed parameter whose value is a is_beartype_suppressed() tester function defined elsewhere. That's kinda awkward. I'm unclear at the moment whether adding hidden parameters to a function marginally increases the time cost of calling that function or space cost of storing that function. I could profile that, but... I'm lazy. It's probably fine. Let's do something else, though. Just 'cause.
As @TeamSpen210 suggests, we could internally refactor get_hint_object_violation() to detect test suppression and respond "accordingly," where "accordingly" means "do something profoundly insane that doesn't make any sense." I like this approach. No new hidden parameters. Only insane and undocumentable behaviour. For example, I could lightly refactor get_hint_object_violation() to return None when test suppression is enabled. This is the way to spaghetti code. Therefore, I will do this.

Since 2. is the way, @beartype will need to generate slightly expanded type-checking code that looks something like this:
(line 0001) def i_heart_cats(
(line 0002)     *args,
(line 0003)     __beartype_get_violation=__beartype_get_violation, # is <function get_func_pith_violation at 0x7fbc9b543d80>
(line 0004)     __beartype_conf=__beartype_conf, # is "BeartypeConf(is_debug=True)"
(line 0005)     __beartype_func=__beartype_func, # is <function i_heart_cats at 0x7fbc9b954900>
(line 0006)     **kwargs
(line 0007) ):
(line 0008)     # Localize the number of passed positional arguments for efficiency.
(line 0009)     __beartype_args_len = len(args)
(line 0010)     # Localize this positional or keyword parameter if passed *OR* to the
(line 0011)     # sentinel "__beartype_raise_exception" guaranteed to never be passed.
(line 0012)     __beartype_pith_0 = (
(line 0013)         args[0] if __beartype_args_len > 0 else
(line 0014)         kwargs.get('cat_scratch_fever', __beartype_get_violation)
(line 0015)     )
(line 0016)
(line 0017)     # If this parameter was passed...
(line 0018)     if __beartype_pith_0 is not __beartype_get_violation:
(line 0019)         # Type-check this parameter or return against this type hint.
(line 0020)         if not isinstance(__beartype_pith_0, str):
(line 0021)             __beartype_violation = __beartype_get_violation(
(line 0022)                 func=__beartype_func,
(line 0023)                 conf=__beartype_conf,
(line 0024)                 pith_name='cat_scratch_fever',
(line 0025)                 pith_value=__beartype_pith_0,
(line 0026)             )
(line 0027)
(line 0028)             # If test suppression is *NOT* currently enabled, raise an exception.  # <-- NEW MADNESS
(line 0029)             if __beartype_violation is not None:
(line 0030)                 raise __beartype_violation
(line 0031)             # Else, test suppression is enabled. In this case, silently ignore this violation.
...

Trivial. No efficiency concerns. Only one new line of generated code. Mild refactoring of get_hint_object_violation(). Sure, there's a bit of steely-eyed madness here. But I for one welcome undocumentable, undebuggable, and unmaintainable refactorings that increase technical debt beyond the event horizon of volunteerism.
Thus, I praise @TeamSpen210. :clap: :full_moon_with_face:

+1 it would be really useful to have this!
I have some unittests to check that a particular incorrect user input to my library will raise a user-friendly error offering specific advice. However, that incorrect user input also violates the type. For example:
        with self.assertRaises(ValueError) as cm:
            PySRRegressor(binary_operators="+")

        self.assertIn(
            "Please pass a list of operators: `[\"+\"]`",
            str(cm.exception),
        )

However, because I have used beartype_this_package() for unit-testing, this test now hits a beartype error instead related to "+" not being a List[str]. The beartype error is correct, although it prevents me from hitting the other error I am unittesting for.
So it would be really nice if there was a simple context manager (maybe bear_spray? :-)) to globally disable type checks, like:
with beartype.bear_spray():
    ... # Do invalid typing stuff, safe from the bear

# The bear comes back out and starts type checking again

which I think should let me test these various error messages in my library PySR.
(Thanks for making this great package @leycec!!)

If efficiency is the main concern I wonder if the BearTypeConf could have an attribute like prime_bear_spray which would "prime" the type checks for being turned off (like during tests) by adding the check for this global parameter to the if statement. So existing code wouldn't be affected at all. Only code that is primed for toggling on/off will have this extra check.

Ho, ho, ho. Merry Necrobump! I've gradually and conveniently forgotten all about ancient centuries-old feature requests like this that surely predate the dawn of GitHub. It's delightful to have them occasionally resurrected with meaningful new discussion. Thanks so much for keeping the dead alive, @MilesCranmer. :zombie:
For your specific use case, though, I wonder if this isn't simply a matter of mis-hinting. That is, your problematic PySRRegressor() function would probably benefit from a mildly more nuanced approach to type hints. By conditionally accounting for the fascinating discrepancies between static type-checkers (e.g., mypy, pyright) and runtime type-checkers (e.g., @beartype, typeguard) that inevitably arise in edge cases like this, you absolutely can have your QA cake and eat its filthy crumbs off the linoleum too: ...5 second rule!
from typing import TYPE_CHECKING

# If a static type-checker (e.g., "mypy", "pyright") is
# currently statically type-checking this submodule,
# prefer the PySRRegressor() function defined below to
# present a simplified API strictly type-checking the
# passed "binary_operators" parameter as a list of strings.
if TYPE_CHECKING:
    _BinaryOperatorsHint = list[str]
# Else, CPython is currently interpreting this submodule
# at runtime. Since a runtime type-checker (e.g.,
# @beartype, "typeguard") *COULD* currently be
# type-checking this submodule at either runtime or
# "pytest"-based test time, prefer the PySRRegressor()
# function defined below to present a more refined API
# fully capturing the range of all runtime behaviours
# supported by that function by permissively
# type-checking the passed "binary_operators" parameter
# as either:
# * A valid list of strings.
# * An invalid string, which that function will then
#   detect and raise a more explanatory message for.
else:
    #FIXME: This assumes Python ≥ 3.10. If you'd like to
    #support Python 3.9 as well, this should then read:
    #    from typing import Union
    #    _BinaryOperatorsHint = Union[list[str], str]
    _BinaryOperatorsHint = list[str] | str

def PySRRegressor(binary_operators: _BinaryOperatorsHint):
    if isinstance(binary_operators, str):
        raise ValueError(
            f'Please pass a list of operators: '
            f'`[{repr(binary_operators)}]`'
        )

    ...

Oh – and Python 3.8 is dead. So you no longer need to explicitly import from beartype.typing import List or from typing import List. The standard list builtin is now directly subscriptable under Python ≥ 3.9. Long live Python 3.9! :partying_face:
The above approach has the demonstrable merits of:

Actually working right now without requiring @leycec to do anything. My laziness has gotta count for something! :sweat_smile:
More accurately capturing the typing dynamics at play in your use case. It only requires a few extra lines of code to do so, too... ignoring that doctoral thesis worth of explanatory comments, which everyone should. :sweat:

Of course, @beartype should still eventually support this feature request. Thankfully...

If efficiency is the main concern...

...efficiency is definitely not a concern here. @TeamSpen210's sagacious life coaching yields a highly performant solution. No, Good Sir. The concern is that I am lazy. Something else always comes up. This issue tracker is always constantly on fire somewhere. It's all I can do to respond to zombified issues like this.
I don't even have any hair left. That's how bad things have gotten. </awkward_moments_on_Github>

The tricky thing about this is that I would still want to have beartype check that type hint turned on for the remainder of the tests.

I must confess that I am dumb and thus fail to understand. Like, is there any discernible difference between either:

@beartype automatically type-checking binary_operators to not be a str (by raising BeartypeCallHintParamViolation if binary_operators is a str)?
PySRRegressor() itself manually type-checking binary_operators to not be a str (by raising ValueError if binary_operators is a str)?

Isn't the type-checking you manually perform even better than the type-checking @beartype automatically performs? The former raises a more readable message than the latter, which was sorta the whole point of you manually type-checking that parameter. Wasn't it? My face is so confused, @AlanCoding. Help @beartype help make sense of this QA madness. :woozy_face:

If I take this approach of expanding the typing hint to list[str] | str at runtime, it would no longer catch such issues.

I... don't get it. Your ValueError exception will continue to be raised, thus catching such issues. Wooziness intensifies. :woozy_face: :woozy_face:

Also if someone turns on a runtime type checker in downstream code, they would also miss this, even though str is invalid (although I suppose they would still hit the ValueError)

That's exactly it! They'd still hit your ValueError. So, no one would ever miss this – even downstream code failing to turn on a runtime type-checker.
Of course, you could always circumvent all of these concerns by just unconditionally calling beartype_this_package() from your {your_package}.__init__ submodule. Or is there some sort of demonstrable concern surrounding @beartype at runtime – like, say, concerns about type-checking overhead, maybe? Honestly, @beartype is bottled lightning. I'd be horrified curious to see whether @beartype tangibly impacted runtime performance at all.
Aaaaaaaand... let's make dinner and pretend this never happened. :yum:

Sorry for being confusing!

@beartype automatically type-checking binary_operators to not be a str (by raising BeartypeCallHintParamViolation if binary_operators is a str)?
PySRRegressor() itself manually type-checking binary_operators to not be a str (by raising ValueError if binary_operators is a str)?

Maybe one point of confusion – I don't actually have @beartype enabled at runtime for downstream users. @beartype is only turned on during unittests.
The ValueError tells the user that they should pass a list of operators (["+"]) rather than the operator itself ("+"). I would like to use a manual argument validation here so that I can give a pretty error message with some tips for how to fix their code. If I were to use @beartype for the error instead, the error message would be: the binary_operators="+" violates type hint str. This is ok for many contexts, but many of PySR's users are complete newbies (for some it's actually their first time programming) and may not even know what a type hint is. So I try to make PySR's error messages pretty basic and actionable, hence why I prefer to manually raise errors for stuff like this.
However, even though I do a lot of manual error handling in PySR, I would still like to use @beartype for the purpose of internal unittesting (for catching dumb internal mistakes). The issue with this is that I can no longer validate the ValueError and error message I described above – I will hit a BeartypeCallHintParamViolation instead, before I can get to the ValueError.

Sure. Totally. I grok all that. Test-time type-checking ala pytest-beartype. That's cool. What I fail to grok, I guess, is why the above snippet doesn't solve all your conundrums. Omitting all of the inline comments that destroy readability, isn't this basically exactly what you want:
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    _BinaryOperatorsHint = list[str]
else:
    _BinaryOperatorsHint = list[str] | str

def PySRRegressor(binary_operators: _BinaryOperatorsHint):
    if isinstance(binary_operators, str):
        raise ValueError(
            f'Please pass a list of operators: '
            f'`[{repr(binary_operators)}]`'
        )

    ...

Have you actually tried that? Is that deficient in some way? Help @beartype help PySRRegressor(). :sob:

Sorry I'm not explaining this well. Yes that patch would eliminate the BeartypeCallHintParamViolation – but it does so globally and for the entirety of test time, rather than locally and only for the single unittest. My aim is to keep the runtime list[str] type hint there for all other tests in case there is a legitimate mistake.

I feel like the next followup question here would be:

Well wouldn't the ValueError then tell you if there was a mistake?

Yes. So at this point I will need to explain that the binary_operators and ValueError is just one example to try to not overcomplicate things. But in reality there are maybe a couple dozen other scenarios like this. And sometimes instead of an explicit error, it will be a warning message with an automatic conversion to the right type. I want to test for those warnings showing up. But I also want to flag violations of type hints outside of the specific tests where I check that a particular warning/error message has been shown to the user.

And sometimes instead of an explicit error, it will be a warning message with an automatic conversion to the right type. I want to test for those warnings showing up. But I also want to flag violations of type hints outside of those tests, since such violations are unexpected.

Ah, ha. Indeed, it all becomes clearer in the crystal ball. I see a dark future for your test suite. :crystal_ball: :fort
However...

(And if they are only warning messages, they wouldn't necessarily fail the test)

Ah, ha! Actually, it's generally advisable to fail tests on any warnings. pytest should probably default to that behaviour out-of-the-box but doesn't, because doing so would break backward compatibility. Still, treating warnings as test failures is really the only sane QA default. If pytest had been created in 2024 (rather than a lot earlier), that would almost certainly have been the default. Indeed, the current pytest default strips essential context and metadata from warnings and is thus largely useless. (See the pytest.ini snippet below for an example of this.)
Thankfully, configuring pytest to fail tests on warnings is trivial. Since this is what the @beartype test suite does, I speak from a place of wisdom and suffering. Just:

Add a new top-level pytest.ini file in the root directory of the GitHub repository hosting your Python package (...if you haven't already).
Add a new filterwarnings = error entry to this file resembling:

# The following pytest-specific section specifier is mandatory, despite this
# file's unambiguous basename of "pytest.ini". One is enraged by bureaucracy!
[pytest]

# Newline-delimited list of all custom warning filters applied by this test
# suite. Recognized strings include:
# * "default", printing the first occurrence of matching warnings for each
#   location (module + line number) where the warning is issued.
#   Unsurprisingly, this is pytest's default. Surprisingly, the resulting
#   output is overly fine-grained to the point of stripping all caller context
#   and thus being mostly useless: e.g.,
#       betse_test/func/sim/solve/test_sim_fast.py::test_cli_sim_fast
#         /usr/lib/python3.7/site-packages/numpy/core/_asarray.py:83:
#         VisibleDeprecationWarning: Creating an ndarray from ragged nested
#         sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays
#         with different lengths or shapes) is deprecated. If you meant to do
#         this, you must specify 'dtype=object' when creating the ndarray
#           return array(a, dtype, copy=False, order=order)
#   Note that pytest reports the warning as originating from within a private
#   NumPy submodule, which it technically does but which communicates no
#   practical meaning with respect to our codebase.
# * "error", turning matching warnings into exceptions. Ideally, pytest would
#   support a filter printing tracebacks on warnings. Since it fails to do so,
#   implicitly printing tracebacks by coercing non-fatal warnings into fatal
#   exceptions is our next best least worst solution.
filterwarnings =
    # Implicitly coerce all non-fatal warnings into fatal exceptions.
    error

    # Avoid coercing all non-fatal warnings matching one or more of the
    # following patterns formatted as:
    #     ignore:{warning_message}:{warning_classname}:{module_name}
    #
    # ...where:
    # * "{warning_message}" is a regular expression matching the plaintext of
    #   the warning message to be ignored.
    # * "{warning_classname}" is the fully-qualified classname of the warning
    #   to be ignored.
    # * "{module_name}" is the fully-qualified name of the module emitting the
    #   warning to be ignored.
    #
    # For example:
    #     ignore:^Use of \.\. or absolute path in a resource path.*:DeprecationWarning:pkg_resources
    #
    # See also:
    # * https://docs.python.org/3/library/warnings.html and
    # * https://docs.pytest.org/en/latest/warnings.html
    ignore:^'cgi' is deprecated and slated for removal in Python 3\.13$:DeprecationWarning:babel.messages.catalog

The above real-world example even demonstrates how to "whitelist" various warnings that you'd rather just silently ignore than treat as fatal test failures.

Even if I have to do some monkey patching of beartype in my test script I would be pretty happy!

...heh. I too love me some monkey-patching. Truly, I see that you are a gentleman coder as well.
Sadly, the @beartype codebase is less amenable to monkey-patching than most. Basically, what I'm saying is that @beartype is a labyrinthine nightmare of grotesquely non-Euclidean proportions. It's best "not to go there." Even I shudder to go there. The beast is hungry. Don't feed the beast, @MilesCranmer. :laughing:
This means that this probably will have to linger until somebody finds a spare volunteer week or three for this. If you're keen to go there, I'd be happy to walk you through a PR implementing this. It seems quite tractable, but... yeah. The @beartype codebase isn't for everybody. If you genuinely think you have the time, energy, and interest, we can definitely make this happen in less than a thousand lines of code – probably a lot less.
But no promises. :wink:

Thanks for engaging with me on this and offering some sage wisdom! I can see how erroring on warnings is in general a good idea. I will think about this in the future. (Some of my warnings are on the boundary between general information and legitimate warnings which makes this more work, but I should probably just set up explicit filters for those parts.)
Anyways, I did eventually get @beartype into my CI. It didn’t feel right to change the runtime types to make the local error-checking tests pass (e.g., also, what if a downstream user wants to do runtime type checking or inspect stuff?), so instead what I did is the following changes:

Separate beartype-enabled job:

  beartype:
    name: Test with beartype
    runs-on: ubuntu-latest
    env:
      PYSR_USE_BEARTYPE: "1"
...

This just turns on @beartype inside PySR’s __init__.py

if os.environ.get("PYSR_USE_BEARTYPE", "0") == "1":
    from beartype.claw import beartype_this_package

    beartype_this_package()

Then I manually disable the relevant tests with this macro:

skip_if_beartype = unittest.skipIf(
    os.environ.get("PYSR_USE_BEARTYPE", "0") == "1",
    "Skipping because beartype would fail test",
)

used like
@skip_if_beartype
def test_deprecation(self):
    """Check helpful error messages for deprecated behaviour"""

Which lets me verify these deprecation errors give the right guidance to users, without erroring on the types when @beartype is enabled. It’s a bit hacky but I feel like it might be the most “correct” current approach to this?
Will also look into warning filters at the config level, thanks!

I would also like to have a context manager to disable type checking for a code path.
Situation: I have a project that only used beartype in tests and i would like to write a test for a function that checks a argument type by himself.
Because it seems that there is no way so "disable beartype temporarly", i have currently only two options:

Don't add a type hint to the function argument.
Add the correct type hint, but don't write a test that pass a wrong value.

Isn't it?

Wonderful! That's a perfect use case, @jedie – and yet more evidence that I should reprioritize this. In theory, there are probably various ways of forcing @beartype 0.19.0 to do what you want. In practice, it's not worth it to even try. Right?
@beartype should clearly just support this out-of-the-box, because that's what everybody wants. Thankfully, this looks super-feasible! I've already specced out exactly what I need to refactor in the @beartype codebase. Now, I just need to find the volunteer time to actually do it... y u gotta be like dis, life :weary:

authors: AlanCoding MilesCranmer TeamSpen210 jedie leycec

repo: beartype/beartype


text:
Support props on TouchableOpacity component. Fixes #14

Fixes #14

Closing stale PRs.

source: gharchive/pull-request

repo: beausmith/react-native-fontawesome-pro

license: MIT

license_type: permissive

license_source: github-api


text:
Added 'Wave' model as an example

Actually is a copy of the 'Post' model

I am sorry for not accepting this but at this moment the amount of models in this project are enough, I want to focus on getting this running as smoothly as possible before adding a lot of new models.
I hope you understand!

repo: beeman/loopback-angular-admin

license: mit

license_source: bigquery


text:
Don't run tests on git push

There is a github hook that runs all tests on each push, but it probably shouldn't. Once we have more of the codebase tested that could tie up the terminal for some minutes. There is also a concern that tests might not always be in a passing state on purpose - don't want that to block ability to push code. Triple check tests run in PR pipeline before accepting merge to not run in terminal.

Combining with #98 because it's easiest to fix both at the same time.

source: gharchive/issue

authors: jessica-obrien jlrpnbbngtn

repo: beer-garden/react-ui


text:
okay I dont know why the emulator is not working does anybody know how to solve it?

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:

Operating System:
Python version:
Software versions:

Briefcase:
Toga:
...

Additional context
Add any other context about the problem here.

I'm going to close this - the original report doesn't provide any details about the problem you're having, errors you're seeing, the platform you're using, or anything else that would help us diagnose the issue.

repo: beeware/beeware


text:
fix on_draw bug

Added a None check before calling on_draw. This cause crashes when trying to run the application without on_draw hook.
PR Checklist:

[X] All new features have been tested
[X] All new features have been documented
[X] I have read the CONTRIBUTING.md file
[X] I will abide by the code of conduct

I must express that calling on_draw in the function _resize is an odd things to me. I would expect this method to be called inside the draw() method. Is that on purpose?

repo: beeware/toga-chart


text:
use ISO 3166-1 alpha-2 for country

close https://github.com/before-interop/malfacon/issues/66

rejeté en interop

repo: before-interop/common


text:
some feature is not work

not work features

,y Yank to OS clipboard ( Misc
,p Paste from OS clipboard ( Misc
unicode symbols
highlight DSLs

hint:

Everthing is ok when i first install. In recent days, i have install again and some features is not work example above.I think there exist some other thing is also not work, but i haven't found them.
, Clear search highlights is work ( Misc
https://github.com/begriffs/haskell-vim-now/issues/206, when i second install.

env
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2016 21:22:16)
Included patches: 1-898
Compiled by root@apple.com
Normal version without GUI.  Features included (+) or not (-):
+acl             -farsi           -mouse_netterm   +syntax
-arabic          +file_in_path    -mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           -mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
+builtin_terms   -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         -gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
-clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   -perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    -keymap          +postscript      +virtualedit
+comments        -langmap         +printer         +visual
-conceal         +libcall         -profile         +visualextra
+cryptv          +linebreak       +python/dyn      +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      -lua             -rightleft       +windows
+diff            +menu            +ruby/dyn        +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
-emacs_tags      -mouseshape      -sniff           -xsmp
+eval            -mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L/usr/local/lib -o vim        -lm -lncurses  -liconv

macOs Sierra

Everything is all right after i do the following work.

reinstall brew
reinstall vim
xcode-select --install
reinstall haskell-vim-now
I guess the third step is usefull.

repo: begriffs/haskell-vim-now


text:
ASP .Net Core Projesinin oluşturulması

ASP .Net Core 3.1 ile yeni proje oluşturulacak.

.Net Core Api projesi oluşturuldu.

repo: bekoturko/NetCoreSample


text:
Selenium headless not working - workaround to force 4.12.0

Have found that when I did a pipenv update then ran the code on my local machine, the firefox browser would display briefly. However on the server (with no terminal attached) it couldn't, so errored out, not producing a screenshot
In my Pipfile I've added this for the meantime which works as before
#selenium = "*"
# bug where it renders to screen on 4.15.0, and fails on the server
selenium = "==4.12.0"

Great issue Dave, thanks for flagging this. This is probably due to a change to how Selenium handles headless mode. It should have been raising a deprecation warning before.

Thank you very much Galen for fixing this!

authors: GalenReich djhmateer

repo: bellingcat/auto-archiver


text:
Хакатончик по решению Issue на БЭМ проектах

Добре!
Есть идейка продвинуть застоявшиеся анклавы задач в БЭМ проектах.
Может организуем хакатончик с одной целью сделать за сутки задачи которые давно подвисли на проектах БЭМ?
Нужены будут кураторы из мантейнеров проектов
И конечно добровольцы!
Кто за?

Тут буквально был неделю назад)

@awinogradov а результаты?

@pavelpower скоро (или не скоро) каждая команда напишет про свою результат.

@blond, @awinogradov
Я же говорю про решение задач кои уже обозначены в issue-tracker на github.
А что делали на прошедшем хакатончике?

https://events.yandex.ru/events/bemup/12-december-2015/

@blond, слишком много инноваций, и нет решений текущей боли. Только перспективняк.
А я же говорю о четком решении задач которые уже обозначены.
enb, bem-pr, enb-bem-specs, ну и т.д.

@blond, решая задачи из перспективника, почему-то забыли о текущих насущных проблемах. И это скорее портит положительное отношение к технологиям, если, конечно, не ударится в религию с головой.

@blond, я чаще замечаю, что поиск новых решений забирает слишком много ресурсов не давая решить все ткущие проблемы тех, что здесь на формуе каждый раз поднимает одни и те же вопросы изо дня в день, из месяца в месяц. Почему-то хватаемся за звезды, не подготовив для этого хорошую базу.

Я конечно могу ошибаться, но где тогда обозначен вектор развития?
На всех bem-сайтах есть информация о постфактум выполненной работе. А без вектора развития, сложно другим разработчика делать что-либо полезное.
По этому и предлагаю провести хакатон, где будут мантейнеры проектов, с тем кто их использует работать над насущными задачами разработки, забыв не на долго о перспективнике.
Ибо, мысли о развитии могут далеко идти в разрез с текущими потребностями.

cc @vithar @tadatuta

@pavelpower
Воу-воу!
Про необходимость собирать БЭМ-проекты с помощью любых сборщиков мы рассказываем больше года (например, https://ru.bem.info/forum/-659/) и в том числе копали в этом направлении на прошлом хакатоне, в котором ты принимал участие.
На этом, наконец, довели задачу до по-настоящему работающего состояния.
Существующим bem create пользоваться больно — это в чистом виде история про разобраться с «застоявшимся».
Про bem mv и прочие утилити говорим года 2, кажется: https://github.com/bem/bem-tools/pull/502
Линтеры — это вообще санитарный минимум, странно, что их отсутствие не вызывает боли. И про этот вектор тоже вроде давно все известно: https://github.com/bem/bemhint/
Ну и, наконец, тема «Любые issues в существующих инструментах» тоже была предложена, но желающих заняться не нашлось.
Ну и вроде ты из первых рук в курсе, как все происходит в Яндексе. Никто не забьет на текущие инструменты, пока ими пользуются, а пользоваться будут еще долго. И развитие существующего происходит на постоянной основе. У нас есть целая служба, которая занимается исключительно инфраструктурными задачами вокруг фронтенда на БЭМ.
А хакатон для нас — это редкая возможность заняться задачами не на «здесь и сейчас», а продвинуться вперед.
Но если у тебя есть возможность и желание вложиться в решение насущных проблем существующих инструментов — заводи issue, призывай мейнтейнеров для обсуждения. Если проблема не узкая, тебе обязательно подскажут, какое решение может быть принято в апстрим.

Как по мне, формат хакатона подходит для тех задач где нужно собраться командой, обменяться опытом, нагенерировать идей и т.п.
А чтобы делать хорошо понятные задачи, нужно каждый день делать их хорошо :)

@pavelpower привет, я чуть выше опубликовал результаты нашей команды на минувшем хакатоне: https://ru.bem.info/forum/774/

@blond, все таки ты прав, на счет хакатона.
@sullenor посмотрел, добротная работа!

authors: awinogradov blond pavelpower sullenor tadatuta

repo: bem/bem-forum-content-ru


text:
Do not show "Open in GitHub" menu item when IDEA does that already

Doesn't happen here, at newly installed v4.1.8

repo: ben-gibson/GitLink


text:
Make module folder move work across volumes

Fix for issue #162
Directory.Move does not work across volumes, meaning having your Temp folder not on the same drive as your User folder will cause module installation to fail.
This uses a non-recursive folder-copy / delete appropriated for SO instead of Directory.Move.

Sorry about the whitespace crap, that was the VS linter's doing.

Sorry for the delay on this, been super busy implementing the new oscquery spec as per vrchat's open beta. I actually made & committed a less-verbose fix for this on the day but forgot to actually push it. Thanks for your PR and sorry I didn't see it sooner

No worries, important thing is it's fixed :)

This still hasn't been integrated into a release?

authors: benaclejames orcinus

repo: benaclejames/VRCFaceTracking


text:
this is a bug?

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
https://media.discordapp.net/attachments/817228555258953738/817974138731233310/unknown.png
What device are you on?
Additional context
well i see the console and i see when a ws open

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
https://media.discordapp.net/attachments/817228555258953738/817974138731233310/unknown.png
What device are you on?
Additional context
well i see the console and i see when a ws open

This is fine, not a bug. Just websocket logging stuff.

@nadirabbas @benawad  close this issue

authors: ELPanaJose Mudrank ermalsh

repo: benawad/dogehouse


text:
addNewRow() : Insertion after a particular row.

When I use the grid for data entry, I would really like to insert a row after any arbitrary position, and also wants to rearrange rows by moving up and down. In order to test this, I have implemented a grid column's menu item 'Insert After' like this in my code;
GRID_ACTIONS: {
    menu: [{
            text: 'Insert After',
            EVENT_HANDLER: ({ metaData }) => {
                const rowIndex = metaData.rowIndex;
                store.dispatch(
                    Actions.EditorActions.addNewRow({ rowIndex, ...

However, In the function addNewRow(_ref10) of EditorAction.js(135), the rowIndex is always 0 after var rowIndex = 0; statement  and never gets chance to be changed until it is finally used in;
var addNewRow = exports.addNewRow = function addNewRow(_ref10) {
    var columns = _ref10.columns,
        data = _ref10.data,
        stateKey = _ref10.stateKey,
        _ref10$editMode = _ref10.editMode,
        editMode = _ref10$editMode === undefined ? 'inline' : _ref10$editMode,
++        _ref10$rowIndex = _ref10.rowIndex,
++        targetIndex = _ref10$editMode === undefined ? 0 : _ref10$rowIndex;

    return function (dispatch) {
        var rowId = (0, _keyGenerator.keyGenerator)('row', (0, _getNewRowId.getNewRowId)());
        var top = 43;
        var rowData = data || {};
--        var rowIndex = 0;
++        var rowIndex =targetIndex;
        var isCreate = true;

        dispatch({ type: _ActionTypes.ADD_NEW_ROW, stateKey: stateKey, rowId: rowId });

        dispatch(editRow({
            rowId: rowId,
            top: top,
            rowData: rowData,
            rowIndex: rowIndex,
            columns: columns,
            isCreate: isCreate,
            stateKey: stateKey,
            editMode: editMode
        }));
    };
};

Because of this, addNewRow() is always inserting a new row at the top.  Is it possible to create an empty row after a particular rowIndex which is passed as a parameter to addNewRow like above?
Also any suggestion in moving a row down or up from custom column menu?
Thanks.

It would be really helpful if you could format these issues.

I have updated this issue. Sorry for the ugly code format.

Thank you! Agreed, this action should take a dynamic rowIndex, where it defaults to 0.
Once this is implemented you can call this via a row-action -- since index is an argument to row actions, you can simply do => rowAction ++, or rowAction -- for above and below, respectively.

Fix has been implemented -- will be published in next release.

Hi Benjamin,
I have downloaded git and tested out your change, and it didn't work. To make it work I had to modify two files. Can you test out and include these changes in the next release. It will be greatly appreciated if I can see the change in the next release.
Thanks.
John.
src/editor/EditorActions.js
export const addNewRow = ({
    columns,
    data,
    stateKey,
    editMode = 'inline',
    rowIndex = 0,
    isCreate = true
}) => (dispatch) => {
    const rowId = keyGenerator('row', getNewRowId());
    const top = 43;
    const rowData = data || {};

--    dispatch({ type: ADD_NEW_ROW, stateKey, rowId});
++    dispatch({ type: ADD_NEW_ROW, stateKey, rowId, rowIndex });

    dispatch(
        editRow({
            rowId,
            top,
            rowData,
            rowIndex,
            columns,
            isCreate,
            stateKey,
            editMode
        })
    );
};

src/reducers/actionHelpers/plugins/datasource.js

export const addNewRow = (state, { rowId, stateKey, rowIndex }) => {
    const existingState = state.get(stateKey);
    const isEditing = existingState && existingState.get('isEditing');
    let data = existingState && existingState.get('data');

    if (existingState && isEditing) {
        return state;
    }

    let newRow = data
        && data.size > 0
        && data.get(0)
        ? data.get(0).map((k, v) => v = '')
        : fromJS({});

    newRow = newRow.set('_key', rowId);

    if (!data) {
        data = new List();
    }

 --   const newData = data.unshift(newRow);

 ++   rowIndex = rowIndex===undefined?0:rowIndex;
 ++   const newData = data.insert(rowIndex, newRow); // rather than adding at the head use insert at specific location

    const updated = existingState.merge({
        data: newData,
        proxy: data,
        isEditing: true,
        lastUpdate: generateLastUpdate(),
        total: newData.size
    });

    return state.setIn([stateKey], updated);
};

Why not submit a PR with these changes?

OK, I did 'npm t' on my changes and I got testing errors. I have changed the test I have added rowIndex parameter for ADD_NEW_ROW actions in the datasource.test.js, and added rowIndex to EditorAction.test.js like this;
        const action = {
            rowId: 'row-id',
            stateKey: 'test-grid',
            rowIndex: 0,
            type: ADD_NEW_ROW
        };

       expect(result)
            .toEqual([
                {
                    rowId: 'cm93LTE=',
                    stateKey: 'test-grid',
                    rowIndex: 0,
                    type: ADD_NEW_ROW
                },

Do you have any idea what I may be missing? The first error looks like this;
  The grid addNewRow Action     ×Should set validation state         Error: Expected [ { rowId: 'cm93LTE=', rowIndex: 0, stateKey: 'test-grid', type: '@@react-redux-grid/ADD_NEW_ROW' }, { columns: [ { dataIndex: 'col1', name: 'Col1' }, { dataIndex: 'col2', name: 'Col2' } ], editMode: 'inline', isCreate: true, rowId: 'cm93LTE=', rowIndex: 0, stateKey: 'test-grid', top: 43, type: '@@react-redux-grid/EDIT_ROW', values: {} } ] to equal [ { rowId: 'cm93LTE=', stateKey: 'test-grid', type: '@@react-redux-grid/ADD_NEW_ROW' }, { columns: [ { dataIndex: 'col1', name: 'Col1' }, { dataIndex: 'col2', name: 'Col2' } ], editMode: 'inline', isCreate: true, rowId: 'cm93LTE=', rowIndex: 0, stateKey: 'test-grid', top: 43, type: '@@react-redux-grid/EDIT_ROW', values: {} } ]             at assert (D:/test2/react-redux-grid/webpack/webpack.test.js:21923:9)             at Expectation.toEqual (D:/test2/react-redux-grid/webpack/webpack.test.js:33131:30)             at Context.<anonymous> (D:/test2/react-redux-grid/webpack/webpack.test.js:42538:39)

That test is fickle. Go ahead and submit the PR and I'll take a look.

repo: bencripps/react-redux-grid


text:
Unable to convert to tensorflow serving

Hi I am following steps mentioned in https://github.com/fizyr/keras-maskrcnn. The model that I use is resnet50_coco_v0.2.0.h5 from (https://github.com/fizyr/keras-maskrcnn/releases).
when I run
python3 main.py

The error I get is:
ValueError: Layer #2 (named "conv1") expects 2 weight(s), but the saved weights have 1 element(s).

complete error stack trace:
FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint8 = np.dtype([("qint8", np.int8, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:517: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:518: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint16 = np.dtype([("qint16", np.int16, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:519: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:520: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint32 = np.dtype([("qint32", np.int32, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorflow/python/framework/dtypes.py:525: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  np_resource = np.dtype([("resource", np.ubyte, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:541: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint8 = np.dtype([("qint8", np.int8, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:542: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:543: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint16 = np.dtype([("qint16", np.int16, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:544: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:545: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  _np_qint32 = np.dtype([("qint32", np.int32, 1)])
/home/ajinkya/anaconda3/envs/tensorflowGPU_p36/lib/python3.6/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:550: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
  np_resource = np.dtype([("resource", np.ubyte, 1)])
Using TensorFlow backend.
WARNING:tensorflow:From main.py:10: The name tf.Session is deprecated. Please use tf.compat.v1.Session instead.

2020-05-14 10:40:17.583273: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2020-05-14 10:40:17.623709: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency: 3193675000 Hz
2020-05-14 10:40:17.624878: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x562e8e163e60 executing computations on platform Host. Devices:
2020-05-14 10:40:17.624924: I tensorflow/compiler/xla/service/service.cc:175]   StreamExecutor device (0): <undefined>, <undefined>
WARNING:tensorflow:From /home/ajinkya/.local/lib/python3.6/site-packages/keras/backend/tensorflow_backend.py:4070: The name tf.nn.max_pool is deprecated. Please use tf.nn.max_pool2d instead.

WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:337: The name tf.log is deprecated. Please use tf.math.log instead.

WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:395: add_dispatch_support.<locals>.wrapper (from tensorflow.python.ops.array_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use tf.where in 2.0, which has the same broadcast rule as np.where
WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:419: calling crop_and_resize_v1 (from tensorflow.python.ops.image_ops_impl) with box_ind is deprecated and will be removed in a future version.
Instructions for updating:
box_ind is deprecated, use box_indices instead
WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:719: The name tf.sets.set_intersection is deprecated. Please use tf.sets.intersection instead.

WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:721: The name tf.sparse_tensor_to_dense is deprecated. Please use tf.sparse.to_dense instead.

WARNING:tensorflow:From /home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py:771: to_float (from tensorflow.python.ops.math_ops) is deprecated and will be removed in a future version.
Instructions for updating:
Use `tf.cast` instead.
Traceback (most recent call last):
  File "main.py", line 108, in <module>
    model.load_weights(H5_WEIGHT_PATH, by_name=True)
  File "/home/ajinkya/Downloads/mrcnn_serving_ready-master/model.py", line 2131, in load_weights
    saving.load_weights_from_hdf5_group_by_name(f, layers)
  File "/home/ajinkya/.local/lib/python3.6/site-packages/keras/engine/saving.py", line 1309, in load_weights_from_hdf5_group_by_name
    ' element(s).')
ValueError: Layer #2 (named "conv1") expects 2 weight(s), but the saved weights have 1 element(s).

What is happening here ? any thoughts to get serving model from this script?

This repo has only been tested for MatterPort MaskRCNN. I do not know whether it will work for  https://github.com/fizyr/keras-maskrcnn.
I am not sure but the error might be happening because of the mismatch of model configuration. Do let me know if you figured out to convert it.


text:
Prevent scrolling on page

It causes the dot to be incorrect.

I'VE NOT EVEN ANNOUNCED THIS @AVERAGEMARCUS
but, also, thank you

😉  I've been getting better at my stalking!

authors: AverageMarcus benfoxall

repo: benfoxall/event-batcher


text:
Adding custom argument types

Hi,
Thank you for the lib.
Add the moment I am in need of a void argument type.
I tried adding it with ref-napi but no luck.
Is there any other way to add one?
const void = ref.refType('void');
getNativeFunction(null, 'myfunction', 'int', [void]);

Apologies, should have seen https://github.com/bengl/sbffi/blob/master/lib/index.js#L34 closing now.

repo: bengl/sbffi


text:
Zambian Currency ZMK is missing

Zambian Currency ZMK is missing.
https://www.xe.com/currency/zmk-zambian-kwacha

I don't think ZMK is the correct currency code for Zambia. It lists ZMW as the most current Zambian currency code and ZMK in the Historical currency codes
The mapping doesn't list any Zambian currency, I think that might be the real issue?
Let me know if I missed something/reading it wrong.

Fixed in https://github.com/bengourley/currency-symbol-map/pull/61

Fixed in https://github.com/bengourley/currency-symbol-map/pull/61

authors: jasonenglish namenyi tomerb15

repo: bengourley/currency-symbol-map


text:
Adds some additional Receipt Metadata

Primarily needed the transaction identifier and original transaction identifier from the receipt metadata.

This looks good and functionally coherent; I have a few minor tweaks I want to do, e.g making the string properties non-optional (using empty string instead) that I’ll clean up sometime this week.

I merged a reduced form of this as I realised several of the properties apply to individual In-App Purchases, rather than the receipt as a whole which is the purpose of ReceiptMetadata. I would like to expose information like originalTransactionIdentifier in the future, but it would require larger API changes.

authors: benjaminmayo joshbillions

repo: benjaminmayo/merchantkit


text:
Add version checking

It may be a good idea to add some version checking to ensure the customer is using a supported version of PowerCLI and PowerShell before trying to use the module in earnest.

The function to retrieve the SRM server version is:
Get-SrmServerVersion

The function to retrieve the SRM server version is:
Get-SrmServerVersion

repo: benmeadowcroft/SRM-Cmdlets


text:
Doesn't seem to support yarn v2

Yarn v2 recently came out with a new module directory structure that doesn't seem to be supported by eslint-plugin-import.

I’m quite aware of it; see #1591, a PR from the yarn maintainer to make it compatible.
Are you on the latest version of the plugin?

I'm running latest version of the plugin (2.20.1) and with yarn v2 I run into :
Resolve error: unable to load resolver "node" erros

I believe you'll need to add eslint-plugin-resolver-node to your top-level dev deps; either way, I think issues with yarn need to be filed on yarn.

Looking to this changes seems like it fixes only cases when eslint-plugin-import is installed directly in the project. But if the project imports another config which includes eslint-plugin-import then it doesn't work with Yarn 2.
So speaking simply the bug still persists. You just have to use dependency structure root-project-taht-is-linted -> my-custom-eslint-config -> eslint-plugin-import to reproduce it

@constgen anything that works in npm but breaks in yarn 2 is a bug in yarn 2; please feel free to file it there.

authors: AlexandreBonaventure constgen fifn2 ljharb

repo: benmosher/eslint-plugin-import


text:
xavtool - Xamarin Automating Version Tool

xavtool
https://github.com/gabrielrobert/xavtool
Command-line utility to automatically increase iOS / Android / UWP applications version. It follows Semantic Versioning.

thanks, nice tool !

authors: benoitjadinon gabrielrobert

repo: benoitjadinon/awesome-xamarin


text:
KeyError: 'species_index'

For some time now I get the following error:

At the same time the graphs in the Society tab for pops and for jobs are not working.

Thanks for bringing this up. Looks like the file format was changed with the new update. I'll have to figure out the new format and make an update to support both 2.0 and 3.0


text:
Daemon Session

The core function which openes #10

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/create

missing access to library at present
@WielandF will check with @jan1993

@WielandF - we urgently need an update here - didn't know in our call what the latest status is

waiting for returns from library

basic coding complete
extended with #67 and #70

authors: WielandF bensteUEM

repo: bensteUEM/mystique


text:
MIPS32 Architecture Release Needed

Version number
ALL
Describe the bug
One of the most affordable routers in Iran that supports the OPENWRT operating system is the Xiaomi 4A Gigabit router, which utilizes MIPS32 architecture. Unfortunately, the file for this architecture is not available in the downloads section.
Please build and add the MIPS32 architecture file as well.
Thanks
Screenshots
Screenshot comparing two files: xray (executable on this router) and Warp-Plus (not executable on this router).

Additional context
If you need more details, let me know

I see, there's also some discussion in #71
I'll work on this for the next release.

The changes required have been merged and will be available in the next release. :heart:

authors: imansoleimani markpash

repo: bepass-org/warp-plus


text:
Traincart don't work

Info
Please provide the following information:

BkCommonLib Version (/train version):
TrainCarts Version (/train version):
Server Type and Version (/version):
[월, 19. 10월 2020 09:40:05 KST INFO] Train_Carts v1.12.2-v1 using BKCommonLib v1.12.2-v5
This server is running Paper version git-TacoSpigot-"f8ba67d6" (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT)
[월, 19. 10월 2020 09:40:16 KST INFO] Previous version: git-Paper-1618 (MC: 1.12.2)
[월, 19. 10월 2020 09:40:16 KST INFO] Checking version, please wait...
[월, 19. 10월 2020 09:40:17 KST INFO] You are 1 commits behind the latest version!

Bug
Description
Please replace this sentence with a detailed description of what exactly happens that you consider a bug.
Try to explain it as if you would tell a friend.
The server's players say that it just doesn't work
Expected behavior
What do you expect TrainCarts to do?
Just work properly
Actual behavior
What is TrainCarts doing instead?
Steps to reproduce
Please list the steps to take, in order to reproduce the bug.
It just once started to happen
Additional Information
<[월, 19. 10월 2020 09:39:40 KST ERROR] Failed to perform physics on train 'train700' at null: [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at java.util.ArrayList.rangeCheck(Unknown Source) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at java.util.ArrayList.get(Unknown Source) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartGroup.head(MinecartGroup.java:115) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartGroup.head(MinecartGroup.java:119) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartGroup.getSpeedAhead(MinecartGroup.java:994) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartGroup.doPhysics_step(MinecartGroup.java:1137) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartGroup.doPhysics(MinecartGroup.java:955) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.tc.controller.MinecartMember.onTick(MinecartMember.java:1424) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.bukkit.common.internal.hooks.EntityHook.onTick(EntityHook.java:117) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.mountiplex.reflection.util.fast.GeneratedInvoker$mplgen3036d523.invokeVA(Unknown Source) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.mountiplex.reflection.util.FastMethod.invokeVA(FastMethod.java:112) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at com.bergerkiller.mountiplex.reflection.ClassInterceptor$CallbackMethodInterceptor.intercept(ClassInterceptor.java:654) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.EntityMinecartRideable$$EnhancerByCGLIB$$6e471449.B_(<generated>) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.World.entityJoinedWorld(World.java:1779) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.World.h(World.java:1749) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.World.tickEntities(World.java:1564) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.WorldServer.tickEntities(WorldServer.java:678) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.MinecraftServer.D(MinecraftServer.java:914) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.DedicatedServer.D(DedicatedServer.java:427) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.MinecraftServer.C(MinecraftServer.java:767) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:665) [월, 19. 10월 2020 09:39:40 KST ERROR] [BKCommonLib]   at java.lang.Thread.run(Unknown Source)>

Train_Carts v1.12.2-v1 using BKCommonLib v1.12.2-v5
Wow thats a pretty old version! Please install BKCommonLib 1.16.3 and Traincarts 1.16.3 release from spigot. These versions also work with Minecraft 1.12.2.

ok, i will try it
2020년 10월 19일 (월) 오전 9:53, Irmo van den Berge notifications@github.com님이
작성:

Train_Carts v1.12.2-v1 using BKCommonLib v1.12.2-v5
Wow thats a pretty old version! Please install BKCommonLib 1.16.3 and
Traincarts 1.16.3 release from spigot. These versions also work with
Minecraft 1.12.2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bergerhealer/TrainCarts/issues/397#issuecomment-711453033,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANM6N2M6UERVTOSMYAA3JF3SLOEZ5ANCNFSM4SVOQHPA
.

LOL IT WORKED

repo: bergerhealer/TrainCarts


text:
Author Icon for Newsletters

Is there an existing issue for this?

[X] I have searched the existing issues

Browser
Any browser
Feature request
At the bottom of the newsletters there is a little icon with a name who wrote it:

@costinberty encouraged me to ask if i could have my own little thing for the newsletters I write :)
I tried to see how it worked and god something like this:

What to put there exactly i do not know yet, but I thought id ask :)
Context
See upper block
Possible implementation
No response

@iuricmp , what should be changed in a PR to update this image?

hey @LFGaming
Could you try this:

add your name in data/authors.yml
add an author in content/newsletter/news-72/index.md

author: luke
title: "Berty News #72"
date: 2024-01-08
aliases: ["/newsletter/weekly-72"]

test it locally: make dev

Hi @LFGaming . Did the comment by @iuricmp answer your question?

Hi @jefft0 ,
It did, I'll make a pr in a bit :)

This issue was resolved in https://github.com/berty/www.berty.tech/pull/413

authors: LFGaming iuricmp jefft0


text:
我们一起膜拜匡老师吧！

deadline: 'end-of-term'
submit: |
匡老师是厉害啊！我们一起膜拜匡老师吧！

不能加 label，差评！

repo: beta/homework


text:
🛑 Endpoint CNAF v2 is down

In 93b143a, Endpoint CNAF v2 (https://particulier.api.gouv.fr/api/v2/composition-familiale?numeroAllocataire=$NUMERO_ALLOCATAIRE&codePostal=$CODE_POSTAL) was down:

HTTP code: 500
Response time: 470 ms

Resolved: Endpoint CNAF v2 is back up in 9a2f93b.

repo: betagouv/api-particulier-status


text:
En tant qu'instructrice, j'ai besoin de voir le numéro de l'article concerné par la déclaration - Mauvaise affichage arti 15 pop à risque et vigilance

https://github.com/user-attachments/assets/5fe96caf-1c92-4e4c-8d8d-666700e7a322

Uploading Enregistrement de l’écran 2024-12-12 à 19.59.52.mov…

il s'agit simplement d'un défaut d'affichage.
Le courrier qui part est le bon et l'article calculé aussi.

repo: betagouv/complements-alimentaires


text:
🛑 API Camino is down

In 2e4b02b, API Camino (https://api.camino.beta.gouv.fr/titres) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API Camino is back up in 869191c.


text:
Resource listing - unlink authors info

In addition to not linking, spacing should be adjusted to clearly group an author with a resource.

OK, fixed!

authors: clararaubertas sbxchicago


text:
🛑 Esra BULUT is down

In 3b244d6, Esra BULUT (https://esrabulut.com.tr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Esra BULUT is back up in 3e7e84d after 48 minutes.

repo: betterwithagency/status-page


text:
🛑 Mon Yoga is down

In 5ca5cc2, Mon Yoga (https://monyoga.co) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mon Yoga is back up in 534dcc4 after 7 minutes.


text:
Feathering for Gizmo lines

What problem does this solve or what need does it fill?
The line gizmos (and everything built on top of lines) currently rely on external anti-aliasing to remove staircase effects. Since high-quality AA is relatively expensive, it would be nice if that wasn't necessary to get good-looking lines.
What solution would you like?
Lines can implement "feathering", which creates extra vertices around the lines that fade out into transparency over a few pixels. egui/epaint is an example of a library that implements this.
What alternative(s) have you considered?

Use FXAA instead, which looks kinda bad and is still likely more expensive than feathering since it's a full-screen pass.
Use higher-quality AA like MSAA, which is relatively expensive in terms of memory usage/traffic and costs extra resolve passes.

Is it that unreasonable to use them for something like a player-facing level editor?

Given their immediate mode use, I generally find it ill advised to use it for those purposes. The best use cases are often focused on small and scoped debug or editing use cases where developer UX is prioritized over performance or visual quality. If the intent is to expose something like this for a player-facing level editor, IMO it's acceptable to accept the hit to visual quality, or write proper retained mode editing tools if performance and visual quality is critical.

repo: bevyengine/bevy


text:
bevy_text feature is required to run bevy_ui tests

Bevy version
0.15-dev
What you did
Ran cargo test -p bevy_ui
What went wrong
Compile errors saying bevy_text is missing.
Additional information
Works if you use cargo test -p bevy_ui --features bevy_text. The need to pass the feature here is unexpected and @mockersf says it's a bug.

@alice-i-cecile is this 0.15 milestone?

not a blocker for the 0.15, but nice to have if there's a PR for it

Ran into this updating one of my PR's. I think its just a few cargo config related tweaks missed from 396aff906e401957507726e3af7d997004117c60

authors: BenjaminBrienen StrikeForceZero UkoeHB mockersf