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

Issue:
Completion issue on readline shell with CASE_SENSITIVE_COMPLETIONS
When using readline and set `$CASE_SENSITIVE_COMPLETIONS = False`.

```
$ mkdir usr && mkdir Users
$ cd ./u<TAB>
```

The `u` in second cmd will be eaten. No such issue with PTK.



Discussion:
Ah, okay.  I can see why this is happening.  I may be able to put in a fix today.

@adqm great! I spent some time but didn't get much.

However, problem would be solved if I put the following line in `~/.inputrc`:

```
set completion-ignore-case on
```

So it seems a consistent issue between `xonsh` and `readline` :)


Resolving patch:
diff --git a/xonsh/readline_shell.py b/xonsh/readline_shell.py
--- a/xonsh/readline_shell.py
+++ b/xonsh/readline_shell.py
@@ -26,7 +26,7 @@
 from xonsh.ansi_colors import partial_color_format, color_style_names, color_style
 from xonsh.environ import partial_format_prompt, multiline_prompt
 from xonsh.tools import print_exception
-from xonsh.platform import HAS_PYGMENTS, ON_WINDOWS, ON_CYGWIN, ON_DARWIN
+from xonsh.platform import ON_WINDOWS, ON_CYGWIN, ON_DARWIN
 
 pygments = LazyObject(lambda: importlib.import_module('pygments'),
                       globals(), 'pygments')
@@ -44,6 +44,9 @@
 _RL_STATE_DONE = 0x1000000
 _RL_STATE_ISEARCH = 0x0000080
 
+_RL_PREV_CASE_SENSITIVE_COMPLETIONS = 'to-be-set'
+
+
 def setup_readline():
     """Sets up the readline module and completion suppression, if available."""
     global RL_COMPLETION_SUPPRESS_APPEND, RL_LIB, RL_CAN_RESIZE, RL_STATE, readline
@@ -130,6 +133,20 @@ def teardown_readline():
         return
 
 
