internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: hylang/hy

Issue:
Tests are failing on Python 3.10.0rc2
`(require tests.resources.macro-with-require)` leads to

```
…
  File "/home/hippo/Workspace/hyenv/hy/hy/macros.py", line 134, in require
    parent_frame = inspect.stack()[1][0]
  File "/home/hippo/Workspace/Python-3.10.0rc2/mybuild/lib/python3.10/inspect.py", line 1676, in stack
    return getouterframes(sys._getframe(1), context)
  File "/home/hippo/Workspace/Python-3.10.0rc2/mybuild/lib/python3.10/inspect.py", line 1653, in getouterframes
    frameinfo = (frame,) + getframeinfo(frame, context)
  File "/home/hippo/Workspace/Python-3.10.0rc2/mybuild/lib/python3.10/inspect.py", line 1625, in getframeinfo
    start = lineno - 1 - context//2
TypeError: unsupported operand type(s) for -: 'NoneType' and 'int
```

Evidently we failed to set a line number on a Hy model somewhere and the latest version of `inspect` needs it. I'm done fussing with this for today, but hopefully I'll find the guilty model sometime this coming week.


Discussion:
So I was able to track this down to the `rename_function` function in `hy/macros.py`. It's probably the case that we need to something to `code_obj_args`, but... I'm also not sure what the purpose of this function really is?

I replaced the call to `rename_function` with just updating `__name__` and `__qualname__` and all the tests pass on 3.10.0rc2, so maybe the need to muck about with the `co_*` fields was a holdover from python2?

```diff
diff --git a/hy/macros.py b/hy/macros.py
index f211c737..1dcc2363 100644
--- a/hy/macros.py
+++ b/hy/macros.py
@@ -73,7 +73,8 @@ def pattern_macro(names, pattern, shadow = None):
 
 def install_macro(name, fn, module_of):
     name = mangle(name)
-    fn = rename_function(fn, name)
+    fn.__name__ = name
+    fn.__qualname__ = name
     (inspect.getmodule(module_of).__dict__
         .setdefault('__macros__', {})[name]) = fn
     return fn
```
...oh, but now it's failing on python3.9. Hmm.

Resolving patch:
diff --git a/hy/macros.py b/hy/macros.py
--- a/hy/macros.py
+++ b/hy/macros.py
@@ -9,7 +9,7 @@
 
 from funcparserlib.parser import NoParseError
 
-from hy._compat import PY3_8
+from hy._compat import PY3_8, PY3_10
 from hy.model_patterns import whole
 from hy.models import replace_hy_obj, Expression, Symbol, as_model, is_unpack
 from hy.lex import mangle, unmangle
@@ -361,3 +361,5 @@ def rename_function(func, new_name):
                  'firstlineno', 'lnotab', 'freevars', 'cellvars']
 if not PY3_8:
     code_obj_args.remove("posonlyargcount")
+if PY3_10:
+    code_obj_args[code_obj_args.index("lnotab")] = "linetable"


Test patch:
Repository: hylang/hy

Issue:
Monkey-patching `py.path.local.pyimport` should no longer be necessary
Hi
I noticed **py** is used in conftest.py but not declared in any configuration files .
In addition, py as a Python library is deprecated as its [documentation](https://pypi.org/project/py/) "py.path: uniform local and svn path objects -> please use pathlib/pathlib2 instead"

Maybe it is necessary to migrate to new dependency-pathlib2 and add it to configuration files.


Discussion:
The reason we're importing `py` in `conftest.py` is just to monkey-patch `py.path.local.pyimport` in order to work around a bug that affected `pytest` (see `conftest.py`), which uses `py.path`. However, a little testing suggests that the monkey-patch is no longer necessary for the test suite to work, so we can probably drop this.
Thanks for your reply.
It seems that it should be solved. If py.path is no longer used, it should be removed from code.

Resolving patch:
diff --git a/conftest.py b/conftest.py
--- a/conftest.py
+++ b/conftest.py
@@ -4,15 +4,12 @@
 from operator import or_
 from functools import reduce
 
-import py
 import pytest
 import hy
 from hy._compat import PY3_8, PY3_10
 
 NATIVE_TESTS = os.path.join("", "tests", "native_tests", "")
 
-_fspath_pyimport = py.path.local.pyimport
-
 # https://github.com/hylang/hy/issues/2029
 os.environ.pop("HYSTARTUP", None)
 
@@ -30,30 +27,6 @@ def pytest_ignore_collect(path, config):
     ) or None
 
 
