What to do with deprecated public submodules

There are various currently public submodules in scipy that are to be deprecated in scipy v2.0.0 such as io.matlab.mio. These files simply  have two functions that are really overrides of the standard module functions __dir__ and __getattr__ in order to display deprecation warnings.
For example this is scipy/io/matlab/mio.py.
# This file is not meant for public use and will be removed in SciPy v2.0.0.
# Use the `scipy.io.matlab` namespace for importing the functions
# included below.

from scipy._lib.deprecation import _sub_module_deprecation

__all__ = ["loadmat", "savemat", "whosmat"]  # noqa: F822

def __dir__():
    return __all__

def __getattr__(name):
    return _sub_module_deprecation(sub_package="io.matlab", module="mio",
                                   private_modules=["_mio"], all=__all__,
                                   attribute=name)

The most obvious type hints for this def __dir__() -> list[str]: ... and def __getattr__(name: str) -> Any. Is this good enough?
Would there be any alternatives to using Any in the case of the second? I feel like this would obscure the type of attribute being accessed but I'm not sure giving concrete types are possible at all or desirable.
If the type hints I suggested are okay I can go and make a PR to add these type annotations to every instance of this pattern.

Actually I saw how @jorenham has done it in files like scipy/integrate/vode.pyi.
# This file is not meant for public use and will be removed in SciPy v2.0.0.
from typing_extensions import Never, deprecated

__all__: list[Never] = []

@deprecated("will be removed in SciPy 2.0.0.")
def __dir__() -> list[Never]: ...
@deprecated("will be removed in SciPy 2.0.0.")
def __getattr__(name: str) -> Never: ...  # pyright: ignore[reportIncompleteStub]

Just need to copy it like this? This should be simple to auto-replace using a script I think.

Yea there's quite a couple of those; good question
I'm not sure anymore whether __getattr__ and __dir__ are the way to go actually.
Yesterday, I even went as far as to prohibit their use in https://github.com/jorenham/unpy/pull/79
In other modules, e.g. special, I left those out, see e.g. https://github.com/jorenham/scipy-stubs/blob/master/scipy-stubs/special/sf_error.pyi
Usually, these deprecated modules are simply re-exports of other (private) modules, so you could just place a comment saying that it's deprecated, and then just re-export them.
I also wouldn't mind if you'd use a "dummy" function with a @deprecated, e.g.
@deprecated("don't")
def loadmat(*args: object, **kwds: object) -> object: ...

Either way, we should probably try to minimize the amount of stubtest errors. In cases like these I'm fine with ignoring an error or two in the allowlist, but that won't even be necessary when you go for the re-export or dummy-function approach.

it's too bad that warnings.deprecated doesn't work on entire modules

Yes in regards to "I'm not sure anymore whether getattr and dir are the way to go actually.", it seems to obscure the type checker's ability to reason about the attributes' type.
Does adding @deprecated warn the user via the LSP that it is deprecated? That might make it better than just simply re-exporting because the comment can't be read unless you jump to the type definition.
This would be a lot more work though because you would need to duplicate the type annotations rather than just the names like in the re-export approach.

Yes in regards to "I'm not sure anymore whether getattr and dir are the way to go actually.", it seems to obscure the type checker's ability to reason about the attributes' type.

You're right; and that's precisely the reason why I decided to disallow them in unpy: __getattr__ and __dir__ are dynamic, stubs are static.

Does adding @deprecated warn the user via the LSP that it is deprecated? That might make it better than just simply re-exporting because the comment can't be read unless you jump to the type definition.

I know that at least VScode supports it in a very helpful manner. I don't think that mypy currently supports it, but pyright (==pylance) do.

This would be a lot more work though because you would need to duplicate the type annotations rather than just the names like in the re-export approach.