+def _rebind_case_sensitive_completions():
+    # handle case sensitive, see Github issue #1342 for details
+    global _RL_PREV_CASE_SENSITIVE_COMPLETIONS
+    env = builtins.__xonsh_env__
+    case_sensitive = env.get('CASE_SENSITIVE_COMPLETIONS')
+    if case_sensitive is _RL_PREV_CASE_SENSITIVE_COMPLETIONS:
+        return
+    if case_sensitive:
+        readline.parse_and_bind("set completion-ignore-case off")
+    else:
+        readline.parse_and_bind("set completion-ignore-case on")
+    _RL_PREV_CASE_SENSITIVE_COMPLETIONS = case_sensitive
+
+
 def fix_readline_state_after_ctrl_c():
     """
     Fix to allow Ctrl-C to exit reverse-i-search.
@@ -235,6 +252,8 @@ def parseline(self, line):
     def completedefault(self, text, line, begidx, endidx):
         """Implements tab-completion for text."""
         rl_completion_suppress_append()  # this needs to be called each time
+        _rebind_case_sensitive_completions()
+
         mline = line.partition(' ')[2]
         offs = len(mline) - len(text)
         if self.completer is None:


Test patch:
Repository: xonsh/xonsh

Issue:
Error with first command when some $PATH doesn't exist
Ohai buddies, I hope you're doing good ^__^

I just upgraded to latest git, and I seem to be having a systematic issue with the first command I'll type in any term/xonsh session (onwards it all works fine):

```
cheaterman@cmans-laptop ~ $ echo 'Owiii bliblibli ^__^'
xonsh: To log full traceback to a file set: $XONSH_TRACEBACK_LOGFILE = <filename>
Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 13095, in default
    run_compiled_code(code, self.ctx, None, 'single')
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 2876, in run_compiled_code
    func(code, glb, loc)
  File "<xonsh-code>", line 1, in <module>
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 15734, in subproc_captured_hiddenobject
    return run_subproc(cmds, captured='hiddenobject')
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 15515, in run_subproc
    binary_loc = locate_binary(cmd[0])
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 11592, in locate_binary
    return builtins.__xonsh_commands_cache__.locate_binary(name)
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 10761, in locate_binary
    _ = self.all_commands
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 10723, in all_commands
    for cmd in executables_in(path):
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 5567, in executables_in
    yield from func(path)
  File "/usr/lib64/python3.4/site-packages/xonsh/__amalgam__.py", line 5529, in _executables_in_posix
    for fname in os.listdir(path):
FileNotFoundError: [Errno 2] No such file or directory: '/opt/bin'
cheaterman@cmans-laptop ~ $ 
```

Seems to be complaining about /opt/bin which is in my $PATH but doesn't exist. I think this shouldn't fail as I never had an issue with it before?

Thanks in advance ^__^



Discussion:

Resolving patch:
diff --git a/xonsh/tools.py b/xonsh/tools.py
--- a/xonsh/tools.py
+++ b/xonsh/tools.py
@@ -481,7 +481,9 @@ def _yield_accessible_unix_file_names(path):
 
 
 def _executables_in_posix(path):
-    if PYTHON_VERSION_INFO < (3, 5, 0):
+    if not os.path.exists(path):
+        return
+    elif PYTHON_VERSION_INFO < (3, 5, 0):
         for fname in os.listdir(path):
             fpath  = os.path.join(path, fname)
             if (os.path.exists(fpath) and os.access(fpath, os.X_OK) and \


Test patch:
Repository: xonsh/xonsh

Issue:
starting xonsh creates `parse_table.py` file on cwd
```
> ls
cli_test  pyte
> python3 -m xonsh
(xonsh starts)
$ ls
cli_test  parser_table.py  pyte
```

anyone can reproduce?



Discussion:
Thanks for reporting @laerus! I don't see this issue on my machine.  This must come from the parser class looking for `xonsh.parser_table` and not finding it.  Can you verify please that your xonsh install directory has a parser_table.py file and that this file is being created when you install xonsh.  How are you installing xonsh?

yes there is a `parser_table.py` in xonsh root directory 
i install with: `python3 setup.py install --user`

should i try removing all `__pycache__` and installing again? <-- that didnt' work

edit:
also it seems like the `test_parser.py` file isn't being created on installation, its mod time is sometime yesterday

Well, what matters is the pychache where xonsh is installed to, not the one in the repo

Also, can you please show us the full install command and stdout that you use to install xonsh?


Resolving patch:
diff --git a/xonsh/parsers/base.py b/xonsh/parsers/base.py
--- a/xonsh/parsers/base.py
+++ b/xonsh/parsers/base.py
@@ -1,5 +1,6 @@
 # -*- coding: utf-8 -*-
 """Implements the base xonsh parser."""
+import os
 import re
 import time
 from threading import Thread
@@ -211,7 +212,8 @@ def __init__(self,
         yacc_debug : debug, optional
             Dumps extra debug info.
         outputdir : str or None, optional
-            The directory to place generated tables within.
+            The directory to place generated tables within. Defaults to the root
+            xonsh dir.
         """
         self.lexer = lexer = Lexer()
         self.tokens = lexer.tokens
@@ -267,8 +269,9 @@ def __init__(self,
                            tabmodule=yacc_table)
         if not yacc_debug:
             yacc_kwargs['errorlog'] = yacc.NullLogger()
-        if outputdir is not None:
-            yacc_kwargs['outputdir'] = outputdir
+        if outputdir is None:
+            outputdir = os.path.dirname(os.path.dirname(__file__))
+        yacc_kwargs['outputdir'] = outputdir
         self.parser = None
         YaccLoader(self, yacc_kwargs)
         #self.parser = yacc.yacc(**yacc_kwargs)


Test patch:
Repository: xonsh/xonsh

Issue:
TypeError: unorderable types: set() <= LazyObject()
Whereas prior builds were working, currently when I execute just-built xonsh from master I'm getting an error.