-def pyimport_patch_mismatch(self, **kwargs):
-    """Lame fix for https://github.com/pytest-dev/py/issues/195"""
-    try:
-        return _fspath_pyimport(self, **kwargs)
-    except py.path.local.ImportMismatchError:
-        pkgpath = self.pypkgpath()
-        if pkgpath is None:
-            pkgroot = self.dirpath()
-            modname = self.purebasename
-        else:
-            pkgroot = pkgpath.dirpath()
-            names = self.new(ext="").relto(pkgroot).split(self.sep)
-            if names[-1] == "__init__":
-                names.pop()
-            modname = ".".join(names)
-
-        res = importlib.import_module(modname)
-
-        return res
-
-
-py.path.local.pyimport = pyimport_patch_mismatch
-
-
 def pytest_collect_file(parent, path):
     if (path.ext == ".hy"
         and NATIVE_TESTS in path.dirname + os.sep


Test patch:
Repository: hylang/hy

Issue:
Add `project_urls` to `setup.py`
This would allow us to provide links to our GitHub repository etc. in a sidebar on PyPI.


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -66,5 +66,9 @@
         "Topic :: Software Development :: Code Generators",
         "Topic :: Software Development :: Compilers",
         "Topic :: Software Development :: Libraries",
-    ]
+    ],
+    project_urls={
+        "Documentation": "https://docs.hylang.org/",
+        "Source": "https://github.com/hylang/hy",
+    }
 )


Test patch:
Repository: hylang/hy

Issue:
Add header notice to "stable" line documentation to point users to the alpha cycle documentation
I was reading documentation and noticed that hy.contrib.walk is mentioned there:
https://docs.hylang.org/en/stable/contrib/walk.html

however it appears that hy.contrib.walk file is no longer on the master branch. 
https://github.com/hylang/hy/blob/6ba90fd3f853b2ddc391aa3358f9386c41d831c4/hy/contrib/walk.hy

is it a bug in documentation or I'm missing something? 




Discussion:
actually it looks ilke hy.contrib.walk only exists in the 0.20 version

are there any plans to support is for the version 1.0 and beyond? 
you are looking at the "stable" line of the documentation switch to "alpha" or "master" to see the latest documentation. Hy is in an alpha cycle as we pilot breaking changes that will go into 1.0. In that vein contrib along with a number of other library functions were moved to [hyrule](github.com/hylang/hyrule) to facilitate a more stable, organized language
I would like to add a header to the stable branch that will point users to the up to date documentation to mitigate this in the future. 
Decent idea. People looking at the wrong documentation has perpetually been a problem, even after I added the version headers, so some more emphasis is warranted.

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -56,7 +56,9 @@
 html_show_sphinx = False
 
 html_context = dict(
-    hy_descriptive_version = hy_descriptive_version)
+    hy_descriptive_version = hy_descriptive_version,
+    has_active_alpha = True,
+)
 
 highlight_language = 'clojure'
 


Test patch:
Repository: hylang/hy

Issue:
Allow `...` as shorthand for `Ellipsis` as in Python



Discussion:
Oddly, `...` and `Ellipsis` parse a little differently from each other in Python, or at least Python 3.9. `...` creates a `Constant` node whereas `Ellipsis` creates `Name`. So, assigning to a global variable `Ellipsis` will shadow `Ellipsis` but not `...`.

Resolving patch:
diff --git a/hy/compiler.py b/hy/compiler.py
--- a/hy/compiler.py
+++ b/hy/compiler.py
@@ -8,6 +8,7 @@
 
 from funcparserlib.parser import NoParseError, many
 
