A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-January/076036.html below:

[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packagesPaul Moore p.f.moore at gmail.com
Wed Jan 9 16:18:34 CET 2008
On 09/01/2008, Christian Heimes <lists at cheimes.de> wrote:
> It's not an issue for experienced users. For the rest we can put a link
> in the start menu under Python 2.5 which opens a new explorer with the
> user package directory.

Um, I'm an experienced user and it's an issue for me...

The problem isn't so much knowing where the directory is, as that
tools (quite rightly) ignore (ie, hide!) hidden directories. For
example, 4NT (my command shell) doesn't auto-complete hidden directory
names by default, many tools' wildcard matching ignores them (always,
not just by default).

Blast, I said I wasn't going to start a big flamewar over Windows behaviour.

I haven't seen anyone propose that something intended to be edited by
a user be stored in a hidden directory (appdata) on Windows. As long
as that is the case, I don't care.

If you are suggesting that a file intended to be viewed/edited by a
user manually should go in AppData, then please be explicit. We can
then argue the concrete issues, rather than just theoretical
principles.

Paul.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4