Opening an issue for this problem since it has not yet been solved and is separate from the other I reported.
When importing objects that have no name attribute, an AttributeError occurs when iterating over the context objects to build up the context dict. Also, there is not necessarily a guarantee that a variable name matches its name attribute anyway.
The only approach I have found is to iterate over the dir of the import .konchrc module and check if the object is in the context list. While working on #99, it seemed natural to do this inside the get_config function that I was creating.
I think this issue may be easier to resolve once #99 is resolved, and possibly along with it.
One of my closed PRs has a test for this issue.

Look into https://github.com/jonathanslenders/ptpython/ support.

ptpython has its own user config file in "~/.ptpython/config", defined as configure. When it starts, it will first read the user's default configuration.

https://github.com/jonathanslenders/ptpython/blob/d00f8d454fe2b94c499869e6677cce7a22601fc4/ptpython/entry_points/run_ptipython.py#L81-L92

I think that konch should read the user's config first and then overwrite with konch configuration. Or add a method to use the user's config and then overwrite with konch configuration.

I am encountering a breaking bug that causes Konch to crash.
I am using Konch inside a venv using pipx, with Pandas, doing some data analysis.
Random commands raise the following exception (last command was dataframe["col"].values):

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/ptpython/completer.py in get_completions(self, document, complete_event)
    258             else:
    259                 # Move function parameters to the top.
--> 260                 jedi_completions = sorted(
    261                     jedi_completions,
    262                     key=lambda jc: (

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/ptpython/completer.py in <lambda>(jc)
    262                     key=lambda jc: (
    263                         # Params first.
--> 264                         jc.type != "param",
    265                         # Private at the end.
    266                         jc.name.startswith("_"),

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/jedi/api/classes.py in type(self)
    717             )
    718
--> 719         return super().type
    720
    721     def get_completion_prefix_length(self):

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/jedi/api/classes.py in type(self)
    187             for value in self._name.infer():
    188                 return value.api_type
--> 189         return self._name.api_type
    190
    191     @property

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/jedi/inference/names.py in __getattr__(self, name)
    618
    619     def __getattr__(self, name):
--> 620         return getattr(self._wrapped_name, name)
    621
    622     def __repr__(self):

~/.local/pipx/venvs/konch/lib/python3.8/site-packages/jedi/inference/value/klass.py in api_type(self)
     78         if self.tree_name is not None:
     79             definition = self.tree_name.get_definition()
---> 80             if definition.type == 'funcdef':
     81                 if function_is_property(definition):
     82                     # This essentially checks if there is an @property before

AttributeError: 'NoneType' object has no attribute 'type'

Is there any way that Konch can pick up everything that is brought into the namespace from a from module import * import command and put it in the context?

A number of tools I use have a way of importing like that to provide a number of handy things in the namespace, and it'd be great if Konch could pick them all up.

d:\xxx>konch init
Initialized konch. Edit .konchrc to your needs and run `konch` to start an interactive session.
d:\xxx>konch
Traceback (most recent call last):
  File "c:\python26\Scripts\konch-script.py", line 9, in <module>
    load_entry_point('konch==0.3.3', 'console_scripts', 'konch')()
  File "c:\Python26\lib\site-packages\konch.py", line 407, in main
    use_file(args['--file'])
  File "c:\Python26\lib\site-packages\konch.py", line 345, in use_file
    execute_file(config_file)
  File "c:\Python26\lib\site-packages\konch.py", line 70, in execute_file
    exec(compile(open(fname, "rb").read(), fname, 'exec'), globals_, locals_)
  File "d:\xxx\.konchrc", line 2
    import konch
                ^
SyntaxError: invalid syntax

But, after change newline character to '\n' or '\r', the error fixed.

I have multiple python environments and often prefer to run packages by specifying which python instance I would like to run under by running 'python -m cmd'. This works great.

I encountered an issue with Konch I was not able to easily correct. When running Konch in such a manner, the .konchrc file is processed, the setup() function is executed, but the context is not retained, and instead a blank context is used. It seems to be a scoping issue.

I was able to get it working properly by specifically setting '_cfg = mod.konch._cfg'. However, this seems to have upset mypy, so I don't know if this is an appropriate solution.

Let me know if I can be of further assistance.

Add some ANSI coloring. Should respect NO_COLOR (https://no-color.org/).

Please refer to issue: bpython/bpython#741
Cause: bpython/bpython#640

With BPython, currently SQLAlchemy commit operations don't work as expected. bpython-curses which comes bundled with bpython solves this.

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

close #211

konch -s notebook

This should open a Jupyter notebook with `context included.

Hi!

I wonder if konch is supposed to be run from (sub?)folders containing .konchrc files only (a bit like .git with Git) or from any system folder. I wonder if you considered user tricking other users into running konch with a malicious .konchrc file — on multi-user systems or through multi-file sources like Git clonse or extracted archives —, something that maybe would not be an issue, if .konchrc was declarative rather than Python code. What do you think?

Best, Sebastian

First I run konch init in my user home directory (~) and setup a working .konchrc file in that directory.

When I run konch I get the following error:

/usr/local/lib/python2.7/dist-packages/konch.py:342: UserWarning: No config file found.
  warnings.warn('No config file found.')
2.7.3 (default, Jan  2 2013, 16:53:07) 
[GCC 4.7.2]

Any other directories I tried worked fine. Only the home directory (~) seems affected.
If I ran konch init in ~/example/ or ~/other/ and used the same .konhrc file it would work as expected.

should fix a typo (sys.playform -> sys.platform) in konch.py

Common wisdom is to use stderr for messaging (including informational messages) and stdout only for operational output in order to support piping and redirection flows. Should we do it for konch?

Articles

• 12 Factor CLI Apps (section 4)
• CLI Design: handling output messages
• When to use STDERR instead of STDOUT

Examples

The following CLIs write informational messages (non-error, non-warning) to stderr:

• python (REPL) - All output goes to stderr
• docker-compose - See docker/compose#2115 (comment) . But there's a proposal to change this: docker/compose#6078 .
• gpg
• black
• heroku-cli
• curl

Counterexamples

The following CLIs write informational messages to stdout.

• ipython
• brew
• yarn and npm
• git, e.g. git init writes "Initialized empty Git repository" to stdout
• pre-commit
• ansible

Other considerations

If we do this, we'd want some way to distinguish errors vs. warnings vs. info messages. This article suggests two styles:

EDIT: We do this now.

The first style you can use is to write the ERROR and WARNING words in error and warning messages respectively, and leave informational messages alone. For example:

myprogram: ERROR: Must provide at least one URL.
myprogram: WARNING: Failed to connect to server; skipping.
myprogram: Connecting to http://www.example.com/...

The second style you can use is to write a single letter indicating the severity of the message and add that letter to every single message printed by the program. For example:

myprogram: E: Must provide at least one URL.
myprogram: W: Failed to connect to server; skipping.
myprogram: I: Connecting to http://www.example.com/...

From the XDG base directory spec:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

Rather than force anyone to migrate, a fallback strategy would be an option:

1. Check $XDG_CONFIG_HOME/konchrc.default
2. If not found, check $HOME/.config/konchrc.default
3. If not found, check $HOME/.konchrc.default

If you would be open to a PR on this, I could maybe put something together.