+from hy._compat import PY3_8
 from hy.errors import HyCompileError, HyLanguageError, HySyntaxError
 from hy.lex import mangle
 from hy.macros import macroexpand
@@ -594,6 +595,13 @@ def compile_numeric_literal(self, x):
 
     @builds_model(Symbol)
     def compile_symbol(self, symbol):
+        if symbol == Symbol("..."):
+            return (
+                asty.Constant(symbol, value=Ellipsis)
+                if PY3_8
+                else asty.Ellipsis(symbol)
+            )
+
         if "." in symbol:
             glob, local = symbol.rsplit(".", 1)
 


Test patch:
diff --git a/tests/native_tests/language.hy b/tests/native_tests/language.hy
--- a/tests/native_tests/language.hy
+++ b/tests/native_tests/language.hy
@@ -648,6 +648,16 @@
   (assert (= [1] output)))
 
 
+(defn test-ellipsis []
+  (global Ellipsis)
+  (assert (is ... Ellipsis))
+  (setv e Ellipsis)
+  (setv Ellipsis 14)
+  (assert (= Ellipsis 14))
+  (assert (!= ... 14))
+  (assert (is ... e)))
+
+
 (defn test-cut []
   (assert (= (cut [1 2 3 4 5] 3) [1 2 3]))
   (assert (= (cut [1 2 3 4 5] 1 None) [2 3 4 5]))
Repository: hylang/hy

Issue:
kwargs with symbolic :keywords as keys
This is more of an annoyance I probably will just learn to live with than anything else, but the following is counterintuitive (according to me).

```
(defn f1 [alpha beta] (* alpha beta))

(defn simple [] (f1 :alpha 3 :beta 7)) ;; works
(defn bad [] (f1 #**{:alpha 3 :beta 7})) ;; doesn't work
(defn good [] (f1 #**{"alpha" 3 "beta" 7})) ;; works
```
*I know* that (1) Lisp symbols are not naturally equivalent to strings and (2) `good` as defined above matches the closest to the behavior of `**kwargs` in Python. So what's really lacking is a comprehensive concept for mangling symbolic keywords -- and this for a behavior that one newbie finds off-putting. 

I wasn't planning on posting it as an issue, but issue #1765 points at something vaguely related in that his problem may not happen in a world where :keywords are already perceived by Python to be strings. One could want for example want `(f1 #**{:for 3 :with 7}))` to be interpreted as `f1(hy_for = 3, hy_with = 7)`.  This pseudo-solution is not good: it would need a redefinition of `defn` syntax  in a way that just breaks everything. Also: this may not be a problem for anybody else. 






Discussion:
> his problem may not happen in a world where :keywords are already perceived by Python to be strings

For what it's worth, this used to be the case. Earlier versions of Hy compiled HyKeyword objects not to themselves, as they currently do, but to strings (specifically, the text of the keyword preceded by a special Unicode character to hint that it was a keyword). The new behavior, which makes `(= :foo ':foo)` true, seems to generally work better.

Resolving patch:
diff --git a/hy/models.py b/hy/models.py
--- a/hy/models.py
+++ b/hy/models.py
@@ -294,7 +294,9 @@ def __bool__(self):
 
     def __call__(self, data, default=_sentinel):
         """Get the element of ``data`` named ``(hy.mangle self.name)``. Thus, ``(:foo
-        bar)`` is equivalent to ``(get bar (hy.mangle "foo"))``.
+        bar)`` is equivalent to ``(get bar "foo")`` (which is different from
+        ``(get bar :foo)``; dictionary keys are typically strings, not
+        :class:`hy.models.Keyword` objects).
 
         The optional second parameter is a default value; if provided, any
         :class:`KeyError` from :hy:func:`get` will be caught, and the default returned


Test patch:
Repository: hylang/hy

Issue:
Consider changing the Hy model objects' design
Since `HyKeyword` is inheriting from a non-`__slots__` object, I believe it will have a `__dict__` attribute anyway, in which case we would be missing out on some of the space-saving advantages of using `__slots__`.  To fix that 
 we can make `HyObject` use `__slots__`; however, this will clash with all the `HyObject` + primitive subclasses.  

If the Hy model objects held references to the actual primitives, instead of actually _being_ those primitives, this problem would be easily solved.

Otherwise, we can probably just use the `abc` and/or `collections.abc` interfaces.

_Originally posted by @brandonwillard in https://github.com/hylang/hy/issues/1924#issuecomment-731694498_


Discussion:
Better to just remove the `__slots__` entirely.

> If the Hy model objects held references to the actual primitives, instead of actually *being* those primitives

This strategy has some appeal. The annoying thing is that we'd need to add a lot of boilerplate methods to allow you to add a `HyInteger` to an `int`, to call `upper` on a `HyString`, etc. Maybe this could be worked around with `__getattr__`. I'm not clear in which cases `__getattr__` can substitute for a magic method.
@Kodiologist Even if `__getattr__` works in all cases like that, it could result in significantly slower (C)Python code, because CPython takes lots of special fast paths on basic types like numbers. There's some good discussion of this in https://www.youtube.com/watch?v=qCGofLIzX6g

Resolving patch:
diff --git a/hy/models.py b/hy/models.py
--- a/hy/models.py
+++ b/hy/models.py
@@ -248,7 +248,6 @@ class Keyword(Object):
       mangling is performed.
     """
 
-    __slots__ = ["name"]
     __match_args__ = ("name",)
 
     def __init__(self, value, from_parser=False):
@@ -311,19 +310,6 @@ def __call__(self, data, default=_sentinel):
                 raise
             return default
 
-    # __getstate__ and __setstate__ are required for Pickle protocol
-    # 0, because we have __slots__.
-    def __getstate__(self):
-        return {
-            k: getattr(self, k)
-            for k in self.properties + self.__slots__
-            if hasattr(self, k)
-        }
-
-    def __setstate__(self, state):
-        for k, v in state.items():
-            setattr(self, k, v)
-
 
 def strip_digit_separators(number):
     # Don't strip a _ or , if it's the first character, as _42 and


Test patch:
Repository: hylang/hy

Issue:
Slow startup when Hy is installed from a wheel
Testing the new release of 0.16.0, I see that startup is much slower when installing from the wheel than from the source distribution or directly from the repository. Likewise for older Hy releases. Even when I make sure the `__pycache__`s are included in the wheel and I can see they're installed. Either there's something wonky with my system, or wheel installation doesn't play nicely with premade byte-compiled files.


Discussion:
Maybe a bytecode version thing?  If you turn on debug, does it say it's recompiling?
Sorry, which debug mode do you mean? Should `HY_DEBUG` print such messages?
I was thinking of [`-d`](https://docs.python.org/3.6/using/cmdline.html#cmdoption-d).
I don't seem to get any messages about compilation from `python3 -d -m hy.core.language`.
Speed issues have gotten worse since the establishment of Hyrule, even when I've ensured that bytecode is pregenerated and installed. I think I may try to address them soon.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -5,6 +5,7 @@
 import fastentrypoints  # Monkey-patches setuptools.
 from get_version import __version__
 from setuptools import find_packages, setup
+from setuptools.command.install import install
 
 os.chdir(os.path.split(os.path.abspath(__file__))[0])
 
@@ -14,14 +15,34 @@
 make things work nicer, and lets Python and the Hy lisp variant play
 nice together. """
 
+
+class install(install):
+    def run(self):
+        super().run()
+        import py_compile
+        from glob import glob
+
+        import hy  # for compile hooks
+
+        for path in glob(os.path.join(self.install_lib, "**/*.hy"), recursive=True):
+            py_compile.compile(
+                path, invalidation_mode=py_compile.PycInvalidationMode.CHECKED_HASH
+            )
+
+
+# both setup_requires and install_requires
+# since we need to compile .hy files during setup
+requires = [
+    "funcparserlib ~= 1.0",
+    "colorama",
+    'astor>=0.8 ; python_version < "3.9"',
+]
+
 setup(
     name=PKG,
     version=__version__,
-    install_requires=[
-        "funcparserlib ~= 1.0",
-        "colorama",
-        'astor>=0.8 ; python_version < "3.9"',
-    ],
+    setup_requires=requires,
+    install_requires=requires,
     python_requires=">= 3.7, < 3.11",
     entry_points={
         "console_scripts": [
@@ -35,10 +56,7 @@
     },
     packages=find_packages(exclude=["tests*"]),
     package_data={
-        "hy": ["*.hy", "__pycache__/*"],
-        "hy.contrib": ["*.hy", "__pycache__/*"],
-        "hy.core": ["*.hy", "__pycache__/*"],
-        "hy.extra": ["*.hy", "__pycache__/*"],
+        "": ["*.hy"],
     },
     data_files=[("get_version", ["get_version.py"])],
     author="Paul Tagliamonte",
@@ -69,4 +87,7 @@
         "Documentation": "https://docs.hylang.org/",
         "Source": "https://github.com/hylang/hy",
     },
+    cmdclass={
+        "install": install,
+    },
 )


Test patch:
Repository: hylang/hy

Issue:
New release
It's time for a new release soon. Here are the things I'd like to get done, or at least try to get done, first. If you think you'll make a PR soon that you'd also like to get in for this release, mention that, too. Volunteers to take these tasks on are also welcome.

- ~#2291~; ~#2292~ - These are more difficult than I thought. I don't think I'm going to make the release wait for them.
- Install bytecode (for Hy and for Hyrule): hylang/hyrule#42; at least partly addresses #1747


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -61,9 +61,7 @@
 html_show_sphinx = False
 
 html_context = dict(
-    hy_descriptive_version=hy_descriptive_version,
-    has_active_alpha=True,
-)
+    hy_descriptive_version=hy_descriptive_version)
 
 highlight_language = "clojure"
 


Test patch:
Repository: hylang/hy

Issue:
F-strings don't allow `\N{…}`
```
Hy 0.24.0 using CPython(default) 3.9.6 on Darwin
=> (print "\N{slightly smiling face}")
🙂
=> (print f"\N{slightly smiling face}")
Traceback (most recent call last):
  File "stdin-eda06fe2e57521e633661e996d6216e5bab61d9b", line 1
    (print f"\N{slightly smiling face}")
               ^