Yea I agree that it's not very DRY. But unfortunately, code duplication is something very common in python typing (which I'm currently trying to tackle through unpy).
But I consider @deprecated as a "nice to have", so adding it in a later iteration would be fine too.
Perhaps this is also something that we can automate with unpy.
The main priority is to have complete scipy-stubs so that it's complete, and valid (at least according to stubtest, (based)mypy, (based)pyright, and ruff), and most importantly, helpful.
Either way, I guess I'm fine with whatever you decide on this point.
If stubtest, ruff and basedpyright are happy with it, then I am too.

Ok got it.
I am actually not too familiar with the tools as of right now. What is the expected output of stubtest, ruff and basedpyright as of now, considering that the stubs are incomplete? I think I tried running stubtest but it just complained about missing stubs.

Assuming that you have poetry and poe installed, then you can run stubtest on a specific directory as e.g.
$poe stubtest scipy.special -- --ignore-unused-allowlist
Poe => stubtest --mypy-config-file=pyproject.toml --allowlist=tests/stubtest/allowlist.txt scipy.special --ignore-unused-allowlist
Success: no issues found in 100 modules

similarly, you can run
$ poe mypy special
Poe => mypy --config-file=pyproject.toml scipy-stubs/special
Success: no issues found in 19 source files
$ poe pyright special
Poe => basedpyright scipy-stubs/special
0 errors, 0 warnings, 0 notes

and
$ poe lint
Poe => ruff check
All checks passed!

(so ruff is already happy with everything)
The "unfinished" modules indeed produce errors in stubtest at the moment. So when you're tackling a package or module, you can consider it "complete" if there are no stubtest errors left.
But I'm planing to write a contributing guide soon, see #50

This apparently was auto-closed, sorry for that.

I think my PR mostly closes this issue.

Yea sounds like a plan


Revert the changes for NNPACK build issue

This patch undoes the change that was put in place to prevent the build and installation of NNPACK from failing due to a renaming of the default branch to main by the NNPACK external dependency cpuinfo.
See https://github.com/apache/tvm/issues/13871
The issue has been fixed at the source by PR #214 which is now merged in to NNPACK, so the change to ubuntu_install_nnpack.sh is no longer required:
https://github.com/Maratyszcza/NNPACK/pull/214
CC @ashutosh-arm @leandron @driazati @areusch

@tvm-bot rerun

@tvm-bot rerun


WPFHostingWin32Control sample and walkthrough missing RegisterTouchWindow()

Issue description
The WPFHostingWin32Control sample and walkthrough are missing a call to RegisterTouchWindow(). Without this the win32 child window will receive mouse and keyboard events, but not touch (WM_TOUCH) or gesture events.
Target framework
Check the .NET target framework(s) being used, and include the version number(s).

[ ] .NET Core
[x] .NET Framework
[ ] .NET Standard

If using the .NET Core SDK, include dotnet --info output. If using .NET Framework without the .NET Core SDK, include info from Visual Studio's Help > About Microsoft Visual Studio dialog.

About VS info
Microsoft Visual Studio Professional 2017
Version 15.9.16
VisualStudio.15.Release/15.9.16+28307.858
Microsoft .NET Framework
Version 4.7.03062

Installed Version: Professional

Visual C++ 2017   00370-20004-56286-AA303
Microsoft Visual C++ 2017

Application Insights Tools for Visual Studio Package   8.14.20131.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017   15.9.04012.0
ASP.NET and Web Tools 2017

C# Tools   2.10.0-beta2-63501-03+b9fb1610c87cccc8ceb74a770dba261a58e39c4a
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

IntelliCode Extension   1.0
IntelliCode Visual Studio Extension Detailed Info

JavaScript Language Service   2.0
JavaScript Language Service

JavaScript Project System   2.0
JavaScript Project System

JavaScript UWP Project System   2.0
JavaScript UWP Project System

Markdown Editor   1.12.253
A full featured Markdown editor with live preview and syntax highlighting. Supports GitHub flavored Markdown.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards   1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