```
$ xonsh
Traceback (most recent call last):
  File "/home/pbr/xonsh/venv/bin/xonsh", line 3, in <module>
    main()
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 16710, in main
    args = premain(argv)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 16695, in premain
    shell = builtins.__xonsh_shell__ = Shell(**shell_kwargs)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 16439, in __init__
    kwargs.get('cacheall', False))
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 16483, in _init_environ
    debug_level=debug)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 16125, in __init__
    load_builtins(execer=self, config=config, login=login, ctx=xonsh_ctx)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 15965, in load_builtins
    builtins.__xonsh_env__ = env = Env(default_env(config=config, login=login))
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 12368, in default_env
    issue_warning=False)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 8855, in load_foreign_envs
    shell = ensure_shell(shell)
  File "/home/pbr/xonsh/venv/lib/python3.4/site-packages/xonsh/__amalgam__.py", line 8770, in ensure_shell
    if not (shell_keys <= VALID_SHELL_PARAMS):
TypeError: unorderable types: set() <= LazyObject()
```



Discussion:
I just noticed this also. Seems to be due to a change to xonsh/foreign_shells.py from 4819eb7. When the variable VALID_SHELL_PARAMS is changed back into a frozenset, instead of a LazyObject containing the frozenset, xonsh loads fine for me.  

Thanks for reporting! this is prolly cause we never call the `__getattribute__` of the LazyObject somehow before the ordering thus the frozenset object doesnt replace the LazyObject


Resolving patch:
diff --git a/xonsh/lazyasd.py b/xonsh/lazyasd.py
--- a/xonsh/lazyasd.py
+++ b/xonsh/lazyasd.py
@@ -81,6 +81,33 @@ def __call__(self, *args, **kwargs):
         obj = self._lazy_obj()
         return obj(*args, **kwargs)
 
+    def __lt__(self, other):
+        obj = self._lazy_obj()
+        return obj < other
+
+    def __le__(self, other):
+        obj = self._lazy_obj()
+        return obj <= other
+
+    def __eq__(self, other):
+        obj = self._lazy_obj()
+        return obj == other
+
+    def __ne__(self, other):
+        obj = self._lazy_obj()
+        return obj != other
+
+    def __gt__(self, other):
+        obj = self._lazy_obj()
+        return obj > other
+
+    def __ge__(self, other):
+        obj = self._lazy_obj()
+        return obj >= other
+
+    def __hash__(self):
+        obj = self._lazy_obj()
+        return hash(obj)
 
 
 def lazyobject(f):


Test patch:
Repository: xonsh/xonsh

Issue:
lazyjson - OSError: Bad file descriptor
this issue is bothering me for too long, a bug that appears 1 out of 5 times i startup xonsh:

```
$ XONSH_DEBUG=1 python3 -m xonsh
Exception ignored in: <bound method LazyJSON.__del__ of <xonsh.lazyjson.LazyJSON object at 0xb4a89fec>>
Traceback (most recent call last):
  File "/home/laerus/.local/lib/python3.4/site-packages/xonsh/lazyjson.py", line 212, in __del__
    self.close()
  File "/home/laerus/.local/lib/python3.4/site-packages/xonsh/lazyjson.py", line 217, in close
    self._f.close()
OSError: [Errno 9] Bad file descriptor
```

anyone else getting this? any ideas on debugging it? 



Discussion:
I don't see it, but I agree it is annoying.


Resolving patch:
diff --git a/xonsh/lazyjson.py b/xonsh/lazyjson.py
--- a/xonsh/lazyjson.py
+++ b/xonsh/lazyjson.py
@@ -214,7 +214,10 @@ def __del__(self):
     def close(self):
         """Close the file handle, if appropriate."""
         if not self.reopen and isinstance(self._f, io.IOBase):
-            self._f.close()
+            try:
+                self._f.close()
+            except OSError:
+                pass
 
     @contextlib.contextmanager
     def _open(self, *args, **kwargs):


Test patch:
Repository: xonsh/xonsh

Issue:
Document sequence attributes of the history object
``` python
self.tss = CommandField('ts', self)
self.inps = CommandField('inp', self)
self.outs = CommandField('out', self)
self.rtns = CommandField('rtn', self)
```

It turns out these are supposed to be the public interface to the history object but they scared me away because they're missing in [the documentation](http://xon.sh/api/history.html#xonsh.history.History)



