mteb/LocBenchRR huggingface dataset:
Potential hang in monomials during integration
In the example given below, the `intermonomials` function is called from the `heurisch` function of the integration process. The problem I encounter is that before calling `internomomials`, the script subs some expression with polynomials. The expressions look something like this, `(27000.0 - 6902.92767267848*exp(-1.66666666666667*s) - 24100.2086229868*exp(-s/120))*exp(k10*s)` and the mapping it uses to sub over this example would be, `[(exp(k10*s), _x1), (exp(-s/120), _x0), (exp(-1.66666666666667*s), _x3), (s, _x2)] `. As you can see, the third exponential is exactly the second one at the 200th power. So the subbed expression would come out as, `_x1*(-6902.92767267848*_x0**200 - 24100.2086229868*_x0 + 27000.0)`, which isn't false, but it causes the `intermonomials` to go on for hours (maybe days, I have never seen it end) in the `for variable in item:` loop at line 85.
```
import sympy as sy

Z0 = sy.Function('Z0')
Z1 = sy.Function('Z1')
k01, k10, t, s= sy.symbols('k01 k10 t s', real=True, positive=True)

m = sy.Matrix([[sy.exp(-k10*t)]])

[a, b, c, d, e, f, g] = [100, 0.5, 0.83, 50, 0.6, 2, 120]
AIF_btf = a*(d*e*(1-sy.exp(-(t-b)/e))+f*g*(1-sy.exp(-(t-b)/g)))
AIF_atf = a*(d*e*sy.exp(-(t-b)/e)*(sy.exp((c-b)/e)-1)+f*g*sy.exp(-(t-b)/g)*(sy.exp((c-b)/g)-1))
AIF_sym = sy.Piecewise((0, t < b), (AIF_btf, sy.And(b<=t, t<c)), (AIF_atf, c<=t))

aif_eq = sy.Eq(Z0(t), AIF_sym)
c_vec  = sy.Matrix([[Z1(t)]])
f_vec  = sy.Matrix([[k01*Z0(t)]])

integrand = m*(m.subs(t, s)**-1)*f_vec.subs(aif_eq.lhs, aif_eq.rhs).subs(t, s)
solution  = sy.integrate(integrand[0], (s, 0, t))
```
This behavior can be "hotfixed" in the `_subterms` function of `heurisch` by replacing the `return expr.subs(mapping)` of line 460 by `return expr.xreplace(dict(mapping))` but I know this probably would be far from an ideal fix. Maybe this doesn't actually need to be fixed and I'm just doing something wrong, too.

Now here is the interesting part, I first talked about this issue and #15494 in the gitter chat thinking they weren't related at all. But for some reason I don't understand, when applying the fix I just talked about, the behavior from #15494 disappeared. Also, since @normalhuman talked about how SymPy prefers working with known rationals, I tried replacing `[a, b, c, d, e, f, g] = [100, 0.5, 0.83, 50, 0.6, 2, 120]` with `[a, b, c, d, e, f, g] = [100, sy.Rational('0.5'), 0.83, 50, sy.Rational('0.6'), 2, 120]` and got NaN as the result of the integral. I then needed to use one of the fixes I proposed in #15494 to get the good result, but it all worked out in the end. Seeing as both issues seem related only in my code, I'm assuming my script is the source of the problem, but I've been searching for a while without success.
Tracking issue: inline docstrings
For many public APIs, JAX currently uses the `jax._src.numpy.util.implements` helper to define docstrings dynamically at runtime. This has several drawbacks:

1. The docstrings extracted from NumPy do not always precisely match the semantics of the associated JAX function. This leads to confusion for people reading these docs.
2. JAX-specific argument requirements should be documented: for example, some functions require particular parameters to be static, and we should document this.
3. The dynamic docstrings do not include example usage: we've stripped all examples from these dynamically-generated docs, because often JAX-specific logic is necessary.
4. Development environments like PyCharm are unable to show these dynamically-generated docs
5. For some submodules, the current logic necessitates runtime dependency on upstream packages (e.g. `jax.scipy` imports `scipy`), and this adds to the import-time startup cost.
6. Wrapped docstrings refer to symbols at import time, so if downstream libraries remove a symbol, JAX cannot be imported! This is currently causing problems for jax versions earlier than 0.4.27, because recent scipy removed symbols from its namespace.
7. The `implements` decorator, despite being correctly annotated, can cause some type checkers to not recognize the input/output annotations of the wrapped function (this has been observed with `pytype`)