MLGen Package Extension   1.0
MLGen Package Visual Studio Extension Detailed Info

NuGet Package Manager   4.6.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Productivity Power Tools 2017/2019   16.0
Installs the individual extensions of Productivity Power Tools 2017/2019

ProjectServicesPackage Extension   1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

ResourcePackage Extension   1.0
ResourcePackage Visual Studio Extension Detailed Info

ResourcePackage Extension   1.0
ResourcePackage Visual Studio Extension Detailed Info

SVG Viewer   1.0.9
Makes it much easier to work with SVG files by showing a live preview in the bottom-right corner of the code window

Test Adapter for Boost.Test   1.0
Enables Visual Studio's testing tools with unit tests written for Boost.Test.  The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test   1.0
Enables Visual Studio's testing tools with unit tests written for Google Test.  The use terms and Third Party Notices are available in the extension installation directory.

TypeScript Tools   15.9.30718.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   2.10.0-beta2-63501-03+b9fb1610c87cccc8ceb74a770dba261a58e39c4a
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual C++ for Linux Development   <IP_ADDRESS>218
Visual C++ for Linux Development

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Tools for CMake   1.0
Visual Studio Tools for CMake

Visual Studio Tools for Universal Windows Apps   15.0.28307.858
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

ping @Thraka

Thanks for noting this. I'll add this to our desktop guide area for updated WPF content for .NET Core. Thanks.


Installation problem on Ubuntu-MATE

Hello,
I wanted to install hawk on my new Ubuntu-MATE 22.04.1, which is running in VMWare Workstation Pro 16 and I got some error messages like:

Could you help how to fix the installation?
I have chosen the 1st option at the beginning of the process as I have Ubuntu.
Regards,
Torabi

@torabi12, I had the same problem and it looks like pip cannot resolve the version of the dependencies, I tested some versions but no success. @medpaf could you provide the package versions you used?

@joao-vitor-souza @torabi12 I run into this isse myself but have you tried to use the tool? Please ignore the error messages and try the tool. In my case everything works fine. If you run into problems let me know. Regards


do not replace the root logger unless the KIVY_REPLACE_ROOT_LOGGER en…

…v var is set

Closes https://github.com/kivy/kivy/issues/4322, and it causes an infinite recursion if the env var is not set. :|
from os import environ
# environ['KIVY_REPLACE_ROOT_LOGGER'] = ''

import logging

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(on_press=lambda *x: logging.warning('test'))

if __name__ == '__main__':
    TestApp().run()

This fixes the recursion: https://github.com/kivy/kivy/issues/4933#issuecomment-274269290, but the app exit may be logged twice as a result in certain cases, so the pr needs further work.


Future of graphcool article

note: I would post this in the forum but it hasn't let me login for months now, I tried signing up with my github account today and it still won't login - just says "authentication complete: click here to continue" and takes me to unauthenticated forum homepage again
What feature are you missing?
A blog post with the future of graphcool-framework
How could this feature look like in detail? Tradeoffs?
Now that the company is funded and rebranding as prisma can we get some official guidance as to the future of graphcool-framework? Most importantly, if/when it is going to be mandatory to migrate to prisma as that could take significant time and resources for some production environments.
Also would be nice to get some guidance on whether or not the 467 existing issues will be worked on, especially ones like #489 which severely cripple any production environment in the case that it has to recover data.

For my part, I'm migrating to prisma.
Rebranding to prisma, the lack of answers, the number of old bugs still not processed, no feedback, ...
I strongly hope to not make another bad choice with prisma and lose my time again !

Would really love some communication too, I'm trying to use graphcool instead of prisma+graphql-yoga because I don't want a node server (graphcool is scala AFAIK), but there hasn't been any releases/commits to graphcool in a while, and prisma cli seems to be getting features not available on graphcool, like seed importing.
I read that the idea was to make prisma the query engine for graphcool, so graphcool becomes a wrapper around prisma which provides authentification and other server features.