hy.reader.exceptions.LexException: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: malformed \N character escape (<string>, line 1)
```

Python 3.9 works fine:
```
>>> print("\N{slightly smiling face}")
🙂
>>> print(f"\N{slightly smiling face}")
🙂
```


Discussion:
Good catch. The problem here is the curly braces, though, not emoji.

Resolving patch:
diff --git a/hy/reader/hy_reader.py b/hy/reader/hy_reader.py
--- a/hy/reader/hy_reader.py
+++ b/hy/reader/hy_reader.py
@@ -448,7 +448,7 @@ def read_chars_until(self, closing, prefix, is_fstring):
                 s = s[:-n_closing_chars]
                 break
             # check if c is start of component
-            if is_fstring and c == "{":
+            if is_fstring and c == "{" and s[-3:] != ["\\", "N", "{"]:
                 # check and handle "{{"
                 if self.peek_and_getc("{"):
                     s.append("{")


Test patch:
diff --git a/tests/native_tests/language.hy b/tests/native_tests/language.hy
--- a/tests/native_tests/language.hy
+++ b/tests/native_tests/language.hy
@@ -1109,6 +1109,11 @@ cee"} dee" "ey bee\ncee dee"))
       (+ "C[" format-spec "]")))
   (assert (= f"{(C) :  {(str (+ 1 1)) !r :x<5}}" "C[  '2'xx]"))
 
+  ; \N sequences
+  ; https://github.com/hylang/hy/issues/2321
+  (setv ampersand "wich")
+  (assert (= f"sand{ampersand} \N{ampersand} chips" "sandwich & chips"))
+
   ; Format bracket strings
   (assert (= #[f[a{p !r :9}]f] "a'xyzzy'  "))
   (assert (= #[f-string[result: {value :{width}.{precision}}]f-string]
Repository: hylang/hy

Issue:
Make a new release
You fixed the setup.py to support 3.11, please release that.


Discussion:
Ordinarily, we release twice a year, once around the middle and once around the end, but I agree an earlier release is warranted, since Python 3.11 is officially out now.

Resolving patch:
diff --git a/hy/core/result_macros.py b/hy/core/result_macros.py
--- a/hy/core/result_macros.py
+++ b/hy/core/result_macros.py
@@ -1895,7 +1895,8 @@ def compile_let(compiler, expr, root, bindings, body):
 
 
 @pattern_macro(
-    "unquote unquote-splice unpack-mapping except finally else".split(), [many(FORM)]
+    "unquote unquote-splice unpack-mapping except except* finally else".split(),
+    [many(FORM)],
 )
 def compile_placeholder(compiler, expr, root, body):
     raise ValueError(f"`{root}` is not allowed here")


Test patch:
diff --git a/tests/compilers/test_ast.py b/tests/compilers/test_ast.py
--- a/tests/compilers/test_ast.py
+++ b/tests/compilers/test_ast.py
@@ -579,14 +579,22 @@ def test_setv_builtins():
     )
 
 
-def test_top_level_unquote():
+def placeholder_macro(x, ename=None):
     with pytest.raises(HyLanguageError) as e:
-        can_compile("(unquote)")
-    assert "`unquote` is not allowed here" in e.value.msg
+        can_compile(f"({x})")
+    assert f"`{ename or x}` is not allowed here" in e.value.msg
 
-    with pytest.raises(HyLanguageError) as e:
-        can_compile("(unquote-splice)")
-    assert "`unquote-splice` is not allowed here" in e.value.msg
+
+def test_top_level_unquote():
+    placeholder_macro("unquote")
+    placeholder_macro("unquote-splice")
+    placeholder_macro("unquote_splice", "unquote-splice")
+
+
+def test_bad_exception():
+    placeholder_macro("except")
+    placeholder_macro("except*")
+    placeholder_macro(hy.mangle("except*"), "except*")
 
 
 def test_lots_of_comment_lines():
Repository: hylang/hy

Issue:
Escaped braces in bracket f-strings are doubled in the output
Python:

```
>>> f"{{foo}}"
'{foo}'
```

Hy, correct:

```
=> f"{{foo}}"
"{foo}"
```

Hy, incorrect:

```
=> #[f-[{{foo}}]f-]
"{{foo}}"
```


Discussion:

Resolving patch:
diff --git a/hy/reader/hy_reader.py b/hy/reader/hy_reader.py
--- a/hy/reader/hy_reader.py
+++ b/hy/reader/hy_reader.py
@@ -437,7 +437,7 @@ def delim_closing(c):
                     index = -1
             return 0
 
-        return self.read_string_until(delim_closing, None, is_fstring, brackets=delim)
+        return self.read_string_until(delim_closing, "fr" if is_fstring else None, is_fstring, brackets=delim)
 
     def read_string_until(self, closing, prefix, is_fstring, **kwargs):
         if is_fstring:


Test patch:
diff --git a/tests/native_tests/strings.hy b/tests/native_tests/strings.hy
--- a/tests/native_tests/strings.hy
+++ b/tests/native_tests/strings.hy
@@ -97,6 +97,10 @@ cee"} dee" "ey bee\ncee dee"))
   (assert (= #[f[a{p !r :9}]f] "a'xyzzy'  "))
   (assert (= #[f-string[result: {value :{width}.{precision}}]f-string]
     "result:      12.34"))
+  ; https://github.com/hylang/hy/issues/2419
+  (assert (=
+    #[f[{{escaped braces}} \n {"not escaped"}]f]
+    "{escaped braces} \\n not escaped"))
 
   ; Quoting shouldn't evaluate the f-string immediately
   ; https://github.com/hylang/hy/issues/1844