The `implements` decorator was originally added as a way to quickly bootstrap development of the `jax.numpy` API, but that is no longer necessary. For all these reasons, we'd like to migrate to static, JAX-specific inline docstrings.

A challenge here is that we **cannot simply copy and modify the existing dynamic docstrings**: they come from `numpy`, and for licensing reasons, we cannot replicate NumPy docstring verbiage within the JAX repository. For this reason, each docstring must be rewritten from scratch, without referencing the text of the NumPy version of the documentation.
[Bug]: from vllm.platforms import current_platform infinite loop error with OpenVino Build. 
### Your current environment

Unrelated

### Model Input Dumps

Unrelated

### 🐛 Describe the bug

In OpenVino Build, from vllm.platforms import current_platform for OpenVino will...
 * reference openvino.py in vllm.platforms.openvino.py as OpenVino is identified as current platform
 * openvino.py line 4 will reference from vllm.utils import print_warning_once
 * vllm.utils line 40 will reference from vllm.platforms import current_platform
 * Due to circular self-reference, will throw error

This impacts any vllm functionality on the openvino build due to vllm requiring detection of the current_platform.

Resolution: **removing print_warning_once dependency from openvino.py will fix, either by defining print function locally or removing logging altogether from openvino.py**



### Before submitting a new issue...

