mteb/LocBenchRR huggingface dataset:
BUG: Data store error - AWS batch/step execution
**Environment:**
metaflow version: 2.12.29
Python 3.11 (Docker Image from public.ecr.aws/docker/library/python:3.11)
Running on AWS Batch

**Description:**
Tested with version 2.12.28 and it runs successfully, with this latest version we get:
Data store error: No completed attempts of the task was found for task `MyFlow/sfn-*/_parameters/*-params`.

Maybe worth mentioning that we include a json file into `MyFlow` like:
```

json_config = IncludeFile(
        name="my_config",
        required=True,
        help="The Configuration",
        default=f"./{PARAMS_JSON}",
    )

```
Slow load times for translation Opportunities
<!--
  - Thanks for taking the time to report a bug in the Oppia project.
  - Before filing a new issue, please do a quick search to check that it hasn't
  - already been filed on the [issue tracker](https://github.com/oppia/oppia/issues)._
  -->

**Describe the bug**
opportunitiessummaryhandler/translation takes 6-7 seconds to execute on production

**To Reproduce**
Steps to reproduce the behavior:
 1. Go to 'Oppia.org'
 2. Click on 'Translate text'
 3. Open network tab in inspector
 4. Select a language/ or click on the pagination icons
 4. See error

**Observed behavior**
Slow load times for translation opportunities

**Expected behavior**
Should have similar load times to question opportunities which are aprx 400 ms to 1 second vs 6- 7 seconds we are seeing here

**Screenshots**
![Screen Shot 2021-12-01 at 12 56 27 PM](https://user-images.githubusercontent.com/35385366/144312712-8388cf71-29a3-4000-83fa-0c93396f035d.png)
DOC: types for numpy.delete's obj argument don't cover all possibilities
### Issue with current documentation:

The docstring for `numpy.delete` specifues the type of the `obj` parameter as:
> **obj : _slice, int or array of ints_**

It seem it can also be anything that can be cast as an array of ints, including e.g. an iterator like `range(0,4,2)` or list of ints like `[0,2,3]`. I confirmed this by looking in the source and I think this line is where anything that isn't a slice, int or bool is cast as a `numpy.array`:

https://github.com/numpy/numpy/blob/83bf22579b6eaa8113f6cff67b10fd9524965f23/numpy/lib/_function_base_impl.py#L5317

This type specification also doesn't mention that `obj` can be an array of booleans.

### Idea or request for content:

I'd open a PR but am not sure the best wording. I'm looking for something like

> **obj : _slice, int, array of bools or anything that can be cast as an array of ints_**

but that seems a bit verbose. Perhaps there's some NumPy jargon that's more succinct?
Cache Patron's Active Loans
<!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->

On several pages (e.g. LoanStatus) we fetch the patron's active loans (which can be expensive) to see if they've borrowed a book (e.g. on the book page).

Ideally, we'd cache this every 5 minutes and invalidate within the /borrow endpoint. The one "gotcha" is if a patron borrows a book from archive.org, Open Library doesn't know how to bust the cache, but that should be okay because presumably this will be fixed within the 5 minute window.

Exploration required into whether cache actually works for this and how performance is impacted.
BinaryClassificationEvaluator returns np.float32() and np.float64()
I came across the problem where

```python
output_scores[similarity_fn_name] = {
  "accuracy": acc,
  "accuracy_threshold": acc_threshold,
  "f1": f1,
  "f1_threshold": f1_threshold,
  "precision": precision,
  "recall": recall,
  "ap": ap,
}
```

is returning outputs in `np.float32()` and `np.float64()` which cause problems during model saving, as the `json/encoder.py` sees those types as `not JSON serializable`.

By changing the code snippet to

```python
output_scores[similarity_fn_name] = {
  "accuracy": acc.item(),
  "accuracy_threshold": acc_threshold.item(),
  "f1": f1.item(),
  "f1_threshold": f1_threshold.item(),
  "precision": precision,
  "recall": recall.item(),
  "ap": ap.item(),
}
```

the elements get copied to a standard Python scalar each (note: `precision` already is) and then behave like expected during saving.
Optimize Face Centroid Calculations
If `Grid.face_lon` does not exist, `_populate_face_centroids()`, actually `_construct_face_centroids()` in it, takes extremely long for large datasets. For instance, the benchmark/profiling below is for a ~4GB SCREAM dataset, around 5 mins:

@rajeeja FYI: I'm already working on this and have gotten optimized results, which will be good for "cartesian" parts of the face center calculations, but you may want to look into the `Welzl` parts as well, i.e. `_populate_face_centerpoints()`.

<img width="1065" alt="Image" src="https://github.com/user-attachments/assets/9aba545f-0fdb-4a4c-b2be-b8fb9ffe087e" />
Client starts with blacked out / blocked UI with many sources
Steps to reproduce:

1. Create a server with 1000 source (`$ NUM_SOURCES=1000 make dev`)
2. Start the client and let it download the sources.
3. Stop the client.
4. Restart the client.

At step 4 the drawing of the UI appears to be blocked (I speculate this is perhaps the client loading locally stored sources and associated messages in a blocking manner). Once the UI is drawn it is completely responsive. See the following screenie for an example of this behaviour:

![blocked_startup](https://user-images.githubusercontent.com/37602/75795529-5e67d100-5d6a-11ea-8f48-a904833df6e6.gif)
Payload registry has to do a linear search to find payloads
https://github.com/aio-libs/aiohttp/blob/21f5f92a755dc5ac7225b5e76f561553cf86565e/aiohttp/payload.py#L97

There is a note that its inefficent.

We might be able to clean it up by giving each payload a key as part of the base class and then doing a dict lookup instead
[Data] `GroupedData.map_groups()` doesn't allow partial callables
### What happened + What you expected to happen

In [this PR](https://github.com/ray-project/ray/pull/45310), a new requirement was imposed on the `fn` callable given as input to [`GroupedData.map_groups()`](https://docs.ray.io/en/latest/data/api/doc/ray.data.grouped_data.GroupedData.map_groups.html#ray.data.grouped_data.GroupedData.map_groups): that it have a `__name__` attribute. Unfortunately, callables partially parametrized using [`functools.partial()`](https://docs.python.org/3/library/functools.html#functools.partial) have no such attribute, so passing them into `.map_groups()` raises an error: `AttributeError: 'functools.partial' object has no attribute '__name__'`. This did not happen prior to the linked PR.

It's not a huge deal, but it did cause code to break unexpectedly, and I guess technically is in conflict with the type annotations on this method.

```
In [1]: import functools

In [2]: callable(functools.partial(lambda x: x))
Out[2]: True

In [3]: functools.partial(lambda x: x).__name__
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[3], line 1
----> 1 functools.partial(lambda x: x).__name__

AttributeError: 'functools.partial' object has no attribute '__name__'
```

### Versions / Dependencies

`ray >= 2.21`
PY3.10
macOS 14.4

### Reproduction script

```python
>>> import functools
>>> import ray
>>> ds = ray.data.range(10)
>>> ds.groupby("id").map_groups(lambda x: x)  # this is fine
MapBatches(<lambda>)
+- Sort
   +- Dataset(num_rows=10, schema={id: int64})
>>> ds.groupby("id").map_groups(functools.partial(lambda x: x))  # this errors
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[8], line 1
----> 1 ds.groupby("id").map_groups(functools.partial(lambda x: x))

File ~/.pyenv/versions/3.10.13/envs/ev-detection-py310/lib/python3.10/site-packages/ray/data/grouped_data.py:253, in GroupedData.map_groups(self, fn, compute, batch_format, fn_args, fn_kwargs, fn_constructor_args, fn_constructor_kwargs, num_cpus, num_gpus, concurrency, **ray_remote_args)
    249         yield from apply_udf_to_groups(fn, batch, *args, **kwargs)
    251 # Change the name of the wrapped function so that users see the name of their
    252 # function rather than `wrapped_fn` in the progress bar.
--> 253 wrapped_fn.__name__ = fn.__name__
    255 # Note we set batch_size=None here, so it will use the entire block as a batch,
    256 # which ensures that each group will be contained within a batch in entirety.
    257 return sorted_ds._map_batches_without_batch_size_validation(
    258     wrapped_fn,
    259     batch_size=None,
   (...)
    271     **ray_remote_args,
    272 )

AttributeError: 'functools.partial' object has no attribute '__name__'
```

### Issue Severity

Low: It annoys or frustrates me.
[MNT]: More consistent color parameters for bar()
### Summary

From #29072. `bar()` supports

- `color` : color or list of color
- `edgecolor` : color or list of color
- `facecolor`: color

i.e.

- `facecolor` cannot take a sequence
- there are no plural aliase (e.g. `edgecolors`)
- likely (t.b.c.) the aliases also do not support sequences, similar to #28884

### Proposed fix

Make `facecolor` accept sequences and check that the parameter precedence among `color`, `edgecolor` and `facecolor` is reasonable and comparable with `scatter`, which can take an explicit color via `c` (equivalent to `color` here).

For now, I'd refrain from introducing plural aliase. `bar()` is originally and primarily a style-all-bars-identical function. Per-bar styling was added later on, and I don't think there's a strong need to support this additional use case with an added plural alias.
Task definition matters in terms of memory usage
As suggested by @Oufattole, this kind of config seems to use excessive amounts of memory (more than 400 GB on MIMIC-IV in my case)
![image](https://github.com/user-attachments/assets/36e87b96-d4b1-491b-b664-f1f39fd1d2ad)
using regex mitigates this:
![image](https://github.com/user-attachments/assets/827523c3-8a6e-4362-89c1-0177133762ee)

https://github.com/Oufattole/meds-torch/blob/main/MIMICIV_INDUCTIVE_EXPERIMENTS/configs/tasks/mortality/in_icu/first_24h.yaml

I'm not sure what the reason could be, but perhaps it's something to attend users to. Tested with es-aces 0.5.1 and command: `aces-cli --multirun hydra/launcher=joblib data=sharded data.standard=meds data.root="$MIMICIV_MEDS_DIR/data" "data.shard=$(expand_shards $MIMICIV_MEDS_DIR/data)" cohort_dir="$cohort_dir" cohort_name="$TASK_NAME"`
jax.lax.scan transforms dict keys to lower case when reporting mismatch in pytree structures
### Description

When `jax.lax.scan` reports an error due to mismatch in the pytree input/output structres, it transforms dict keys to lowercase.

Small repro:

```python
def f(loop_i, x):
  return {'T': jnp.array([0.5])}

init_val = {'t': jnp.array([1.0])}
jax.lax.fori_loop(0, 1, f, init_val)
```

Which leads to error:
```
TypeError: scan body function carry input and carry output must have the same pytree structure, but they differ:

The input carry component loop_carry[1] is a <class 'dict'> with pytree metadata ('t',) but the corresponding component of the carry output is a <class 'dict'> with pytree metadata ('t',), so the pytree node metadata does not match.
```

### System info (python version, jaxlib version, accelerator, etc.)

N/A
Performance Bug: Reading large compressed images takes huge time to process
Reading a compressed image takes (>10minutes), if the image is large-ish (>250kb)

## Environment

Which environment were you using when you encountered the problem?

```bash
$ python -m platform
Linux-5.15.146.1-microsoft-standard-WSL2-x86_64-with-glibc2.35

$ python -c "import pypdf;print(pypdf._debug_versions)"
pypdf==4.2.0, crypt_provider=('pycryptodome', '3.19.0'), PIL=9.5.0
```

## Code + PDF

This is a minimal, complete example that shows the issue:

```python
import sys
from datetime import datetime

from pypdf import PdfReader

def log(msg):
    print(f"[{datetime.now()}] {msg}\n")

file = sys.argv[1]

log("Reading File PyPDF..")
images = []
pypdf_reader = PdfReader(file)
for pidx, page in enumerate(pypdf_reader.pages, start=1):
    log(f"Reading page {pidx}")
    for iidx, image in enumerate(page.images, start=1):
        log(f"Processing Image {iidx}")
        images.append(image.image)
    log(f"Competed page {pidx}")
log("Completed Reading File PyPDF!")
```

Attached is a sample PDF I created that can reproduce this error. 
[file_with_image.pdf](https://github.com/py-pdf/pypdf/files/15305860/file_with_image.pdf)


The PDF can be added to the tests as well.


## Output

This is the complete output I see:
Look at the time difference between Image 6 and Image 7. It is close to 12 minutes

```
[2024-05-14 14:06:52.927018] Reading File PyPDF..
[2024-05-14 14:06:52.929346] Reading page 1
[2024-05-14 14:06:52.971993] Processing Image 1
[2024-05-14 14:06:52.993297] Processing Image 2
[2024-05-14 14:06:53.007304] Processing Image 3
[2024-05-14 14:06:53.021166] Processing Image 4
[2024-05-14 14:06:53.049529] Processing Image 5
[2024-05-14 14:06:53.051842] Processing Image 6

[2024-05-14 14:18:46.906472] Processing Image 7
[2024-05-14 14:18:47.088749] Processing Image 8
[2024-05-14 14:18:47.092159] Processing Image 9
[2024-05-14 14:18:47.099422] Processing Image 10
[2024-05-14 14:18:47.099513] Competed page 1
```
"Order of columns does not match" error should give an extra info about expected order
It is not clear what order we should provide when we see the error "Order of columns does not match":
```python
import pandas as pd
import dask.dataframe as dd

data = {
    'id': [1, 1, 1, 2, 2, 2],
    'date': pd.to_datetime(['2023-01-01', '2023-01-04', '2023-01-05', '2023-01-01', '2023-01-04', '2023-01-05']),
    'metric': [1,1,1,1,1,1]
}
pd_df = pd.DataFrame(data).astype({'id': 'int64', 'metric': 'int64', 'date': 'datetime64[ns]'})
df = dd.from_pandas(pd_df)

df = (
    df
    .groupby(by=['id'])
    .apply(lambda x: x.resample("D", on="date").sum().reset_index(), include_groups=True, meta={"metric": "int64", 'date': 'datetime64[ns]', 'id': 'int64'})
    .reset_index(drop=True)
)
display(df.dtypes)
display(df.compute())
```

The right order is:
```
meta={'date': 'datetime64[ns]', 'id': 'int64', "metric": "int64", }
```
but it isn't clear why

https://github.com/dask/dask/blob/e71d4361a57e7990e4a325021e6382877ac9ab49/dask/dataframe/utils.py#L437
Optimize storing fill_value to Array
Would be nice if when storing a scalar or an array that contains only the `fill_value` of the `Array`, the chunk is merely deleted (if it exists) instead of writing out a chunk that contains only the `fill_value` for all elements. The `Array` should behave identically in either case. The only benefit is that storage is cutdown automatically in this case. A situation where this may come up is when copying one `Array` to another.
Use FreeBusy API to generate scheduling time
https://developers.google.com/calendar/api/v3/reference/freebusy/query

I somehow missed this api / component for caldav apis and google api. We can use this in-place for generating availability times.
Allow `./` and `../` in paths when recursively including templates
Description
		
(last modified by Gabriel Nick Pivovarov)		
Hi. Currently, when trying to recursively include a Django template within itself using the include tag with a path that contains ./ or ../, Django raises a TemplateSyntaxError. However, using a path that does not contain ./ or ../ does not raise the error. When the error is raised, the debug toolbar describes it like this:
TemplateSyntaxError at /
The relative path ‘“./ul.html”’ was translated to template name ‘app/ul.html’, the same template in which the tag appears.
Here is an example of a template in a Django app called app with the path app/templates/app/ul.html that would produce the error given above:
<ul>
	{% for section in sections %}
		<li>
			<p>{{ section.name }}</p>
			{% if section.sections|length != 0 %}
				{% include "./ul.html" with sections=section.sections %}
			{% endif %}
		</li>
	{% endfor %}
</ul>
However, replacing the directory ./ul.html with the equivalent app/ul.html makes the error go away (assuming that the project's settings.py specifies APP_DIRS = True and the views and URLs are configured correctly). The actual paths are translated identically in both cases, and the behavior of the include tag should not depend simply on whether or not the path string uses ./ or ../ (or if it should, this is not documented in the Django documentation). Therefore, it seems that this is a bug. The expected behavior is that an error is only raised when recursively using the extends template, not when recursively using the include template.
Contrapositively, it appears that recursively extending a template using the extends tag with a path that does not contain ./ or ../ raises a TemplateDoesNotExist exception.
One possible fix is to modify the django/template/loader_tags.py file (​https://github.com/django/django/blob/main/django/template/loader_tags.py) such that the error is raised when a template attempts to extend itself (not when a template attempts to include itself, which would otherwise be valid). The error handling logic in question starts on line 267 of that file within the construct_relative_path function; perhaps it should only be used when called from the do_extends function.
Here is a relevant discussion in the Django forums: ​https://forum.djangoproject.com/t/template-recursion-why-does-django-not-allow-and/31689
DOC: methods in see also section in the  pandas.DataFrame.size  are not hyperlinks
### 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://pandas.pydata.org/docs/reference/api/pandas.DataFrame.size.html

### Documentation problem

In the see also section the `ndarray.size` method is listed, but it is not hyperlinks and thus the reader cannot navigate with ease but has to look for them instead. 

### Suggested fix for documentation

Add numpy.ndarray.size in the docstring.
Add 307 and 308 redirect response codes to django.shortcuts.redirect
Description
	 
Other than 301 and 302 response codes for redirects, there is also:
​https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
​https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
Currently, Django is unaware of these.
Proposal:
Add two new HTTP response classes for 307 and 308.
Enhance django.shortcuts.redirect with a new keyword argument preserve_method that, in combination with the existing permanent, decides which of the four redirect classes to use.
Add 307 and 308 redirect response codes to django.shortcuts.redirect
Description
	 
Other than 301 and 302 response codes for redirects, there is also:
​https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
​https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
Currently, Django is unaware of these.
Proposal:
Add two new HTTP response classes for 307 and 308.
Enhance django.shortcuts.redirect with a new keyword argument preserve_method that, in combination with the existing permanent, decides which of the four redirect classes to use.
Reuse cufft plan objects
Reusing a plan object have a significant impact in the complete fft performance. I measured a ~500us time drop.

We should try to create a `PlanAllocator` or a pool of plans to reuse objects according to the requested size.

(Plans allocate gpu memory so we have to be careful when reusing them).

CC @leofang @asi1024 @grlee77
Change in inference of overloads involving `Hashable` and `slice` now that `slice` is generic
**Bug Report**

Consider the following Python snippet, saved as `foo.pyi`:

```py
from typing import assert_type, overload, Hashable

class Foo: ...

class DataFrame:
    @overload
    def __getitem__(self, key: slice) -> DataFrame: ...
    @overload
    def __getitem__(self, key: Hashable) -> Foo: ...


df = DataFrame()
assert_type(df[1:], DataFrame)
assert_type(df[:2], DataFrame)
```

Prior to [the recent change to make `slice` generic in typeshed](https://github.com/python/typeshed/pull/11637), mypy used to emit no errors on this snippet. However, mypy on the `master` branch emits the following errors:

```
foo.pyi:7: error: Overloaded function signatures 1 and 2 overlap with incompatible return types  [overload-overlap]
foo.pyi:13: error: Expression is of type "Any", not "DataFrame"  [assert-type]
foo.pyi:14: error: Expression is of type "Any", not "DataFrame"  [assert-type]
```

The first error here seems reasonable to me, but it's unclear to me why mypy now infers `Any` as the result of the `df` subscriptions. This snippet is minimized from the sole new mypy_primer error reported in https://github.com/python/typeshed/pull/11637#issuecomment-2435268577.

**To Reproduce**

https://mypy-play.net/?mypy=master&python=3.12&gist=339ba7f72c9048770ce15d6dc75207a1

**Your Environment**

- Mypy version used: mypy 1.14.0+dev.2ebc690279c7e20ed8bec006787030c5ba57c40e (compiled: no)
BUG(duckdb): Compiling STRUCTs throws away field name info, which is sometimes needed
**Fully reproducible code snippet**
```python
import sqlglot
print(sqlglot.__version__)
# 25.28.1.dev12

inp = """SELECT CAST({'i':1, 's':'foo'} AS STRUCT("s" TEXT, "i" INT));"""
e = sqlglot.parse_one(inp, "duckdb")
actual = e.sql("duckdb")
print(actual)
# SELECT CAST(ROW(1, 'foo') AS STRUCT("s" TEXT, "i" INT));
```

If you run `actual` on https://shell.duckdb.org/, you get "Conversion Error: Could not convert string 'foo' to INT32".
This is because the names of the fields is important, and the simple `(ROW(1, 'foo')` that is currently given as output isn't adequate for this usage.

I would expect that `actual == inp`. I think this should work even if the struct values are columns instead of literals, eg `{'i':my_int_col, 's':my_str_col}` should roundtrip exactly.

I originally found this in [this ibis issue](https://github.com/ibis-project/ibis/issues/10417), but I think this should be fixed at the sqlglot level. Curious if you will agree.
Conditional decorated functions are not type checked
**Bug Report**

Going through Mypy's tests, I realized that some tests are passing that shouldn't. This involves for example:

- `testConditionalFunctionDefinitionUsingDecorator3` (there's an error in the test that the test author probably didn't notice: Positional only args of a callable are never assignable to a normal function with positional-or-keyword params; typically an error in Mypy would look like this: `Incompatible redefinition (redefinition with type "Callable[[int], None]", original type "Callable[[Arg(int, 'x')], None]")`)
- `testConditionalFunctionDefinitionUsingDecorator4` (there's even a TODO in there that complains about this not being done)
- `testNewAnalyzerConditionalDecoratedFunc`

**To Reproduce**

```python
from typing import Callable
def dec(f) -> Callable[[int], None]: raise NotImplementedError

if int():
    def f(x: str): pass
else:
    @dec
    def f() -> None: pass   
```

https://mypy-play.net/?mypy=latest&python=3.12&gist=18b131da809d740eced20dd7652ea213

**Expected Behavior**

It would be nice if Mypy complained here (like in AFAIK all other conditional definitions).

I'm happy to assist if somebody wants to fix this.
[Feature]: phi-3.5 is a strong model for its size, including vision support.  Has multi-image support, but vllm does not support
### 🚀 The feature, motivation and pitch

phi-3.5 is a strong model for its size, including strong multi-image vision support.   But vllm does not support the multi-image case.

https://github.com/vllm-project/vllm/blob/03b7bfb79b1edf54511fd1b12acc9a875cee5656/vllm/model_executor/models/phi3v.py#L421-L425

### Alternatives

Only other models

### Additional context

_No response_