SWE-smith

Bug: Unexpected Behavior with TemplateNotFound Exception

Description

After a recent update, I'm encountering unexpected behavior when trying to handle templates that are not found. It seems like the TemplatesNotFound exception is not providing the expected template name in certain scenarios, which is causing issues in error handling logic.

Steps to Reproduce

1. Attempt to load a template that does not exist using the Jinja2 environment.
2. Catch the TemplatesNotFound exception.
3. Observe the template name provided in the exception message.

Expected Outcome

The exception should provide the name of the first template that was not found, allowing for proper error handling and logging.

Actual Outcome

The exception message does not consistently provide the expected template name, leading to confusion in identifying which template was missing.

Environment

• Jinja2 Version: Latest
• Python Version: 3.10.15
• Operating System: Linux

This issue is causing some of our error handling mechanisms to fail, as they rely on the template name being correctly identified in the exception. Any insights or fixes would be greatly appreciated!

String time formats not being parsed correctly in TimeFrameAttributeSunPy

What happened?

When trying to use string time formats in SunPy coordinates, I'm getting ValueError exceptions. The code is not properly handling string time formats that should be valid.

from sunpy.coordinates import frames
from astropy.time import Time

# This fails with ValueError
frame = frames.Helioprojective(obstime='2012/01/01T00:00:00')

Also, using 'now' as a time string doesn't work:

# This fails with ValueError: Invalid time input <unbound>='now'
from sunpy.coordinates.frameattributes import TimeFrameAttributeSunPy
attr = TimeFrameAttributeSunPy()
attr.convert_input('now')

What did you expect to happen?

I expected these string time formats to be properly parsed. SunPy should be able to handle various string time formats like '2012/01/01T00:00:00', '20120101000000', and '2012/01/01 00:00:00' through its parse_time utility. Also, the special string 'now' should be recognized and converted to the current time.

Minimal Complete Verifiable Example

from sunpy.coordinates import frames
from astropy.time import Time

# These all fail with ValueError
frame1 = frames.Helioprojective(obstime='2012/01/01T00:00:00')
frame2 = frames.Helioprojective(obstime='20120101000000')
frame3 = frames.Helioprojective(obstime='2012/01/01 00:00:00')

# This special case also fails
from sunpy.coordinates.frameattributes import TimeFrameAttributeSunPy
attr = TimeFrameAttributeSunPy()
result, converted = attr.convert_input('now')

Environment

• SunPy version: latest
• Python version: 3.11
• Operating system: Linux

Additional Information

The issue appears to be in the TimeFrameAttributeSunPy class in sunpy/coordinates/frameattributes.py. The code that handles string time inputs seems to be incorrectly processing these formats. The special case for 'now' also doesn't seem to be working properly.

Issue Text

Inconsistent Character Handling in TooManySymbolOrPunctuationPlugin

Description

The TooManySymbolOrPunctuationPlugin class in charset_normalizer/md.py is not correctly handling certain character conditions, leading to inaccurate symbol and punctuation counts.

Steps/Code to Reproduce

The issue arises when processing text with repeated characters or common ASCII characters. The logic intended to differentiate between symbols, punctuation, and other characters seems to be flawed.

Expected Results

The plugin should accurately count symbols and punctuation based on the character's properties and its relationship to the last processed character. Specifically, it should increment the symbol count only when a character is a symbol and not a digit or emoticon, and the punctuation count when a character is a punctuation mark.

Actual Results

The current implementation incorrectly increments the symbol count under certain conditions, such as when a character is not a digit or emoticon, but is a symbol. Additionally, the punctuation count logic does not account for repeated characters or common ASCII characters correctly.

Possible Causes

• The condition checking for the last printable character and common ASCII characters might be incorrectly structured, leading to unexpected behavior.
• The logic for determining when to increment the symbol and punctuation counts may not be correctly distinguishing between different character types.

This issue affects the accuracy of the plugin's detection capabilities, potentially leading to false positives or negatives in symbol and punctuation detection.

Multiple issues with Flask's context management

Description

I've discovered several critical issues with Flask's context management system that cause applications to crash or behave unexpectedly. The problems appear to be in the ctx.py file and affect the following functionality:

1. The _AppCtxGlobals.pop() method ignores the provided default value and always returns None when the key doesn't exist

2. The after_this_request function has inverted logic - it raises an error when a request context IS active (instead of when it's NOT active)

3. The AppContext.pop() method has several issues:

   • It incorrectly checks for token length
   • It ignores the exception parameter
   • It always passes None to do_teardown_appcontext
   • It pops from the beginning of the token list instead of the end
   • It has an inverted assertion check
   • It sends the wrong parameters to appcontext_popped.send

4. The RequestContext class initializes _cv_tokens as a tuple instead of a list, causing AttributeError when methods try to append to it

Steps to Reproduce

Here's a simple example that demonstrates one of the issues:

from flask import Flask, g, after_this_request

app = Flask(__name__)

@app.route('/')
def index():
    # This will raise an error with the inverted logic
    @after_this_request
    def add_header(response):
        response.headers['X-Custom'] = 'Value'
        return response
    
    # This will return None instead of the default value
    value = g.pop('non_existent_key', 'default_value')
    return f"Value: {value}"

if __name__ == '__main__':
    app.run(debug=True)

When running this application and accessing the root URL, you'll get a RuntimeError because the after_this_request function has inverted logic. Additionally, the g.pop() method will return None instead of the provided default value.

The issues with AppContext.pop() and RequestContext._cv_tokens cause more severe problems that break most Flask functionality, including request handling, session management, and template rendering.

Images not displaying in Word documents after adding them

I'm having an issue with adding images to Word documents using python-docx. When I try to add an image to a document, the image doesn't appear in the document at all.

Steps to reproduce

1. Create a new Word document
2. Try to add an image using the new_pic_inline method
3. The image doesn't appear in the document

Example code

from docx import Document

document = Document()
paragraph = document.add_paragraph()
run = paragraph.add_run()
# Add an image to the run
run.add_picture('my_image.png', width=100, height=200)
document.save('document_with_image.docx')

When I open the saved document, the image is missing completely.

Expected behavior

The image should appear in the document with the specified dimensions.

Actual behavior

No image appears in the document at all.

I also noticed that when I try to get the default style for a document, it's not working correctly. For example:

default_style = document.styles.default('paragraph')

This doesn't return the expected default style.

I'm using python-docx version 0.8.11 on Windows 10.

support block type strings in resnet Is your feature request related to a problem? Please describe. from https://github.com/Project-MONAI/MONAI/discussions/4678, the resnet input args should be able to understand strings in addition to the class types, the corresponding docstrings should be revised https://github.com/Project-MONAI/MONAI/blob/d99857cb49aab464ac38f7926ce4c6f299417721/monai/networks/nets/resnet.py#L173-L175

TOML parsing broken for timezone offsets and string handling

In [1]: import tomli
   ...: doc = '\n[bliibaa.diibaa]\noffsettime=[1979-05-27T00:32:00.999999-07:00]\n'
   ...: tomli.loads(doc)

ValueError: Expected datetime.datetime object, got {'bliibaa': {'diibaa': {'offsettime': [datetime.datetime(1979, 5, 27, 0, 32, 0, 999999, tzinfo=datetime.timezone(datetime.timedelta(hours=7)))]}}}

There are two major issues with the TOML parser:

1. Timezone offsets are being calculated incorrectly - a negative offset is being treated as positive and vice versa. In the example above, -07:00 is being interpreted as +07:00.

2. String parsing is broken, especially for multiline strings. For example:

In [2]: tomli.loads("v = '\n'")
TOMLDecodeError: Found invalid character '\n'

Additionally, the parser seems to have issues with the skip_until function which affects various parsing scenarios. This is causing valid TOML files to fail parsing and some invalid files to be accepted.

Categorical factor handling broken after recent changes

Description

After some recent changes, categorical factors are being processed incorrectly. The code seems to be treating categorical factors as numerical factors, which causes assertion errors and incorrect behavior.

Steps/Code to Reproduce

import patsy
import numpy as np

# Simple categorical factor example
data = {'x': ['a', 'b', 'c', 'a', 'b'], 'y': [1, 2, 3, 4, 5]}
formula = 'y ~ C(x)'

# This should work but now fails
try:
    result = patsy.dmatrix(formula, data)
    print("Success:", result)
except Exception as e:
    print("Error:", e)

The error occurs because the code is incorrectly asserting that categorical factors should be numerical:

Expected Behavior

Categorical factors should be handled properly with contrast matrices, not treated as numerical factors. The formula y ~ C(x) should create appropriate dummy variables for the categorical levels.

Actual Behavior

The code fails with assertion errors because it's trying to process categorical factors using the numerical factor code path, which includes assertions that the factor type should be "numerical".

KeyError raised when accessing deprecated keys in FeedParserDict

Description

After updating to the latest version, I've encountered an issue where accessing certain keys in the FeedParserDict raises a KeyError. This seems to happen with keys that have been deprecated and are supposed to have alternative mappings.

For example, when trying to access the 'license' key, which should map to an alternative key if available, a KeyError is raised instead of returning the expected value.

Steps to reproduce:

1. Create a FeedParserDict instance with a 'links' key containing a dictionary with 'rel' set to 'license' and 'href' set to a URL.
2. Attempt to access the 'license' key on the FeedParserDict instance.
3. Observe that a KeyError is raised instead of returning the 'href' value.

This behavior is unexpected and breaks the functionality that was previously working.

fallback() function doesn't handle callable-only approaches

Bug description

The fallback() function in flow.py doesn't properly handle the case when an approach is just a callable without explicit error types. According to the docstring, each approach should have a form of (callable, expected_errors), but the function should also accept just a callable as an approach, defaulting to catching all exceptions.

How to reproduce

from funcy.flow import fallback

def raiser():
    raise Exception("Error")

# This should work but fails
result = fallback(raiser, lambda: 1)

Current behavior

When passing a callable directly as an approach (without wrapping it in a tuple with error types), the function fails with:

Expected behavior

The function should accept both forms:

• (callable, expected_errors) tuple
• Just a callable, which should default to catching all exceptions

The function should try each approach in order, and return the result of the first one that doesn't raise an exception. If all approaches fail, it should re-raise the last exception.

Version information

funcy 1.17.0

Path parsing broken after recent changes

Description

Path parsing is completely broken and returns empty tuples for all path strings. This affects delta operations and path-based functionality throughout the library.

Steps/Code to Reproduce

from deepdiff.path import _path_to_elements

# Simple attribute access
result = _path_to_elements('root.hello', root_element=None)
print(f"Expected: [('hello', GETATTR)], Got: {result}")

# Array indexing
result = _path_to_elements("root[4]['b'][3]", root_element=None)
print(f"Expected: [(4, GET), ('b', GET), (3, GET)], Got: {result}")

# Mixed access
result = _path_to_elements('root[4].b[3]', root_element=None)
print(f"Expected: [(4, GET), ('b', GETATTR), (3, GET)], Got: {result}")

All of these return empty tuples () instead of the expected parsed path elements.

This also breaks delta operations:

from deepdiff import DeepDiff, Delta

t1 = {'field1': {'joe': 'Joe'}}
t2 = {'field1': {'joe': 'Joe'}, 'field2': {'James'}}
diff = DeepDiff(t1, t2)
delta = Delta(diff=diff, always_include_values=True)
# This will fail because path parsing is broken
result = t1 + delta

The path parsing function appears to have lost all its logic for handling brackets, dots, quotes, and other path syntax elements.

Slug generation fails with missing generator argument.

Description

After updating the slug method in the internet provider, I encountered an issue where the slug generation fails due to a missing 'generator' argument. This seems to affect multiple locales, including Japanese, Chinese, Hungarian, Polish, and others.

To reproduce the issue, you can try the following steps:

1. Initialize a Faker instance with any locale, for example, 'ja_JP'.
2. Attempt to generate a slug using faker.slug().
3. Observe the error message indicating a missing 'generator' argument.

Example:

from faker import Faker

faker = Faker('ja_JP')
print(faker.slug())

Expected behavior: The slug should be generated without errors.

Actual behavior: A TypeError is raised, stating that BaseProvider.__init__() is missing the required positional argument 'generator'.

This issue seems to be consistent across various locales and needs to be addressed to ensure slug generation works as expected.