- [X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the [documentation page](https://docs.vllm.ai/en/latest/), which can answer lots of frequently asked questions.
Remove useless `chunk_dicts`
### Summary

```diff
diff --git a/mlflow/openai/_openai_autolog.py b/mlflow/openai/_openai_autolog.py
index 149e92793..45e486808 100644
--- a/mlflow/openai/_openai_autolog.py
+++ b/mlflow/openai/_openai_autolog.py
@@ -158,7 +158,6 @@ def patched_call(original, self, *args, **kwargs):
                 yield chunk
 
             try:
-                chunk_dicts = []
                 chunk_dicts = [chunk.to_dict() for chunk in chunks]
                 if config.log_traces and request_id:
                     mlflow_client.end_trace(
```

### Notes

- Make sure to open a PR from a **non-master** branch.
- Sign off the commit using the `-s` flag when making a commit:

  ```sh
  git commit -s -m "..."
           # ^^ make sure to use this
  ```

- Include `#{issue_number}` (e.g. `#123`) in the PR description when opening a PR.
[BUG] No matching signature found on free-threaded Python code generation
### Describe the bug

Whilst testing SciPy for issues against free-threaded CPython 3.13 https://github.com/scipy/scipy/pull/21496, we have observed several instances of errors on functions that fuse dtypes, for some reason, these errors are being flagged when running tests under parallel conditions, and not under single threading.

```
__________________________________________________________________ test_label03[numpy] __________________________________________________________________
scipy/ndimage/tests/test_measurements.py:169: in test_label03
    out, n = ndimage.label(data)
        data       = array([1.])
        xp         = <module 'numpy' from '/home/rgommers/code/pixi-dev-scipystack/scipy/.pixi/envs/free-threading/lib/python3.13t/site-packages/numpy/__init__.py'>
scipy/ndimage/_support_alternative_backends.py:37: in wrapper
    result = func(*args, **kwds)
        args       = (array([1.]),)
        delegator  = <function binary_fill_holes_signature at 0x385421dfa00>
        func       = <function label at 0x385421de9c0>
        kwds       = {}
        module_name = 'ndimage'
        xp         = <module 'scipy._lib.array_api_compat.numpy' from '/home/rgommers/code/pixi-dev-scipystack/scipy/scipy/build-nogil-install/lib/python3.13t/site-packages/scipy/_lib/array_api_compat/numpy/__init__.py'>
scipy/ndimage/_measurements.py:218: in label
    max_label = _ni_label._label(input, structure, output)
        caller_provided_output = False
        ii         = 3
        input      = array([1.])
        need_64bits = False
        output     = array([-889028608], dtype=int32)
        structure  = array([ True,  True,  True])
_ni_label.pyx:200: in _ni_label._label
    ???
_ni_label.pyx:237: in _ni_label._label
    ???
_ni_label.pyx:93: in _ni_label.__pyx_fused_cpdef
    ???
E   TypeError: No matching signature found
```

The generated C code for the Cython instance is described in the following comment: https://github.com/scipy/scipy/pull/21496#discussion_r1850947457

I will provide a minimal reproducible example soon. 

cc @rgommers 

### Code to reproduce the behaviour:

_No response_

### Expected behaviour

_No response_

### OS

Linux

### Python version

3.13t

### Cython version

_No response_

### Additional context

_No response_
mypy doesn't flag continue/break/return in except*
**Feature**
continue/break/return in except* is a syntax error, see https://peps.python.org/pep-0654/#forbidden-combinations. 

```python
def foo():
    for _ in range(5):
        try:
            ...
        except* Exception:
            continue
        except* ValueError:
            break
        except* TypeError:
            return
```
```sh
$ mypy --python-version=3.11 foo.py
Success: no issues found in 1 source file
$ mypy --version
mypy 1.13.0 (compiled: yes)
```

**Pitch**
mypy does give an error if you try to combine `except` and `except*`, and as far as I know it flags all other syntax errors as well, so should probably handle this too. It might also cause users to adjust code to avoid `unreachable code` needlessly, when in fact they have bigger problems to fix first.
Massive performance regression in cKDTree.query with L_inf distance in scipy 0.17
Hi,

While running some of my own code, I noticed a major slowdown in scipy 0.17 which I tracked to the cKDtree.query call with L_inf distance.
I did a git bisect and tracked the commit that caused the issue -- the commit is :
58a10c2688398ab440de8d6d7b5fba29671df182
Here is the example program that finishes in ~ 10 seconds before this commit and pretty much never finishes after it

```
import scipy.spatial.ckdtree
import numpy as np
arr1 = np.random.uniform(size=(6000000, 3))
tree2 = scipy.spatial.ckdtree.cKDTree(arr1)
distances, ind = tree2.query(arr1, 1, p=np.inf)
```

I also checked that if I change the distance from L_inf to L_2, then program finishes pretty quickly. I also tried to stop the program with gdb a few times to see where the code is mostly spending the time on and it seems to be here scipy/spatial/ckdtree/src/query.cxx:311. I also tried to dig into the problematic commit but I don't know enough about ckdtree internals to suggest a patch. 

Thanks, 
 Sergey

If relevant, I'm seeing this issue on a both systems that I tried  64bit RHEL6.7 with gcc 4.4 and Debian 7.9 with gcc-4.7. In all the cases it is python 2.7
`flet build` creates bundle but running it gives `ImportError: No module named main` error
### Duplicate Check

- [X] I have searched the [opened issues](https://github.com/flet-dev/flet/issues) and there are no duplicates

### Describe the bug

Traceback (most recent call last):
  File "<string>", line 47, in <module>
  File "<frozen runpy>", line 222, in run_module
  File "<frozen runpy>", line 142, in _get_module_details
ImportError: No module named main


### Code sample

<details open><summary>Code</summary>

```python
print(error)
```

</details>


### To reproduce

...

### Expected behavior

_No response_

### Screenshots / Videos

<details open>
<summary>Captures</summary>

![Screenshot_2024-11-28-23-36-20-36_92b64b2a7aa6eb3771ed6e18d0029815](https://github.com/user-attachments/assets/e22fcd4a-eaa1-448f-8c61-51164c6cbae7)


</details>


### Operating System

Windows

### Operating system details

11

### Flet version

0.25

### Regression

No, it isn't

### Suggestions

_No response_

### Logs

<details open><summary>Logs</summary>

```console
[Paste your logs here]
```

</details>


### Additional details

_No response_
bug in dask.array.reshape_blockwise
**Minimal Complete Verifiable Example**:

```python
import dask.array

reshape_blockwise(dask.array.ones((3,)), shape=(3,), chunks=((3,),))
```
```
ValueError: Setting chunks is not allowed when reducing the number of dimensions.
```

cc @phofl
openbabel has contagious license
https://tldrlegal.com/license/gnu-general-public-license-v2
`sqlglot.optimizer.qualify_columns.qualify_columns` fails on `table.*` inside `UNION ALL`
### Explanation

When using `qualify_columns` on a SQL query that contains a `UNION ALL` and one of the statement uses the `SELECT table.*` notation, `qualify_columns` raises an `sqlglot.errors.OptimizeError: Unknown table: p` error.

### Fully reproducible code snippet

```py
from sqlglot import parse_one
from sqlglot.schema import MappingSchema
from sqlglot.optimizer.qualify_columns import qualify_columns

SQL_DIALECT = "snowflake"

print(qualify_columns(parse_one("""
SELECT p.*
FROM p

UNION ALL

SELECT p2.*
FROM p2
""", dialect="snowflake"), schema=MappingSchema(dialect=SQL_DIALECT)).sql(pretty=True, dialect=SQL_DIALECT))
```

Running this snippet raises an error:
```
Traceback (most recent call last):
  File "test_sqlglot.py", line 7, in <module>
    print(qualify_columns(parse_one("""
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "sqlglot/optimizer/qualify_columns.py", line 81, in qualify_columns
    _expand_stars(
  File "sqlglot/optimizer/qualify_columns.py", line 623, in _expand_stars
    raise OptimizeError(f"Unknown table: {table}")
sqlglot.errors.OptimizeError: Unknown table: p
```

Looks like, inside `_expand_stars`, `scope.sources` is an empty list. In that exact case, `scope` represents the entire query (with both SELECT and the UNION ALL in between), and `scope_type` is ROOT (not UNION).


Again, happy to make a PR.
DataCollatorForLanguageModeling is (unnecessary) slow
### System Info

- `transformers` version: 4.43.1
- Platform: Linux-3.10.0-1062.18.1.el7.x86_64-x86_64-with-glibc2.17
- Python version: 3.11.3
- Huggingface_hub version: 0.23.4
- Safetensors version: 0.4.3
- Accelerate version: 0.32.1
- Accelerate config: 	not found
- PyTorch version (GPU?): 1.13.0+cu117 (False)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using distributed or parallel set-up in script?: No


### Who can help?

@ArthurZucker

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

```
from transformers import AutoTokenizer
from transformers import DataCollatorForLanguageModeling

tokzr = AutoTokenizer.from_pretrained('bert-base-multilingual-cased', use_fast=False)

masker = DataCollatorForLanguageModeling(tokzr)
data = ['this is a very boring test sentence'] * 1000

for line in data:
    token_ids = tokzr.encode(line, return_tensors='pt')[0]
    #input_text, output_labels = masker.torch_mask_tokens(token_ids.view(1, -1))
```

### Expected behavior

I would expect this code to be not much slower when uncommenting the masking. However, uncommenting it makes the code 5 times slower. I have tried to profile where this happens, and it seems like it is mainly happening in finding the random words to replace with, as it gets the length of the vocabulary there which takes a long time (https://github.com/huggingface/transformers/blob/main/src/transformers/data/data_collator.py#L854). I am not sure how to make getting the length faster, but perhaps it can just be saved/cached?
DaskTaskRunner can not work together with `wait_for`
### Bug summary

When using the `DaskTaskRunner` using wait_for is broken. Using the `ThreadPoolTaskRunner` the same flow works just fine.

```py
from prefect import flow, task
from prefect.task_runners import ThreadPoolTaskRunner
from prefect_dask.task_runners import DaskTaskRunner

@task()
def task_a() -> bool:
    print("Task A")
    return True

@task()
def task_b() -> bool:
    
    print("Task B")
    return True


@flow(name='test_flow', log_prints=True, task_runner=DaskTaskRunner()) #ThreadPoolTaskRunner()
def main_flow():
    task_a_future = task_a.submit()
    task_b_future = task_b.submit(wait_for=[task_a_future])

    task_b_future.wait()


if __name__ == '__main__':
    main_flow()
```

generates the errors:


```
Exception ignored in: <function PrefectDaskFuture.__del__ at 0x00000199CFD7B4C0>
Traceback (most recent call last):
  File "C:\mambaforge\envs\prefect\Lib\site-packages\prefect_dask\task_runners.py", line 153, in __del__
    if self._final_state or self._wrapped_future.done():
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\mambaforge\envs\prefect\Lib\site-packages\distributed\client.py", line 378, in done
    return self._state.done()
           ^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'done'
Exception ignored in: <function PrefectDaskFuture.__del__ at 0x00000199CFD7B4C0>
Traceback (most recent call last):
  File "C:\mambaforge\envs\prefect\Lib\site-packages\prefect_dask\task_runners.py", line 153, in __del__
    if self._final_state or self._wrapped_future.done():
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\mambaforge\envs\prefect\Lib\site-packages\distributed\client.py", line 378, in done
    return self._state.done()
           ^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'done'
Exception ignored in: <function PrefectDaskFuture.__del__ at 0x00000199CFD7B4C0>
Traceback (most recent call last):
  File "C:\mambaforge\envs\prefect\Lib\site-packages\prefect_dask\task_runners.py", line 153, in __del__
    if self._final_state or self._wrapped_future.done():
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\mambaforge\envs\prefect\Lib\site-packages\distributed\client.py", line 378, in done
    return self._state.done()
           ^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'done'
```

Seems like wrapping the normal future is broken when wait_for is used. If we use the return value of task_a in task_b and skip the wait_for the behaviour under both TaskRunners is correct.

### Version info

```Text
Version:             3.0.10
API version:         0.8.4
Python version:      3.12.7
Git commit:          3aa2d893
Built:               Tue, Oct 15, 2024 1:31 PM
OS/Arch:             win32/AMD64
Profile:             ephemeral
Server type:         server
Pydantic version:    2.9.2
Integrations:
  prefect-dask:      0.3.1
```


### Additional context

_No response_
SECURITY: Requests module leaks passwords & usernames for HTTP Basic Auth
While looking at the MicroPython `requests` module (on the git HEAD), I noticed this:

If you make a request with HTTP basic auth (a username/password) and did not specify a headers dict, then I believe the username and password would be added to the default headers to be used for **every subsequent HTTP request**.  Even if that request is to a completely different server, which you don't trust with your username and password.  That's probably not a good idea.

I haven't verified this, it's just from reading the code, but someone should probably look into it.

This is because there is `headers={}` in the function prototype, specifying a default for the `headers` parameter.  But (at least in cPython) that same dictionary will get reused for every call that doesn't explicitly specify a `headers` parameter.  So if the function changes the `headers` dictionary - such as by adding an `Authorization` header - that change will be there for every future call of the function.  This is a known dangerous part of the Python language, you're not the first people to write this kind of bug.

To fix this, you could keep the auth headers separate from the `headers` variable.  Something like this (totally untested!) commit: https://github.com/jonfoster/micropython-lib/commit/92e9b2208814faa22ba3ff2a19cbc8e0c5210a47 - feel free to use that as a starting point.
SECURITY: Requests module leaks passwords & usernames for HTTP Basic Auth
While looking at the MicroPython `requests` module (on the git HEAD), I noticed this:

If you make a request with HTTP basic auth (a username/password) and did not specify a headers dict, then I believe the username and password would be added to the default headers to be used for **every subsequent HTTP request**.  Even if that request is to a completely different server, which you don't trust with your username and password.  That's probably not a good idea.

I haven't verified this, it's just from reading the code, but someone should probably look into it.

This is because there is `headers={}` in the function prototype, specifying a default for the `headers` parameter.  But (at least in cPython) that same dictionary will get reused for every call that doesn't explicitly specify a `headers` parameter.  So if the function changes the `headers` dictionary - such as by adding an `Authorization` header - that change will be there for every future call of the function.  This is a known dangerous part of the Python language, you're not the first people to write this kind of bug.

To fix this, you could keep the auth headers separate from the `headers` variable.  Something like this (totally untested!) commit: https://github.com/jonfoster/micropython-lib/commit/92e9b2208814faa22ba3ff2a19cbc8e0c5210a47 - feel free to use that as a starting point.
DOC: Update variables a and b to names consistent with comment documentation
### Pandas version checks

- [X] I have checked that the issue still exists on the latest versions of the docs on `main` [here](https://pandas.pydata.org/docs/dev/)


### Location of the documentation

https://github.com/pandas-dev/pandas/blob/main/pandas/core/computation/expressions.py

### Documentation problem

Lines 234 and 235 explain what a and b are in detail (left and right operands), but there are many of those same variables earlier in the file, making it harder to understand what they represent.

### Suggested fix for documentation

Assuming a and b represent right and left operands throughout each function, change these variable names to right_op and left_op instead throughout all functions to have more descriptive variable names