Discussion:
Thanks for opening this @BlaXpirit!


Resolving patch:
diff --git a/xonsh/history.py b/xonsh/history.py
--- a/xonsh/history.py
+++ b/xonsh/history.py
@@ -505,7 +505,22 @@ def _hist_show(ns=None, hist=None, start_index=None, end_index=None,
 # Interface to History
 #
 class History(object):
-    """Xonsh session history."""
+    """Xonsh session history.
+
+    Attributes
+    ----------
+    rtns : sequence of ints
+        The return of the command (ie, 0 on success)
+    inps : sequence of strings
+        The command as typed by the user, including newlines
+    tss : sequence of two-tuples of floats
+        The timestamps of when the command started and finished, including
+        fractions
+    outs : sequence of strings
+        The output of the command, if xonsh is configured to save it
+
+    In all of these sequences, index 0 is the oldest and -1 (the last item) is the newest.
+    """
 
     def __init__(self, filename=None, sessionid=None, buffersize=100, gc=True,
                  **meta):


Test patch:
Repository: xonsh/xonsh

Issue:
type builtin, or some equivalent
In bash, you can use the `type` builtin to see if a command is a file, alias, or shell function. It would be useful to have this in xonsh, especially to tell if a command is coming from xonsh or from subprocess mode. Right now, type calls `/usr/bin/type` (not sure what that is all about). This would also be useful if xonsh ever implements PATH hashing. 

Note that `type` is also a command on Windows which means something else entirely. Bash also has `command -V` which is the same as `type`. 



Discussion:
Weird, I don't have `/usr/bin/type`. I agree though.  There needs to be some utility to determine what a command is.

Thanks for pointing out the oversight.

what about `whatis` as command name?

Is there a preferred name to call this builtin?

A quick look around the source code didn't uncover a straight-forward way to use the existing machinery to do this. Is there something I missed?

Hey @astronouth7303 -- it might not cover everything, but `xoreutils.which` is pretty good at this.  Especially with the `-v` flag.  

```
gil@bad_cat ~ $ which -v conda
aliases['conda'] = <function _xonda at 0x7f5f34244e18>
gil@bad_cat ~ $ which -v python
/home/gil/miniconda3/bin/python (from PATH element 0)
```

`which` is a logical place to put this functionality. One suggestion for improvement: `type` in bash gives the full source for functions:

```
$type sizeup
sizeup is a function
sizeup ()
{
    if [[ -z "$1" ]]; then
        DIR=.;
    else
        DIR="$1";
    fi;
    du -a -h -x "$DIR" | gsort -h
}
```

That shouldn't be too difficult.  We could add a flag to `which` to have it call `xonsh_superhelp`.  Or we could just have the `verbose` flag do that by default?

Hm. zsh just defines `type` as `which -v`.

Note that you should be able to get this by passing the function through `xonsh.built_ins.superhelp()`


Resolving patch:
diff --git a/xonsh/aliases.py b/xonsh/aliases.py
--- a/xonsh/aliases.py
+++ b/xonsh/aliases.py
@@ -396,12 +396,14 @@ def which(args, stdin=None, stdout=None, stderr=None):
         # skip alias check if user asks to skip
         if (arg in builtins.aliases and not pargs.skip):
             if pargs.plain or not pargs.verbose:
-                if isinstance(builtins.aliases[arg], list):
+                if not callable(builtins.aliases[arg]):
                     print(' '.join(builtins.aliases[arg]), file=stdout)
                 else:
                     print(arg, file=stdout)
             else:
                 print("aliases['{}'] = {}".format(arg, builtins.aliases[arg]), file=stdout)
+                if callable(builtins.aliases[arg]):
+                    builtins.__xonsh_superhelp__(builtins.aliases[arg])
             nmatches += 1
             if not pargs.all:
                 continue


Test patch:
Repository: xonsh/xonsh

Issue:
vox deactivate no longer resets my path
`which python3` returns the same thing before and after `vox deactivate` now.  `vox activate` correctly changes it, but `vox deactivate` no longer puts it back.  I am on the newest label of xonsh. 



Discussion:
Thanks for reporting @wreed4!  Pull requests most welcome for this for any vox users out there...

I can confirm. I guess I broke something in that rewrite...


Resolving patch:
diff --git a/xontrib/voxapi.py b/xontrib/voxapi.py
--- a/xontrib/voxapi.py
+++ b/xontrib/voxapi.py
@@ -178,7 +178,7 @@ def activate(self, name):
         if 'VIRTUAL_ENV' in env:
             self.deactivate()
 
-        type(self).oldvars = {'PATH': env['PATH']}
+        type(self).oldvars = {'PATH': list(env['PATH'])}
         env['PATH'].insert(0, bin_path)
         env['VIRTUAL_ENV'] = env_path
         if 'PYTHONHOME' in env:


Test patch:
diff --git a/tests/test_vox.py b/tests/test_vox.py
--- a/tests/test_vox.py
+++ b/tests/test_vox.py
@@ -43,3 +43,25 @@ def test_activate(xonsh_builtins, tmpdir):
     assert xonsh_builtins.__xonsh_env__['VIRTUAL_ENV'] == vox['spam'].env
     vox.deactivate()
     assert 'VIRTUAL_ENV' not in xonsh_builtins.__xonsh_env__
+
+
+@skip_if_on_conda
+def test_path(xonsh_builtins, tmpdir):
+    """
+    Test to make sure Vox properly activates and deactivates by examining $PATH
+    """
+    xonsh_builtins.__xonsh_env__['VIRTUALENV_HOME'] = str(tmpdir)
+    # I consider the case that the user doesn't have a PATH set to be unreasonable
+    xonsh_builtins.__xonsh_env__.setdefault('PATH', [])
+
+    oldpath = list(xonsh_builtins.__xonsh_env__['PATH'])
+    vox = Vox()
+    vox.create('eggs')
+
+    vox.activate('eggs')
+    
+    assert oldpath != xonsh_builtins.__xonsh_env__['PATH']
+    
+    vox.deactivate()
+    
+    assert oldpath == xonsh_builtins.__xonsh_env__['PATH']
Repository: xonsh/xonsh

Issue:
Invalid sys.argv when running a xonsh script
``` sh
$ cat test.py
#!/usr/bin/env python3
import sys
print(sys.argv)
$ ./test.py --hello world
['./test.py', '--hello', 'world']
$ python3 test.py --hello world
['test.py', '--hello', 'world']
$ sed -i s/python3/xonsh/ test.py
$ ./test.py --hello world
['--hello', 'world']
$ xonsh test.py --hello world
['--hello', 'world']
$ execx($(cat test.py))
['/usr/local/bin/xonsh']
$
```

As you can see, program name is not passed into `argv[0]`. This behaviour differs from _every other_ existing programming language, including Python. Thus, none of the option parsing libraries work with default settings, since they try to use `sys.argv[1:]`.
Hoping this is a bug that's going to be fixed, I'm using the following workaround for now:

``` py
if semver.match(re.search(r"([\w.-]+)\W*$", $(xonsh --version)).group(1), "<=0.4.4"):
    args = sys.argv
else:
    args = sys.argv[1:]
```

By the way, why does `xonsh --version` print a `repr` of a tuple?



Discussion:
Hey @SirNickolas thanks for reporting! This is an issue that was bugging me for some time, you can expect a fix soon or even try for a PR.


Resolving patch:
diff --git a/xonsh/main.py b/xonsh/main.py
--- a/xonsh/main.py
+++ b/xonsh/main.py
@@ -159,7 +159,7 @@ def premain(argv=None):
         parser.print_help()
         parser.exit()
     if args.version:
-        version = '/'.join(('xonsh', __version__)),
+        version = '/'.join(('xonsh', __version__))
         print(version)
         parser.exit()
     shell_kwargs = {'shell_type': args.shell_type,
@@ -224,8 +224,8 @@ def main(argv=None):
         # run a script contained in a file
         path = os.path.abspath(os.path.expanduser(args.file))
         if os.path.isfile(path):
-            sys.argv = args.args
-            env['ARGS'] = [args.file] + args.args
+            sys.argv = [args.file] + args.args
+            env['ARGS'] = sys.argv[:]  # $ARGS is not sys.argv
             env['XONSH_SOURCE'] = path
             run_script_with_cache(args.file, shell.execer, glb=shell.ctx,
                                   loc=None, mode='exec')


Test patch:
Repository: xonsh/xonsh

Issue:
`xonsh.completers.pip` explodes if `pip` is not on PATH
On my Windows installation, Python is not on PATH (because multiple Python madness), and therefore neither is pip. However, the pip completer [expects pip to be on the path](https://github.com/xonsh/xonsh/blob/master/xonsh/completers/pip.py#L14).

This causes the completer to blow up with a `FileNotFoundError` when it tries to complete.



Discussion:

Resolving patch:
diff --git a/xonsh/completers/pip.py b/xonsh/completers/pip.py
--- a/xonsh/completers/pip.py
+++ b/xonsh/completers/pip.py
@@ -11,8 +11,11 @@
 
 @xl.lazyobject
 def ALL_COMMANDS():
-    help_text = str(subprocess.check_output(['pip', '--help'],
-                                            stderr=subprocess.DEVNULL))
+    try:
+        help_text = str(subprocess.check_output(['pip', '--help'],
+                                                stderr=subprocess.DEVNULL))
+    except FileNotFoundError:
+        return []
     commands = re.findall("  (\w+)  ", help_text)
     return [c for c in commands if c not in ['completion', 'help']]
 
@@ -24,7 +27,11 @@ def complete_pip(prefix, line, begidx, endidx, ctx):
                          (not PIP_RE.search(line)):
         return
     if PIP_LIST_RE.search(line):
-        items = subprocess.check_output(['pip', 'list'], stderr=subprocess.DEVNULL)
+        try:
+            items = subprocess.check_output(['pip', 'list'],
+                                            stderr=subprocess.DEVNULL)
+        except FileNotFoundError:
+            return set()
         items = items.decode('utf-8').splitlines()
         return set(i.split()[0] for i in items)
 


Test patch:
Repository: xonsh/xonsh

Issue:
default value for $PATH seems strange in wizard
It's  `<xonsh.__amalgam__.LazyObject object at 0x7f6705929eb8>`. Current value is okay though.

I run fresh xonsh 0.4.3 on Ubuntu 16.04.



Discussion:
Hello, thank you for reporting this! this happens because we need to call the `__getattribute__` method on a LazyObject somehow in order to replace itself with the actual object. Simply putting something like `PATH_DEFAULT[0]` in `environ.py` before `DEFAULT_VALUES` dictionary is being set, fixes this problem, but there must be a more elegant way to this.

I think this is a matter of calling str or repr s directly 


Resolving patch:
diff --git a/xonsh/lazyasd.py b/xonsh/lazyasd.py
--- a/xonsh/lazyasd.py
+++ b/xonsh/lazyasd.py
@@ -116,6 +116,12 @@ def __or__(self, other):
         obj = self._lazy_obj()
         return obj | other
 
+    def __str__(self):
+        return str(self._lazy_obj())
+
+    def __repr__(self):
+        return repr(self._lazy_obj())
+
 
 def lazyobject(f):
     """Decorator for constructing lazy objects from a function."""
diff --git a/xonsh/proc.py b/xonsh/proc.py
--- a/xonsh/proc.py
+++ b/xonsh/proc.py
@@ -15,7 +15,6 @@
 import builtins
 import functools
 import threading
-import importlib
 import subprocess
 import collections
 import collections.abc as abc
@@ -24,7 +23,7 @@
 from xonsh.tools import (redirect_stdout, redirect_stderr, fallback,
                          print_exception, XonshCalledProcessError)
 from xonsh.teepty import TeePTY
-from xonsh.lazyasd import LazyObject, lazyobject
+from xonsh.lazyasd import lazyobject
 
 
 # force some lazy imports so we don't have errors on non-windows platforms


Test patch: