Re: Generic dictionary

[Thorsten Kampe]

* Chris Angelico (Sun, 20 Nov 2016 23:35:52 +1100)
> I see. So you want to be able to have something that looks and 
> feels
> like a dictionary, but uses a different way of looking things up.
> Makes reasonable sense, on the surface.
> 
> Before you go down that route, I strongly recommend reading up on
> exactly *why* a dictionary has the requirement of hashability, and
> what the consequences are of trying to look things up using lists as
> keys. You can easily experiment with it like this:
> 
> class HashableList(list):
> def __hash__(self):
> return hash(tuple(self))
> 
> Use those in your dict, rather than vanilla lists. Then you can mess
> around with the consequences of mutable dict keys.
> 
> Alternatively, switch from using lists to using tuples. They're
> hashable and immutable, thus avoiding the problems. If what you're
> trying to do is use multi-part dict keys, a tuple is far and away the
> best solution.

Chris, it's up to the consumer to decide which key/keyfunc to use. 
The lists as keys (that is first element in an tuple) are created on 
the fly and not used for anything. They are mutable but not mutated.

Mutating the list would be like mutating a list you're iterating 
through: just don't do it.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Generic dictionary

[Thorsten Kampe]

* Steve D'Aprano (Sun, 20 Nov 2016 22:40:19 +1100)
> 
> Further thoughts come to mind, after looking more closely at your code.
> 
> On Sun, 20 Nov 2016 08:27 pm, Thorsten Kampe wrote:
> 
> > def values(inst):
> > if isinstance(inst._generic, dict):
> > return inst._generic.values()
> > else:
> > try:
> > return list(zip(*inst._generic))[1]
> > except IndexError:  # empty GenericDict
> > return ()
> 
> That's... weird. Sometimes your instance will return a list, and sometimes a
> tuple. So if you write code expecting a list, it will suddenly and
> unexpectedly break when the instance is empty.
> 
> A better way of writing this is:
> 
> def values(inst):
> if isinstance(inst._generic, dict):
> return inst._generic.values()
> else:
> return [t[1] for t in inst._generic]

You are right, I modified it to
`return [value for key, value in inst._generic]`
...which is more more intelligible than my original try/except/list
(zip)

Thanks, Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Generic dictionary

[Thorsten Kampe]

* Steve D'Aprano (Sun, 20 Nov 2016 21:10:08 +1100)
> 
> On Sun, 20 Nov 2016 08:27 pm, Thorsten Kampe wrote:
> 
> > I'd like to extend the dictionary class by creating a class that acts
> > like a dictionary if the class is instantiated with a dictionary and
> > acts like a "dictitem" ([(key1, value1), (key2, value2), ...]) if
> > instantiated with a list (that is dictitem).
> 
> I'm not sure exactly what you are trying to accomplish here. You want a
> single class that sometimes behaves like a dict, and sometimes behaves like
> a list? Not just any list, but specifically a list of tuples of two items.

Treating a list of tuples as a substitute for a dictionary is a well 
established idiom (think list(dict.items()) and dict()).
 
> Frankly, that sounds... weird. Generally speaking, classes don't behave
> differently according to how they are created.

I think, you misinterpreted my question. It's not about behaving 
differently but the opposite: a streamlined interface for the caller 
so the caller does not have to worry whether it uses a dict or a 
dictitem.

See my response to Peter:
The use case is an Equivalence class which creates a {invariant(x): 
[x, y, z] ...} dictionary. Since the Equivalence class should accept 
all kinds of key functions, I have to make sure that lists (which are 
not hashable), etc. can be handled as keys.

The GenericDict class allows the Equivalence class to be agnostic 
regarding the underlying data structure. It tries to create a 
dictionary and if that fails uses a dictitem. All method calls are 
the same because that's handled by GenericDict.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Generic dictionary

[Thorsten Kampe]

* Anny Mous (Sun, 20 Nov 2016 21:46:25 +1100)
> 
> On Sun, 20 Nov 2016 08:43 pm, Peter Otten wrote:
> 
> > Thorsten Kampe wrote:
> > 
> >> [Crossposted to tutor and general mailing list]
> >> 
> >> Hi,
> >> 
> >> I'd like to extend the dictionary class by creating a class that acts
> >> like a dictionary if the class is instantiated with a dictionary and
> >> acts like a "dictitem" ([(key1, value1), (key2, value2), ...]) if
> >> instantiated with a list (that is dictitem).
> [...]
> > def GenericDict(dict_or_items):
> > if isinstance(dict_or_items, dict):
> > return dict(dict_or_items)
> > else:
> > return SimpleGenericDictWithOnlyTheFalseBranchesImplemented(
> > dict_or_items
> > )
> 
> 
> Personally, I'd go even simpler:
> 
> dict(dict_of_items)
> 
> will return a dict regardless of whether you start with another dict or a
> list or tuples.

The whole point of my posting was non hashable keys (like lists):

```
>>> dictitem
[([1], '11'), ([2], '22'), ([4], '33'), ([3], '44')]
>>> dict(dictitem)
-
TypeError   Traceback (most recent call last)
 in ()
> 1 dict(dictitem)

TypeError: unhashable type: 'list'
```

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Generic dictionary

[Thorsten Kampe]

* Peter Otten (Sun, 20 Nov 2016 10:43:01 +0100)
> 
> Thorsten Kampe wrote:
> > 
> > I'd like to extend the dictionary class by creating a class that acts
> > like a dictionary if the class is instantiated with a dictionary and
> > acts like a "dictitem" ([(key1, value1), (key2, value2), ...]) if
> > instantiated with a list (that is dictitem).
> > 
> > The code (see extract at bottom) works well but it contains a lot of
> > "if this is a dictionary then do as a dictionary already does"
> > boilerplate code". How can I "inherit"(?)/"subclass"(?)/derive from
> > dict so I don't have to write the code for the dictionary case?
> 
> Hm.
> 
> def GenericDict(dict_or_items):
> if isinstance(dict_or_items, dict):
> return dict(dict_or_items)
> else:
> return SimpleGenericDictWithOnlyTheFalseBranchesImplemented(
> dict_or_items
> )

That would be a kind of factory function for the class?
 
> > ```
> > class GenericDict:
> > """
> > a GenericDict is a dictionary or a list of tuples (when the keys
> > are not hashable)
> > """
> > def __init__(inst, generic_dict):
> > inst._generic = generic_dict
> > 
> > def __getitem__(inst, key):
> > if isinstance(inst._generic, dict):
> > return inst._generic[key]
> > else:
> > return inst.values()[inst.keys().index(key)]
> 
> It's not obvious why you'd ever want that. What's the use case?

The use case is an Equivalence class which creates a {invariant(x): 
[x, y, z] ...} dictionary. Since the Equivalence class should accept 
all kinds of key functions, I have to make sure that lists (which are 
not hashable), etc. can be handled as keys.

Treating a list of tuples as a substitute for a dictionary is a well 
established idiom (think list(dict.items()) and dict()).

The GenericDict class allows the Equivalence class to be agnostic 
regarding the underlying data structure. It tries to create a 
dictionary and if that fails uses a dictitem. All method calls are 
the same because that's handled by GenericDict.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Generic dictionary

[Thorsten Kampe]

[Crossposted to tutor and general mailing list]

Hi,

I'd like to extend the dictionary class by creating a class that acts 
like a dictionary if the class is instantiated with a dictionary and 
acts like a "dictitem" ([(key1, value1), (key2, value2), ...]) if 
instantiated with a list (that is dictitem).

The code (see extract at bottom) works well but it contains a lot of 
"if this is a dictionary then do as a dictionary already does" 
boilerplate code". How can I "inherit"(?)/"subclass"(?)/derive from 
dict so I don't have to write the code for the dictionary case?

Thorsten

```
class GenericDict:
"""
a GenericDict is a dictionary or a list of tuples (when the keys
are not hashable)
"""
def __init__(inst, generic_dict):
inst._generic = generic_dict

def __getitem__(inst, key):
if isinstance(inst._generic, dict):
return inst._generic[key]
else:
return inst.values()[inst.keys().index(key)]

def values(inst):
if isinstance(inst._generic, dict):
return inst._generic.values()
else:
try:
return list(zip(*inst._generic))[1]
except IndexError:  # empty GenericDict
return ()

def keys(inst):
if isinstance(inst._generic, dict):
return inst._generic.keys()
else:
try:
return list(zip(*inst._generic))[0]
except IndexError:  # empty GenericDict
return ()
```

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to test for type or instance of dict_values?

[Thorsten Kampe]

* Peter Otten (Thu, 17 Nov 2016 13:38:26 +0100)
> 
> Thorsten Kampe wrote:
> 
> > How can I test for type or instance of dictviews like dict_values?
> 
> Why do you want to?

Thanks, for the `collections.abc.ValuesView` tip.

The code in question is part of an attempt to get the dimensions of 
multi-dimensional lists, the `isinstance` is there in order to 
exclude strings.

"""
def dim(seq):
dimension = []
while isinstance(seq, (list, tuple)):
dimension.append(len(seq))
try:
seq = seq[0]
except IndexError:  # sequence is empty
break
return dimension
"""

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

How to test for type or instance of dict_values?

[Thorsten Kampe]

How can I test for type or instance of dictviews like dict_values?

`isinstance({}.values, dict_values)` gives
`NameError: name 'dict_values' is not defined`

"""
>>> type({}.values())

"""

Thorsten


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

* eryk sun (Fri, 11 Nov 2016 09:55:23 +)
> 
> If it works like cmd.exe, then it does its own search using %Path% 
> and %PathExt%. For example:
> 
> C:\>cmd /c "set "PATH=" & cmd"
> 'cmd' is not recognized as an internal or external command,
> operable program or batch file.
> 
> But why should subprocess.Popen implement its own search like the
> shell instead of relying on CreateProcess to search for the
> executable? You'd have to come up with an argument to convince the
> devs to change the behavior in 3.7.

My goal is to verify that other shells/interpreters on Windows work 
the same way as Python when running an application or creating a sub-
process. Cmd does not. What's else there? I have Bash here but that's 
a Cygwin executable. And Cygwin Python does not work like Windows 
Python.

Any ideas?

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

* eryk sun (Fri, 11 Nov 2016 06:23:50 +)
> 
> That's the application directory, which is the first place
> CreateProcess looks (via the SearchPath call), as both of my examples
> shows. In my case python.exe is located in the standard 3.5 system
> installation path, "C:\Program Files\Python35".

Okay, it looks like I read your first answer not thorough enough.

So if the application's directory is always searched then the issue 
should be reproducible with any native (non-Cygwin) Windows 
interpreter:

"""
tcc> \PortableApps\TCC_RT\tcc.exe /c run-TEST.btm
unset PATH
tcc.exe /c ver
TCC: C:\Documents\batch\run-TEST.btm [2]  Unbekannter Befehl 
"tcc.exe"
"""

So TCC can't find itself with an empty PATH. That's how Python 
(subprocess) should also work.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

* Thomas Nyberg (Thu, 10 Nov 2016 17:46:06 -0500)
> 
> On 11/10/2016 05:32 PM, Thorsten Kampe wrote:
> > Yes. That works. But it's not like subprocess should work.
> >
> 
> It certainly is odd. I can at least confirm that when I try to run your 
> code I get the error that you're expecting, but I run debian.
> 
> Have you tried using os.unsetenv()?

I think you are kind of misunderstanding my intention. I'm actually 
trying the opposite: running python.exe by setting F:\PortableApps
\Python3x as the first element in PATH. No Python interpreter is in 
my PATH. So unsetting PATH is just a way to demonstrate that this 
should never ever work.

I'm going to open a bug report.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

* eryk sun (Thu, 10 Nov 2016 23:04:02 +)
> 
> On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe
> <thors...@thorstenkampe.de> wrote:
> >
> > I'm trying to run a script with a different Python version by
> > extending the path variable and executing "python.exe". It looks like
> > subprocess will always run the current executing Python.
> 
> WinAPI CreateProcess checks the application directory, current
> directory (an insecure legacy default), %SystemRoot%\System32,
> %SystemRoot%\System, %SystemRoot%, and then the directories in %PATH%.
> This is listed in the documentation of the lpCommandLine parameter on
> MSDN [1].

I'm aware of that. Python is in F:\PortableApps\Python3x and neither 
the current directory nor the PATH points to that.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

* Thomas Nyberg (Thu, 10 Nov 2016 17:07:35 -0500)
> 
> On 11/10/2016 04:58 PM, Thorsten Kampe wrote:
> > Hi,
> >
> > I'm trying to run a script with a different Python version by
> > extending the path variable and executing "python.exe". It looks like
> > subprocess will always run the current executing Python.
> >
>  > [...]
>  >
> > Thorsten
> >
> 
> Have you tried using the full path to the other binary?

Yes. That works. But it's not like subprocess should work.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Windows: subprocess won't run different Python interpreter

[Thorsten Kampe]

Hi,

I'm trying to run a script with a different Python version by 
extending the path variable and executing "python.exe". It looks like 
subprocess will always run the current executing Python.

The following snippet demonstrates the problem:
"""
import os, subprocess
os.environ['PATH'] = ''
print(subprocess.check_output(['python.exe', '-V']))
"""

It outputs the version of the current executing Python interpreter 
although it should generate an error because Python is not in the 
PATH.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ConfigParser: use newline in INI file

[Thorsten Kampe]

* Ned Batchelder (Sat, 1 Oct 2016 17:41:28 -0700 (PDT))
> 
> On Saturday, October 1, 2016 at 6:25:16 PM UTC-4, Thorsten Kampe wrote:
> > * Ben Finney (Sun, 02 Oct 2016 07:12:46 +1100)
> > > 
> > > Thorsten Kampe <thors...@thorstenkampe.de> writes:
> > > 
> > > > ConfigParser escapes `\n` in ini values as `\\n`.
> > 
> > Indenting solves the problem. I'd rather keep it one line per value 
> > but it solves the problem.
> 
> If you want to have \n mean a newline in your config file, you can 
> do the conversion after you read the value:
> 
> >>> "a\\nb".decode("string-escape")
> 'a\nb'

Interesting approach (although it does not work with Python 3: decode 
is only for byte-strings and the string-escape encoding is not 
defined).

If I understand this correctly, this is equivalent to
`.replace('\\n', '\n')` ?

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ConfigParser: use newline in INI file

[Thorsten Kampe]

* Ben Finney (Sun, 02 Oct 2016 07:12:46 +1100)
> 
> Thorsten Kampe <thors...@thorstenkampe.de> writes:
> 
> > ConfigParser escapes `\n` in ini values as `\\n`.

Indenting solves the problem. I'd rather keep it one line per value 
but it solves the problem.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ConfigParser: use newline in INI file

[Thorsten Kampe]

* Terry Reedy (Sat, 1 Oct 2016 15:44:39 -0400)
> 
> On 10/1/2016 10:56 AM, Thorsten Kampe wrote:
> 
> > ConfigParser escapes `\n` in ini values as `\\n`. Is there a way to
> > signal to ConfigParser that there is a line break?
> 
> Without an example or two, I don't really understand the question enough 
> to answer.

>>> !cat INI.ini
[Asciidoc]
_test_stdout = \nHello, World!\n

>>> import configparser

>>> config = configparser.ConfigParser()

>>> config.read('INI.ini')
['INI.ini']

>>> config['Asciidoc']['_test_stdout']
'\\nHello, World!\\n'

...as you can see, ConfigParser escaped the backslash by doubling it. 
Which is fine in most cases - except when I want to have something 
indicating an newline.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

ConfigParser: use newline in INI file

[Thorsten Kampe]

Hi,

ConfigParser escapes `\n` in ini values as `\\n`. Is there a way to 
signal to ConfigParser that there is a line break?

Thorsten


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to convert 'ö' to 'oe' or 'o' (or other si =?utf-8?Q?milar_things)_in_a_string??=

[Thorsten Kampe]

* Terry Reedy (Sun, 18 Sep 2016 03:51:40 -0400)
> 
> On 9/18/2016 2:45 AM, Steven D'Aprano wrote:
> 
> > It doesn't matter whether you call them "accent" like most people do, or
> > "diacritics" as linguists do.
> 
> I am a native born American and I have never before heard or seen 
> non-accent diacritic marks called 'accents'.  Accents indicate stress. 
> Other diacritics indicate other pronunciation changes.  It is 
> counterproductive to confuse the two groups.  Spanish, for instance, has 
> vowel accents that change which syllable gets stressed.  A tilda is not 
> an accent; rather, it softens the pronunciation of 'n' to 'ny', as in 
> 'canyon'.

Had to be said. Nothing to add.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to convert 'ö' to 'oe' or 'o' (or other si =?utf-8?Q?milar_things)_in_a_string??=

[Thorsten Kampe]

* Martin Schöön (17 Sep 2016 20:20:12 GMT)
> 
> Den 2016-09-17 skrev Kouli :
> > Hello, try the Unidecode module - https://pypi.python.org/pypi/Unidecode.
> >
> > Kouli
> >
> > On Sat, Sep 17, 2016 at 6:12 PM, Peng Yu  wrote:
> >> Hi, I want to convert strings in which the characters with accents
> >> should be converted to the ones without accents. Here is my current
> >> code.
> 
> Side note from Sweden. Å, ä and ö are not accented characters in our 
> language. They are characters of their own.

I think he meant diacritics.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there something similar to `set -v` of bash in python

[Thorsten Kampe]

* Thorsten Kampe (Sat, 17 Sep 2016 12:25:05 +0200)
> 
> * Peng Yu (Fri, 16 Sep 2016 21:31:37 -0500)
> > 
> > Hi, `set -v` in bash allows the print of the command before print the
> > output of the command.
> > 
> > I want to do the similar thing --- print a python command and then
> > print the output of the command. Is it possible with python?
> 
> Rather easily. I've implemented it some time ago like this:

Oops, I mixed it up with `set -x`, sorry.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there something similar to `set -v` of bash in python

[Thorsten Kampe]

* Peng Yu (Fri, 16 Sep 2016 21:31:37 -0500)
> 
> Hi, `set -v` in bash allows the print of the command before print the
> output of the command.
> 
> I want to do the similar thing --- print a python command and then
> print the output of the command. Is it possible with python?

Rather easily. I've implemented it some time ago like this:

"""
import sys

def _traceit(frame, event, arg):
if (frame.f_globals['__name__'] == '__main__' and
event in ['call', 'line']):

logger.debug('+[{lineno}]: {code}'.format(
lineno = frame.f_lineno,
code   = inspect.getframeinfo(frame).code_context
[0].rstrip()))
return _traceit

sys.settrace(_traceit)
"""

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[Thorsten Kampe]

* Ulli Horlacher (Tue, 16 Feb 2016 12:38:44 + (UTC))

By the way: there is a script called `win_add2path.py` in your Python 
distribution which "is a simple script to add Python to the Windows 
search path. It modifies the current user (HKCU) tree of the 
registry.". That should do most of what you want.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[Thorsten Kampe]

* Ulli Horlacher (Tue, 16 Feb 2016 12:38:44 + (UTC))
> 
> Thorsten Kampe <thors...@thorstenkampe.de> wrote:
> > * Ulli Horlacher (Tue, 16 Feb 2016 08:30:59 + (UTC))
> > > I need to extend the PATH environment variable on Windows.
> > 
> > 1. Add the path component yourself into HKEY_CURRENT_USER and make 
> > sure it's not there already (pure Python).
> 
> Preferred!
> What is HKEY_CURRENT_USER? Another environment variable?

It's a hive in the Windows registry and the equivalent of `~/.*` in 
Linux terms (HKEY_LOCAL_MACHINE[/Software] being the equivalent of 
`/etc`). The fact that you're asking indicates that you should read 
about that in advance. 

The task itself is definitely not that hard. Maybe someone has 
already asked at StackOverflow. But the devil's in the detail.

Some things to consider

- Python is not by default installed on Windows, so you have to use a 
way to run your script without (PyInstaller for instance).

- by default there is no entry in HKCU, so you have to create it 
first (under HKEY_CURRENT_USER\Environment).

- you need to create the correct type (REG_SZ, null-terminated 
string)

- Windows paths are semicolon separated (not colon).

- Windows only module for the Registry: 
https://docs.python.org/3/library/winreg.html

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: extending PATH on Windows?

[Thorsten Kampe]

* Ulli Horlacher (Tue, 16 Feb 2016 08:30:59 + (UTC))
> I need to extend the PATH environment variable on Windows.
> 
> So far, I use:
> 
>system('setx PATH "%PATH%;'+bindir+'"')
> 
> The problem: In a new process (cmd.exe) PATH contains a lot of double
> elements. As far as I have understood, Windows builds the PATH
> environment variable from a system component and a user component. With
> the setx command from above I have copied the system PATH into the user
> PATH component.
> 
> Is there a better way to extend the PATH environment variable for the user?
> It must be persistent, not only for the current process.

`os.system` should be `subprocess.call` on modern systems (actually 
`subprocess.run` if you have Python 3.5). Since `setx` doesn't seem 
to have unique and add options, you basically have two options:

1. Add the path component yourself into HKEY_CURRENT_USER and make 
sure it's not there already (pure Python).

2. a) use a shell that offers that capability with `set`: 
https://jpsoft.com/help/set.htm (TCC/LE is free)

   b) use a dedicated environment variable editor: 
http://www.rapidee.com/en/command-line

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Run two processes in parallel

[Thorsten Kampe]

* Ian Kelly (Sun, 29 Mar 2015 03:13:31 -0600)
 
 On Sun, Mar 29, 2015 at 2:11 AM, Thorsten Kampe
 thors...@thorstenkampe.de wrote:
 
  I'd like to run two processes concurrently (either through a builtin
  module or a third-party). One is a background task and the other is
  displaying a spinner (for which I already found good packages).
  [...]
 
 It shouldn't be all that complicated:
 
 import time, multiprocessing, spinner
 process1 = multiprocessing.Process(target=time.sleep, args=(60,))
 process1.start()
 [...]

Thanks, I missed the example in the long documentation for 
multiprocessing. From Python 3.2 there is also `concurrent.futures` 
which does the same thing - but also allows you to use a thread.

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

Run two processes in parallel

[Thorsten Kampe]

Hi,

I'd like to run two processes concurrently (either through a builtin 
module or a third-party). One is a background task and the other is 
displaying a spinner (for which I already found good packages).

The two processes do not have to communicate with each other; only 
the second should be able to know when the first has terminated. To 
make it clear, this is the pseudo-code:

```
import time, PARALLEL, spinner
process1 = PARALLEL.start(time.sleep(60))

while process1.isrunning
spinner.update()
time.sleep(1)

print('done')
```

From what I see, Python modules threading and multiprocessing seem 
either not suited for that or to be too complicated (though I don't 
have any experience with these and could be wrong). A search on PyPi 
for parallel, background, and concurrent found too many.

What would you do? Which technique or module would you suggest?

Thorsten

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue16786] argparse doesn't offer localization interface for version action

[Thorsten Kampe]

New submission from Thorsten Kampe:

The - deprecated - version keyword for argparse.ArgumentParser allowed for 
localization of the show program's version number and exit help text for 
-v/--version (output of -h/--help)

The new version action for add_argument does not allow this - resulting in a 
partially translated output for the -v/--version option.

--
components: Library (Lib)
messages: 178209
nosy: thorsten
priority: normal
severity: normal
status: open
title: argparse doesn't offer localization interface for version action
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16786
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Usefulness of the not in operator

[Thorsten Kampe]

* candide (Sat, 08 Oct 2011 16:41:11 +0200)
 After browsing source code, I realize that parenthesis are not
 necessary (not has higher precedence than in).

Lower precedence.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pythonw.exe

[Thorsten Kampe]

* Chris Angelico (Sun, 14 Aug 2011 16:52:05 +0100)
 On Sun, Aug 14, 2011 at 3:30 PM, Nobody nob...@nowhere.com wrote:
  BTW, unless you're using Windows 95/98/ME, you don't have a DOS
  Prompt. The command prompt in Windows NT/2000/XP/Vista/7 isn't DOS.
 
 I don't see this as any sloppier than referring to opening a
 whatever prompt when you mean opening up a windowed command
 interpreter.

You're misunderstanding what people mean by DOS prompt. They don't 
mean this is the DOS command shell, they mean this is DOS.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dialog boxes in curses

[Thorsten Kampe]

* f...@slick.airforce-one.org (13 Aug 2011 15:21:01 GMT)
 I want to have dialog boxes (a message with Yes/No/Cancel options,
 possibly with keyboard accels) in python + curses.

Use Python Dialog[1] which is basically a wrapper for dialog boxes 
around ncurses.

Thorsten
[1] http://pythondialog.sourceforge.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inconsistencies with tab/space indentation between Cygwin/Win32?

[Thorsten Kampe]

* Christian Gelinek (Thu, 4 Aug 2011 13:55:37 +0930)
 Any ideas on how to get the thing to run under (real) Windows,
 hopefully without having to edit existing sources of people who left
 our company ages ago?

python -t
Issue a warning when a source file mixes tabs and spaces for
indentation in a way that makes it depend on the worth of a tab
expressed in spaces. Issue an error when the option is given twice.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] IPython 0.11 is officially out

[Thorsten Kampe]

* Fernando Perez (Sun, 31 Jul 2011 17:26:50 + (UTC))
 on behalf of the IPython development team, I'm thrilled to announce,
 after more than two years of development work, the official release of
 IPython 0.11.
 
 This release brings a long list of improvements and new features
 (along with hopefully few new bugs). We have completely refactored
 IPython, making it a much more friendly project to participate in by
 having better separated and organized internals. We hope you will not
 only use the new tools and libraries, but also join us with new ideas
 and development.
 [...]
 Here is a quick listing of the major new features:
 [...]
 - New configuration system
 [...]

And the best thing is: IPython 0.11 is not compatible to 0.10 so if you 
had your own customized ipythonrc you can start from scratch.

The documentation[1] says If you are upgrading to version 0.11 of 
IPython, you will need to migrate your old ipythonrc or ipy_user_conf.py 
configuration files to the new system. Read on for information on how to 
do this. Unfortunately there is no more mentioning of migration, so 
the developers' approach seems to be: read all about the new 
configuration system and see if you can somehow duplicate your old 
ipythonrc settings. Good luck!.

By the way: configuration object, applications, configurables, 
singletons, ... Am I really supposed to understand all this?

Thorsten
[1] http://ipython.org/ipython-doc/stable/config/overview.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Deeply nested dictionaries - should I look into a database or am I just doing it wrong?

[Thorsten Kampe]

* Andrew Berg (Sat, 30 Jul 2011 22:10:43 -0500)
 I'm looking for pointers on design. I'm inexperienced but cautious and
 am mostly wondering if there's an easier way to format this data or
 if this approach will lead to problems.

The QueueItem.x264['avs']['filter']['fft3d']['ffte']) example does not 
look right. Especially the mix of . and [] references. Actually, 
dictionaries in a dictionary don't look right to me either.

The design of your data structure won't change. I would think that your 
program already mimicks it by nested class statements so you're 
duplicating the already existing class structure via dictionaries in 
order to have it available in the main class. You say that is necessary 
but I'm not convinced it is.

Another approach would be named tuples instead of dictionaries or flat 
SQL tables.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Deeply nested dictionaries - should I look into a database or am I just doing it wrong?

[Thorsten Kampe]

* Andrew Berg (Sun, 31 Jul 2011 13:36:43 -0500)
 On 2011.07.31 02:41 AM, Thorsten Kampe wrote:
  Another approach would be named tuples instead of dictionaries or
  flat SQL tables.
 What would the advantage of that be?

QueueItem.x264['avs']['filter']['fft3d']['ffte'] would be 
QueueItem.x264.avs.filter.fft3d.ffte. I recently migrated from a 
syntax of - example - datetuple[fieldpositions['tm_year'][0]] (where 
fieldpositions was a dictionary containing a list) to 
datetuple.tm_year_start which is much more readable.

The advantage of a SQL(ite) database would be simple flat tables but 
accessing them would be more difficult.

Even a INI config file structure could match your problem.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Anssi Saari (Mon, 18 Jul 2011 19:28:49 +0300)
 
 Thorsten Kampe thors...@thorstenkampe.de writes:
 
  The perfect programming font is just the one that looks so good that 
  you would also use it for writing email. Dejavu Sans Mono is pretty 
  good. Consolas looks also looks good but it is Windows only.
 
 How is Consolas Windows only? Not that I'd put it in my Windows-free
 systems, but I don't see why you couldn't?

Consolas ships with all versions of Windows Vista and Windows 7, 
including Home Basic. If you’re using Visual Studio 2005, you can 
download Consolas from Microsoft. If not, you still may be able to use 
the font, though your mileage may vary. I was able to install it on a 
Windows XP SP1 machine that doesn’t have any version of Visual Studio. 
This PC does have the Microsoft .NET Framework SDK which creates various 
“Microsoft Visual Studio” folders under “Program Files”. These may cause 
the Consolas installer to think I do have VS 2005. I got no error 
messages, and the font was instantly available in all applications.

Another way to get Consolas is to download and install the free 
PowerPoint Viewer 2007 from Microsoft. This works on any computer with 
Windows 2000 SP4 or Windows XP SP1 or later. In addition to the 
PowerPoint Viewer 2007 itself, the installer will install the following 
fonts: Calibri, Cambria, Candara, Consolas, Constantia and Corbel. Only 
the Consolas font is monospaced. All these fonts ship with Windows Vista 
and Windows 7.

http://www.editpadpro.com/fonts.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
 3) Tabs create freedom in the form of user controlled indention.
 
 Indention width should be a choice of the reader NOT the author. We
 should never code in indention width; but that is EXACTLY what we
 are doing with spaces! No, the reader should be able to choose the
 indention width without ANY formatting required or without any
 collateral damage to the source code. Tabs offer freedom, spaces offer
 oppression.

Why are you so obsessed with indentation length? Indentation length is 
just /one/ of the formatting choices that the author makes for the 
reader - and probably the /least/ significant one.

There is for instance maximum line length, the number of empty lines, 
the author's method of alignment, spaces between the equals sign and so 
on. These are all much more dominant in the source code and none of 
this is left for the reader's disposition.

Compare for instance

variable= 11
anothervariable = 22

def whatever (prettylong = 1,
  alsoprettylong = 22,
  anotherone = 33):
pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
pass

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Andrew Berg (Sat, 16 Jul 2011 19:29:30 -0500)
 Of everything I've read on tabs vs. spaces, this is what makes the
 most sense to me:
 http://www.iovene.com/61/

Interesting one, especially the - from the coder's point of view - 
artificial distinction between indentation and alignment.

What is the difference between indentation and alignment? Well, 
indentation works with tabs, alignment not.

The author's conclusion simply just use what ever you want for 
indenting, but use spaces for aligning leaves only two choices for 
Python programmers: use spaces for indenting or don't align.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Andrew Berg (Sun, 17 Jul 2011 03:36:31 -0500)
 Not everyone agrees on how many spaces an indent should be (whether an
 indent is a tab or a space-tab), which is a good reason to use tabs.

Not everyone who doesn't agree on indent size actually cares enough 
about indent size - especially in someone else's code. I'd say it's 
probably rather the majority making this whole debate artificial.

I like my indent four spaces. If you like eight, wonderful, I don't 
care, it's your code. If I want to use your code in my own, I completely 
have to reformat your code anyway. And if we work on a project together, 
we have to agree on formatting anyway, the indent size being the least 
important one.

This whole debate is artificial.

 Using tabs for indentation and spaces for alignment solves the
 problem. I really can't think of any problems this would cause that
 aren't superficial.

Sorry, you didn't understand my point. My point is: the distinction 
between indentation and alignment is superficial. Indentation /is/ 
exactly the same as alignment.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
  And if we work on a project together, we have to agree on formatting
  anyway, the indent size being the least important one.
 How is indent size unimportant with regard to formatting?

Take some code or yours and format it with three and with six spaces. 
Then you will see how unimportant it is: it looks virtually the same.

Or as I've written in another posting:
There is for instance maximum line length, the number of empty lines, 
the author's method of alignment, spaces between the equals sign and so 
on. These are all much more dominant in the source code and none of 
this is left for the reader's disposition.

Compare for instance

variable= 11
anothervariable = 22

def whatever (prettylong = 1,
  alsoprettylong = 22,
  anotherone = 33):
pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
pass


  This whole debate is artificial.
 Only if no one cares about your code.

Only if you don't care about indent length - which I again state, most 
people (probably) don't.

 It's also worth mentioning that some people have an almost religious
 fervor when it comes to spaces and tabs.

I know. These are people like rantingrick who start artificial threads 
like this with artificial problems like tabs versus spaces to liberate 
the common coder.

  Sorry, you didn't understand my point. My point is: the distinction
  between indentation and alignment is superficial. Indentation /is/
  exactly the same as alignment.

 I still don't understand. Whitespace to the left of an assignment to
 signify an indent and whitespace around operators to align values (in
 a multi-line assignment) are not the same.

When I'm (consistently, of course) indenting code, I'm aligning it. When 
I'm aligning code, I do this by indenting it, see for instance...

firstvariable = 11
variable  = 111

firstvariable = 22
variable =  222

The second = and the 222 is indented.

Or your example:
setup(
name = 'Elucidation',
version  = '0.0.1-WIP',
py_modules   = ['elucidation'],
author   = 'Andrew Berg',
author_email = 'baha...@digital-signal.net',
url  = '',
platforms= 'Windows',
description  = 'Provides a class for storing information on
multimedia files that are to be converted or remuxed and methods to
convert and remux using popular tools.'
)

The keywords are aligned by indenting. In the left of an assignment 
case it makes a difference for the Python compiler, in the alignment 
case it doesn't. In both cases, it makes a difference to the human who 
indents/aligns to group similar things and blocks.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)
 So long as the indentation lines up (which it does, with tabs or
 spaces) then I do not see any problem with variable-width.

 What are the counter-arguments?

Alignment doesn't line up.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200)
 Thorsten Kampe wrote:
  * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
  I still don't understand. Whitespace to the left of an assignment
  to signify an indent and whitespace around operators to align
  values (in a multi-line assignment) are not the same.
  
  When I'm (consistently, of course) indenting code, I'm aligning it. When
  I'm aligning code, I do this by indenting it, see for instance...
  
  firstvariable = 11
  variable  = 111
  
  firstvariable = 22
  variable =  222
  
  The second = and the 222 is indented.
 
 You might want to check your English dictionary.  Indenting is commonly 
 understood in typography as To begin (a line or lines) at a greater or less 
 distance from the margin¹.  In particular, in computer programming it 
 usually means that there is, at most, whitespace on the left of the text.²  
 In that sense, the above is _not_ indentation (or indenting), as neither 
 variable nor variable = consist only of whitespace.  It is only 
 aligning.³

*doublesigh* that is actually the point I was trying to make. From a 
programmer's point of view the distinction is artificial because he does 
essentially the same: press the tab key or the indent button to move the 
stuff right from the cursor to the right so it gets aligned with the 
stuff above.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* gene heskett (Sun, 17 Jul 2011 10:29:03 -0400)
 On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine:
  I'm still looking for the perfect programming font. Suggestions
  welcomed.
 
 When you find it Dotan, let me know, I've been looking since the later
 '70's.

The perfect programming font is just the one that looks so good that 
you would also use it for writing email. Dejavu Sans Mono is pretty 
good. Consolas looks also looks good but it is Windows only.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* rantingrick (Sun, 17 Jul 2011 10:57:10 -0700 (PDT))
 Choose to follow it or die of exceptions; your choice.

One of the best things I've read for a long time :-).

 The past is bickering over selfish personal freedoms, the future of is
 unity.

And a tab is *exactly* four spaces. Not three. Not five. Not eight. For 
you, for me, and for the rest of the world. Amen!

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 22:20:15 +0300)
 
 On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe thors...@thorstenkampe.de 
 wrote:
  * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)
  So long as the indentation lines up (which it does, with tabs or
  spaces) then I do not see any problem with variable-width.
 
  What are the counter-arguments?
 
  Alignment doesn't line up.
 
 
 They do with tabs.

Indentation alignment will (because you're using only spaces). Otherwise 
it doesn't align (it can't), simply because of the variable-width.

For instance (in a variable-width font):

if a == b:
var123= 22
varxyz456 = 333
  ^
aligned   not aligned

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An interesting beginner question: why we need colon at all in the python language?

[Thorsten Kampe]

* Dave Angel (Mon, 11 Jul 2011 10:36:48 -0400)
 On 01/-10/-28163 02:59 PM, Anthony Kong wrote:
  My immediate response is: it allows us to fit statements into one
  line. e.g.
  if a == 1: print a
 
 You're confusing the colon with the semi-colon. If you want two
 statements on the same line, you use a semi-colon.

He's not confusing anything at all. His example made it pretty clear 
that he didn't mean two statements but multiline statemements.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An interesting beginner question: why we need colon at all in the python language?

[Thorsten Kampe]

* Thomas Jollans (Mon, 11 Jul 2011 16:16:17 +0200)
 Basically, it looks better, and is more readable. 

People tend to overlook the colon for the same reason they tend to 
forget to set the colon in the first place:
a) it's a very weak marker in comparison to indentation and
b) it looks like doubling the markup to them (colon plus indentation)

What makes the if syntax for me even more weird, is the fact that you 
can have an else clause with an else without a then clause with a then.

if x  5:
print whatever 
else:
print whatever  

in comparison to:

if x  5
then
print whatever 
else
print whatever 

 A colon, in English like in Python, means that something follows that
 is related to what was before the colon. So the colon makes it
 abundantly clear to the human reader that a block follows,

The block that follows makes it abundantly clear to the human reader 
that a block follows.

 and that that block is to be considered in relation to what was just
 said, before the colon.

The indentation makes it abundantly clear to the human reader that that 
indented block is to be considered in relation to what was just said, 
before the indentation.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An interesting beginner question: why we need colon at all in the python language?

[Thorsten Kampe]

* Steven D'Aprano (Wed, 13 Jul 2011 21:07:17 +1000)
 Thorsten Kampe wrote:
  * Thomas Jollans (Mon, 11 Jul 2011 16:16:17 +0200)
  Basically, it looks better, and is more readable.
  
  People tend to overlook the colon for the same reason they tend to
  forget to set the colon in the first place:
  a) it's a very weak marker in comparison to indentation and
  b) it looks like doubling the markup to them (colon plus indentation)
 
 I can't speak for others, but speaking for myself, I wonder whether this is
 a difference between English speakers and non-English speakers?

It's not a difference between English and non-English speakers but the 
difference between a branch (if-then-else) and an enumeration (your 
example).

 To me, as a native English speaker, leaving the colon out of a header
 line, as follows below, just looks wrong.
 [enumeration] 
 
 Although the bullet list is indented, the header line Our three weapons
 are looks like something is missing, as if I had started to write
 something and forgotten to finish. It needs a colon to be complete:

Sure, because it's an enumeration - and not a branch or loop.
 
 An indented block on its own is surprising. It just hangs there, 
 with no connection to what was going on before. Why is it indented?
 Is it connected to the previous sentence?

In normal text: sure. You cannot just indent in Python as you like. 
Indentation always shows the connection.
 
  A colon, in English like in Python, means that something follows
  that is related to what was before the colon. So the colon makes it
  abundantly clear to the human reader that a block follows,
  
  The block that follows makes it abundantly clear to the human reader
  that a block follows.
 
 But it's too late by then. You have to mentally backtrack.
 
 blah blah blah blah statement is complete
 indented block surprise the previous line wasn't complete
 
 blah blah blah blah colon statement is not complete
 indented block

Source code is (unlike normal text) not read line by line. So you (at 
least I) don't have to backtrack from line 2 to line 1 because you see 
them both at the same time.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An interesting beginner question: why we need colon at all in the python language?

[Thorsten Kampe]

* Grant Edwards (Wed, 13 Jul 2011 13:03:22 + (UTC))
 On 2011-07-13, Thorsten Kampe thors...@thorstenkampe.de wrote:
 
  and that that block is to be considered in relation to what was just
  said, before the colon.
 
  The indentation makes it abundantly clear to the human reader that
  that indented block is to be considered in relation to what was just
  said, before the indentation.

 You would think so, but human readers like redundancy.

I also like redundancy (and consistency). That's why I'd much more 
prefer a then than a colon which is easily overlooked while reading 
/and/ while writing.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wgy isn't there a good RAD Gui tool fo python

[Thorsten Kampe]

* sturlamolden (Mon, 11 Jul 2011 06:44:22 -0700 (PDT))
 On 11 Jul, 14:39, Ben Finney ben+pyt...@benfinney.id.au wrote:
  The Unix model is: a collection of general-purpose, customisable
  tools, with clear standard interfaces that work together well, and
  are easily replaceable without losing the benefit of all the others.
 
 This is opposed to the Windows model of a one-click installer for a
 monolithic application. Many Windows users get extremely frustrated
 when they have to use more than one tool.

*sigh* There is no Windows nor Unix model. There is only you-get-what-
you-pay-for.

On Windows, you're a customer and the developer wants to make using his 
application as convenient as possible for you, the customer.

On Unix you don't pay and the developer couldn't care less if his 
application works together with application b or how much it takes you 
to actually get this damn thing running.

And as soon as developers start developing for Unix customers (say 
Komodo, for instance), they start following the Windows model - as you 
call it.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Wgy isn't there a good RAD Gui tool fo python

[Thorsten Kampe]

* sturlamolden (Mon, 11 Jul 2011 07:21:37 -0700 (PDT))
 On 11 Jul, 16:10, Thorsten Kampe thors...@thorstenkampe.de wrote:
  And as soon as developers start developing for Unix customers (say
  Komodo, for instance), they start following the Windows model - as
  you call it.
 
 You are probably aware that Unix and Unix customers have been around
 since the 1970s. I would expect the paradigm to be changed by now.

For the /customers/ on Unix it never was a paradigm. They would have 
laughed in their vendor's face if they had gotten the here are the 
tools, just make them work together as you like attitude[1].

Thorsten
[1] at least starting from the beginning of the nineties when commercial 
alternatives to Unix began to emerge
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Please Help with vertical histogram

[Thorsten Kampe]

* Cathy James (Mon, 11 Jul 2011 19:42:10 -0500)
 Please kindly help- i have a project where I need to plot dict results
 as a histogram. I just can't get the y- axis to print right. May
 someone please help? I have pulled my hair for the past two weeks, I
 am a few steps ahead, but stuck for now.

This sounds like homework. There's the Python Tutor mailing list where 
you will receive help.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String concatenation vs. string formatting

[Thorsten Kampe]

* John Gordon (Fri, 8 Jul 2011 20:23:52 + (UTC))
 I prefer this usage:
 
   logger.error('%s could not be stored - %s' % \
 (self.preset_file, sys.exc_info()[1]))

The syntax for formatting logging messages according to the 
documentation is:

Logger.error(msg, *args) 

NOT

Logger.error(msg % (*args)) 

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: windows 7 create directory with read write execute permission for everybody

[Thorsten Kampe]

* Gelonida (Sun, 26 Jun 2011 23:53:15 +0200)
 On this machine I used os.mkdir() / os.makedirs() and I had permission 
 problems , but only on Windows7.

Windows file permissions haven't changed since 1995. The only addition 
was dynamic inheritance support back in 2000.

 I expect, that the win32 libraries might have function calls allowing
 to control the permissions of a directory, but I am really bad with
 win32 as I worked mostly with Linux or code, that was platform
 independent, which Windows file permission handling is not :-( .

Even Linux file systems have ACL support. It's only that few people use 
it since application support is sparse. And it lacks (dynamic) 
inheritance which is so 1980s.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: windows 7 create directory with read write execute permission for everybody

[Thorsten Kampe]

* Gelonida (Mon, 27 Jun 2011 11:32:45 +0200)
 One thing, which I would still like to know (though I don't need it
 for my current task) is what to do to to setup an ACE on a directory,
 such, that all entries below will inherit the directory's access
 settings.

Such a thing does not exist.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: windows 7 create directory with read write execute permission for everybody

[Thorsten Kampe]

* Gelonida (Sun, 26 Jun 2011 22:57:57 +0200)
 What do I have to do under python windows to create a directory with
 all permissions, such, that new files / directories created below will
 inherit the permissions.

Exactly nothing (except creating the directory, of course).

 The reason I am asking is, that I'd like to create a directory
 structure where multiple users should be allowed to read / write /
 create files and directories.
 
 Alternatively it would be even better to specify exactly which users
 should be allowed to access the directory tree.
 
 I never used / modified Windows file permissions except once or twice
 via explorer. I'm thus a little shaky with Microsoft's file
 permissions.

Microsoft's permission handling hasn't changed in the last eleven years. 
So you had a lot of time to learn about it. Do you see this Learn about 
access control and permissions link when you're in the security tab? 
Just click on it.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to write to registry without admin rights on win vista/7

[Thorsten Kampe]

* Andrew Berg (Fri, 24 Jun 2011 14:02:54 -0500)
 On 2011.06.24 03:48 AM, Duncan Booth wrote:
  http://stackoverflow.com/questions/130763/request-uac-elevation-from-within-a-python-script
 Heh. On Windows 7, using 'runas' for the operation in os.startfile()
 gives me a normal UAC prompt.

That is because UAC for non-admin accounts /is/ runas.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to write to registry without admin rights on win vista/7

[Thorsten Kampe]

* miamia (Fri, 24 Jun 2011 01:08:55 -0700 (PDT))
 In my program I can set to run after system startup (it writes path to
 Software\Microsoft\Windows\CurrentVersion\Run)

Under HKLM oder HKCU? The path itself is of course irrelevant.

 but when normal user is logged in my application crashes.

Without an exception?

 I must right click on app an choose Run As Admin and then everything
 works.
 
 How can I do it to write to registry without Run As Admin ?

Disable UAC.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7 and cmd on Windows 7 64 (files lost)

[Thorsten Kampe]

* Michel Claveau - MVP (Thu, 23 Jun 2011 08:33:20 +0200)
 On Win 7 64 bits:
   Command-Line
   CD \Python27
   dir C:\Windows\System32\SoundRecorder.exe:== OK
   Python.exe
 
  import os
  os.system(dir C:\\Windows\\System32\\SoundRecorder.exe)  
 
 == Do not found the file !!!
 
 and os.system(cmd /k)  then  dir C:\Windows\System32\SoundRecorder.exe  
 do not found
 anyway.

This is because 32-bit processes (Python, 32-bit cmd) cannot see the 64-
bit DLLs in System32.
 
 But:
   {Ctrl-Z} in Python
   then  dir C:\Windows\System32\SoundRecorder.exe  run OK

Now you are running 64-bit Cmd.
 
 Therefore, is the problem only in Python? 

Of course not (see above).

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7 and cmd on Windows 7 64 (files lost)

[Thorsten Kampe]

* Tim Golden (Thu, 23 Jun 2011 08:31:26 +0100)
 
 Certain commands, including dir and copy are not executables
 in their own right, but merely subcommands of cmd.exe.

Right, internal commands.

 You've got two options in Python:
 
os.system (rcmd /c dir c:\windows)

os.system automatically runs a shell (cmd) - see the documentation.
 
Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to avoid leading white spaces

[Thorsten Kampe]

* Roy Smith (Thu, 02 Jun 2011 21:57:16 -0400)
 In article 94ph22frh...@mid.individual.net,
  Neil Cerutti ne...@norwich.edu wrote:
  On 2011-06-01, ru...@yahoo.com ru...@yahoo.com wrote:
   For some odd reason (perhaps because they are used a lot in
   Perl), this groups seems to have a great aversion to regular
   expressions. Too bad because this is a typical problem where
   their use is the best solution.
  
  Python's str methods, when they're sufficent, are usually more
  efficient.
 
 I was all set to say, prove it! when I decided to try an experiment.  
 Much to my surprise, for at least one common case, this is indeed 
 correct.
 [...]
 t1 = timeit.Timer('laoreet' in text,
  text = '%s' % text)
 t2 = timeit.Timer(pattern.search(text),
   import re; pattern = re.compile('laoreet'); text = 
 '%s' % text)
 print t1.timeit()
 print t2.timeit()
 -
 ./contains.py
 0.990975856781
 1.91417002678
 -

Strange that a lot of people (still) automatically associate 
efficiency with takes two seconds to run instead of one (which I 
guess no one really cares about).

Efficiency is much better measured in which time it saves you to write 
and maintain the code in a readable way.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[Thorsten Kampe]

* Thomas Rachel (Sat, 28 May 2011 07:06:53 +0200)
 Am 27.05.2011 17:52 schrieb Steven D'Aprano:
  On Fri, 27 May 2011 09:40:53 -0500, harrismh777 wrote:
  3.x is completely incompatible with 2.x (some call it a dialect,
  but that is a lie).
 
  Completely incompatible? A lie?
 
 Hard word, but it is true. Many things can and will fall on your feet
 when moving.

I think we should stop talking about (in)compatability because everyone 
seems to associate something different with that term (incompatible = 
no Python2 to code will run with Python3, not all Python2 code will 
run with Python3).

The question is: if you want (or have) to run your code under Python3, 
how likely is that it will run unmodified? My experience is: unless the 
code is especially written with Python3 compatability or just a short 
snippet, it's actually quite unlikely that it will run.

I modified three programs/modules (none of them written with Python3 in 
mind - I was thinking that Python 3000 would come out some day after 
Perl 6, PHP 6 and GNU Hurd; how could I know that the Python developers 
actually mean business?)

One is a tool box kind of module. I had to insert lots of list() and 
add a complete function that would deal with the different behaviour of 
sort. Probably easy to find the problems if you have extensive unit 
tests but without it was a tedious nightmare.

The second a kind of script template. gettext.install has no unicode = 
True. Easy fix but I wondered why Python 3 does not ignore the keyword 
simply.

The third, a more real world complete application using PyQt. Took me 
about a day to fix. The problem was not just with the code but also with 
the tools (pyuic4, pyrcc4). Without the PyQt mailing list this wouldn't 
have been possible. Still: a complete workday (or even more) for 150 
lines of code.


Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Beginner needs advice

[Thorsten Kampe]

* Thorsten Kampe (Sat, 28 May 2011 08:38:54 +0200)
 My experience is: unless the code is especially written with Python3
 compatability [...]

Oops, I meant unless the code is specifically written with Python3 
compatability in mind [...]

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why did Quora choose Python for its development?

[Thorsten Kampe]

* Steven D'Aprano (27 May 2011 03:07:30 GMT)
 Okay, I've stayed silent while people criticize me long enough. What 
 exactly did I say that was impolite? 

Nothing.

 John threw down a distinct challenge:
 
 if Python is really so much better than Python [sic] 
 readability wise, why do I have such a hard time dropping
 Perl and moving on?
 [...]
 If I got it wrong about John, oh well, I said it was a guess, and
 trying to get inside someone else's head is always a chancy business.

Why were you trying to speculate in response to such a - sorry - dumb[1] 
question? What do his personal failures to switch to Python (why did he 
even try?) have to do with whether a) Python is more readable than Perl 
and b) whether readability counts towards productivity?

/Maybe/ it is simply because he somehow like[s] Perl more but 
definitely that is not really relevant to the question about 
readibility.

 Or maybe I just ran into him on a bad day.

Bad argument day. His other Python vs Perl is like Latin vs 
Devanagari argument is not really better. The problem with Perl is that 
it does /not/ use (Latin) alphabetic characters (like a, b, c) to form 
words but symbols ($, %, @. |, *) and re-combines them to give them new 
and special meaning.

So this is exactly /not/ a alphabet vs alphabet thing but a word(s) vs 
symbols.

Thorsten
[1] Sorry for being impolite. But why do I...? kind of rhetorical 
questions (as arguments) are just dumb.
-- 
http://mail.python.org/mailman/listinfo/python-list

sys.tracebacklimit not working in Python 3.2?

[Thorsten Kampe]

Hi,

 type test.py
import sys

sys.tracebacklimit = 0
import doesnotexist

 python test.py
ImportError: No module named doesnotexist

 python3 test.py
Traceback (most recent call last):
  File test.py, line 4, in module
import doesnotexist
ImportError: No module named doesnotexist

The 3.2 documentation says When set to 0 or less, all traceback 
information is suppressed and only the exception type and value are 
printed. Bug?

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: changing current dir and executing a shell script

[Thorsten Kampe]

* suresh (Fri, 27 May 2011 14:25:52 -0700 (PDT))
 I want to execute the following command line stuff from inside python. 
 $cd directory
 $./executable
 
 I tried the following but I get errors
 import subprocess
 subprocess.check_call('cd dir_name;./executable')
 
 Due to filename path issues, I cannot try this version.
 subprocess.check_call('./dir_name/executable')

os.chdir?
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue12193] Argparse does not work together with gettext and non-ASCII help text

[Thorsten Kampe]

Thorsten Kampe thors...@thorstenkampe.de added the comment:

LANG=de_De - should've been LANG=de_DE. Sorry for wasting someone's time. I 
shouldn't write bug reports in the middle of the night.

Sorry and thanks, Thorsten

--
resolution:  - invalid
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12193
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Why did Quora choose Python for its development?

[Thorsten Kampe]

* John Bokma (Wed, 25 May 2011 07:01:07 -0500)
 Thorsten Kampe thors...@thorstenkampe.de writes:
  * Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)
  
  On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain da...@druid.net wrote:
   One of my favorite quotes (not sure if it was about Perl or APL) is 
  I
   refuse to use a programming language where the proponents of it stick
   snippets under each other's nose and say 'I bet you can't guess what
   this does.'
  
  Yes, I believe that was Perl. And an amusing quote. But most of the
  point of it comes from the fact that Perl uses punctuation for most of
  its keywords, whereas (say) Python uses English words; it's a lot more
  fun to crunch something down when you can use $| and friends than when
  you have to put x and y, complete with spaces, for a simple boolean.
  But that says nothing about which language is actually better for
  working with... [...]
 
  It does say something about readibility. And yes, readability counts. 
  And yes, readability says a lot about how good a language is for reading 
  and working with.
 
 To people used to the latin alphabet languages using a different script
 are unreadable. So readability has a lot to do with what one is used
 to.

You've made that alphabet argument more than once. Nevertheless it's 
nonsense (sorry). Perl uses the same alphabet as Python. Only the 
words Perl uses ($| for instance) are only found in a Perl 
dictionary not in a English or math dictionary like the one that Python 
uses.

That's why you can /read/ Python but you have to /decode/ Perl to 
understand the source code.

 Like I already stated before: if Python is really so much better than
 Python readability wise, why do I have such a hard time dropping Perl
 and moving on?

What kind of argument is that?

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* Steven D'Aprano (25 May 2011 21:59:58 GMT)
 On Wed, 25 May 2011 09:26:11 +0200, Thorsten Kampe wrote:
 
  Naming something in the terms of its implementation details (in this
  case recursion) is a classical WTF.
 
 *If* that's true, it certainly doesn't seem to apply to real-world 
 objects. Think about the exceptions:
 
 microwave oven
 vacuum cleaner
 oven fries
 electric car
 chain saw
 flintlock rifle
 air gun
 vulcanised rubber
 kerosene heater
 aluminium foil
 diamond saw
 gas stove
 wood stove
 four-wheel drive car
 incandescent light bulb
 electric razor
 unleaded petrol
 
 to mention only a few.
 
 Naming the thing after the implementation would often seem to be *good 
 advice*, not bad. We often do care about implementations. You really do 
 need to know whether the car you drive uses leaded or unleaded.

That's exactly the point. You don't need to know whether include sub-
directories was implemented recursively. It's absolutely pointless.

But not to digress, the /real/ problem with commands or idioms like rm 
-r is /not/ their choice of option names but that they explain these 
options in the exact same terms. No one would have a problem with -r, 
--recursive -- remove directories including all sub-directories instead 
of -r, --recursive -- remove directories and their contents 
recursively.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* Steven D'Aprano (25 May 2011 22:58:21 GMT)
 
 On Wed, 25 May 2011 00:06:06 +0200, Rikishi42 wrote:
 
  What I mean is: I'm certain that over the years I've had more than 
one
  person come to me and ask what 'Do you wish to delete this directory
  recursively?' meant. BAut never have I been asked to explain what 'Do
  you wish to delete this directory and it's subdirs/with all it's
  contents?' meant. Never.
 
 I know many people who have no idea what a directory is, let alone a 
 subdirectory, unless it's the phone directory. They're non-computer 
 users. Once they start using computers, they quickly work out what the 
 word means in context, or they ask and get told, and then they've learned 
 a new word and never need ask again. This is a good thing.
 
 The idiom of recursively delete is no different. Of course some people 
 will have to learn a new term in order to make sense of it. So what?

It's not just a new term. It tries to describe something which could 
be easily described in the terms of what is already known.

If someone has learned what a directory or folder is, you don't have to 
explain what include sub-folders means. Instead of creating a new 
mysterious term (recursively delete), you simply explain stuff by re-
using an already existing term. It's just that simple.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* Steven D'Aprano (26 May 2011 10:06:44 GMT)
 
 On Thu, 26 May 2011 10:48:07 +0200, Thorsten Kampe wrote:
 
  But not to digress, the /real/ problem with commands or idioms like rm
  -r is /not/ their choice of option names but that they explain these
  options in the exact same terms. No one would have a problem with -r,
  --recursive -- remove directories including all sub-directories instead
  of -r, --recursive -- remove directories and their contents
  recursively.
 
 I think you are understanding the description remove directories and 
 their contents recursively as a description of the *mechanism* by which 
 rm removes the directory, i.e. some recursive tree-walking function that 
 visits each node and deletes it.
 
 I don't believe that's how the description is meant to be understood. I 
 understand it as describing the effect, not the implementation.

It doesn't matter how I interprete the explanation -r = recursively 
delete. What matters is that I have to explain (interpret, translate 
the explanation.

 You're interpreting the reference to recursive as a nod to the
 implementation. I'm not, and therefore your arguments don't convince
 me.

No one understands what recursively delete means until someone 
explains (translates) it to him. This is not an argument but a simple 
fact. I experienced it many times, others here in the thread did and 
probably you, too.

recursively delete is completely unneccessary because there is already 
a simple explanation that everyone understands without translation 
(delete including subdirectories).

It's unnecessary bullshit buzzword bingo from nerds which adds or helps 
or explains nothing. It's just that simple.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* Charles (Thu, 26 May 2011 20:58:35 +1000)
 Thorsten Kampe thors...@thorstenkampe.de wrote in message 
 news:mpg.284834d227e3acd1989...@news.individual.de...
 
  If someone has learned what a directory or folder is, you don't have
  to explain what include sub-folders means. Instead of creating a
  new mysterious term (recursively delete), you simply explain stuff
  by re- using an already existing term. It's just that simple.
 
 I'm a native english speaker, and to me there is a difference between
 delete directory and sub-directories (or folders and sub-folders if
 you follow Microsoft's naming conventions) and recursively delete. I
 know english is very ambiguous, but to me directory and
 sub-directories does not necessarily imply sub-directories of
 sub-directories and so on,

Are we playing word games here? You can easily improve my example to 
delete directory and all sub-directories beneath. Or delete directory 
and all sub-directories beneath and all content. Or delete directory 
and all files and directories within.

 while recursively delete does carry the connotation of deleting the
 sub-directories of sub-directories and sub-directories of
 sub-directories of sub-directories and so on.

Sure. Because you already know what it means (someone has already 
translated it to you long time ago).

Did your mom tell you to recursively clean up your room?.

Does my file manager ask me are you sure you want to recursively delete 
the folder?? No, it asks 'are you sure you want to remove folder 
folder name and all its contents?'.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* sal migondis (Thu, 26 May 2011 17:50:32 -0400)
 On Thu, May 26, 2011 at 12:28 PM, sal migondis salmi...@gmail.com
 wrote:
  From: Thorsten Kampe thors...@thorstenkampe.de
  It's unnecessary bullshit buzzword bingo from nerds which adds or
  helps or explains nothing. It's just that simple.
 
 This has nothing to do with buzzwords whatsoever.
 
 Despite polite hints from several other posters, the problem is that (like
 the OP) you are not a native speaker of English but you will not listen and
 still think you are qualified to make recommendations regarding usage and
 abusage in the English language.

*sigh* there is nothing in recursively delete which would be specific 
to English. It would be the same in French, Spanish, Italian or German 
(rekursiv löschen).

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue12193] Argparse does not work together with gettext and non-ASCII help text

[Thorsten Kampe]

New submission from Thorsten Kampe thors...@thorstenkampe.de:

Error with argparse and UTF-8 non-ASCII help text on Linux (works on Windows 
and on Linux with optparse):

% LANG=de_De ./script.py --help
Traceback (most recent call last):
  File ./script.py, line 26, in module
args = cmdlineparser.parse_args()
  File /usr/lib/python2.7/argparse.py, line 1678, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File /usr/lib/python2.7/argparse.py, line 1710, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File /usr/lib/python2.7/argparse.py, line 1916, in _parse_known_args
start_index = consume_optional(start_index)
  File /usr/lib/python2.7/argparse.py, line 1856, in consume_optional
take_action(action, args, option_string)
  File /usr/lib/python2.7/argparse.py, line 1784, in take_action
action(self, namespace, argument_values, option_string)
  File /usr/lib/python2.7/argparse.py, line 993, in __call__
parser.print_help()
  File /usr/lib/python2.7/argparse.py, line 2303, in print_help
self._print_message(self.format_help(), file)
  File /usr/lib/python2.7/argparse.py, line 2317, in _print_message
file.write(message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 
91: ordinal not in range(128)

--
components: Unicode
files: script.py
messages: 137013
nosy: thorsten
priority: normal
severity: normal
status: open
title: Argparse does not work together with gettext and non-ASCII help text
versions: Python 2.7
Added file: http://bugs.python.org/file22138/script.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12193
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12193] Argparse does not work together with gettext and non-ASCII help text

[Thorsten Kampe]

Changes by Thorsten Kampe thors...@thorstenkampe.de:


--
type:  - crash

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12193
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12193] Argparse does not work together with gettext and non-ASCII help text

[Thorsten Kampe]

Changes by Thorsten Kampe thors...@thorstenkampe.de:


Added file: http://bugs.python.org/file22139/script.de.po

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12193
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12193] Argparse does not work together with gettext and non-ASCII help text

[Thorsten Kampe]

Changes by Thorsten Kampe thors...@thorstenkampe.de:


Added file: http://bugs.python.org/file22140/script.mo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12193
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: English Idiom in Unix: Directory Recursively

[Thorsten Kampe]

* Rikishi42 (Wed, 25 May 2011 00:06:06 +0200)
 
 On 2011-05-24, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
  I think that is a patronizing remark that under-estimates the
  intelligence of lay people and over-estimates the difficulty of
  understanding recursion.
  
  Why would you presume this to be related to intelligence? The point was
  not about being *able* to understand, but about *needing* to understand
  in order to use.
 
  Maybe they don't need to understand recursion. So what?
 
 I think you should read the earlier posts again, this is drifting so far
 from what I intended.
 
 What I mean is: I'm certain that over the years I've had more than one
 person come to me and ask what 'Do you wish to delete this directory
 recursively?' meant. BAut never have I been asked to explain what 'Do you
 wish to delete this directory and it's subdirs/with all it's contents?'
 meant. Never.

Naming something in the terms of its implementation details (in this 
case recursion) is a classical WTF.

On the other hand, it's by far not the only WTF in Unix. For instance, 
how often have you read unlink instead of delete? Or directory 
instead of folder, pointing out that directory is the correct term 
because a directory is just a listing and does not contain the actual 
files. Of course these implementation details will never matter to 
anyone except under the rarest conditions.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why did Quora choose Python for its development?

[Thorsten Kampe]

* Chris Angelico (Wed, 25 May 2011 08:01:38 +1000)
 
 On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain da...@druid.net wrote:
  One of my favorite quotes (not sure if it was about Perl or APL) is 
I
  refuse to use a programming language where the proponents of it stick
  snippets under each other's nose and say 'I bet you can't guess what
  this does.'
 
 Yes, I believe that was Perl. And an amusing quote. But most of the
 point of it comes from the fact that Perl uses punctuation for most of
 its keywords, whereas (say) Python uses English words; it's a lot more
 fun to crunch something down when you can use $| and friends than when
 you have to put x and y, complete with spaces, for a simple boolean.
 But that says nothing about which language is actually better for
 working with... [...]

It does say something about readibility. And yes, readability counts. 
And yes, readability says a lot about how good a language is for reading 
and working with.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Customize help output from optparse (or argparse)

[Thorsten Kampe]

* Thomas 'PointedEars' Lahn (Thu, 12 May 2011 22:22:20 +0200)
 Thorsten Kampe wrote:
  I'm using optparse for a little Python script.
  
  1. The output from --help is:
  
  Usage: script.py arg
  
  script.py does something
  
  Options:
-h, --help   show this help message and exit
  
  
  I would prefer to have the description before the usage, like...
  
  script.py does something
  
  Usage: script.py arg
  
  Options:
-h, --help   show this help message and exit
  
  [...]
  Is that possible with either optparse or the new kid on the block
  argparse. If so how?
 
 You can easily have #1 with optparse.OptionParser(usage=…)¹, but optparse 
 is deprecated in favor of argparse.ArgumentParser.

I'm already using usage. That's where optparse has it from. Putting the 
usage message into the description and vice versa is of course not a 
viable way to go.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Customize help output from optparse (or argparse)

[Thorsten Kampe]

Hi, 

I'm using optparse for a little Python script.

1. The output from --help is:

Usage: script.py arg

script.py does something

Options:
  -h, --help   show this help message and exit


I would prefer to have the description before the usage, like...

script.py does something

Usage: script.py arg

Options:
  -h, --help   show this help message and exit


2. The output from --doesnotexit is:

Usage: script.py arg

script.py: error: no such option: --doesnotexist


I would prefer to have the error first, then the usage and additionally 
the options, like...

script.py: error: no such option: --doesnotexist

Usage: script.py arg

Options:
  -h, --help   show this help message and exit


Is that possible with either optparse or the new kid on the block 
argparse. If so how?

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to capture all the environment variables from shell?

[Thorsten Kampe]

* Tim Chase (Mon, 26 Jul 2010 21:42:24 -0500)
 On 07/26/10 21:26, Steven W. Orr wrote:
  Please! Never export anything from your .bashrc unless you
  really know what you're doing. Almost all exports should be
  done in your .bash_profile
 
 Could you elaborate on your reasoning why (or why-not)?  I've 
 found that my .bash_profile doesn't get evaluated when I crank up 
 another terminal window, while my bashrc does.  Thus I tend to 
 put my exports in my ~/.bashrc so they actually take effect in my 
 shell...

~/.bash_profile is only evaluated for login shells and ~/.bashrc only 
for non-login shells. Thus it's recommended to keep ~/.bash_profile 
empty (except a source statement for .bashrc) and put all your settings, 
aliases, exports, etc. in .bashrc.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is there a strawberry python?

[Thorsten Kampe]

* Daniel Fetchinson (Sat, 12 Sep 2009 12:54:03 -0700)
 
  the reason I like strawberry perl is that I don't need to have admin right
  to install it. i can just unzip it and start the game.
  i am wondering if there is something similar in python community.
 
  any insight will be appreciated!
 
 As far as I remember there are python installations on USB sticks
 which you can run without any privileges.
 
 http://www.portablepython.com/

Any Python runs without privileges. For some actions (like installing 
new packages) you need to have the appropriate keys in HKCU. But this is 
not required to run Python.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Support for Windows 7 ?

[Thorsten Kampe]

* MRAB (Sat, 05 Sep 2009 17:54:00 +0100)
 Pascale Mourier wrote:
  Martin v. Löwis a écrit :
  
  Without having seen any details, I refuse to guess. Most likely, it is
  a user mistake.
  
  YES IT IS! Sorry for the inconvenience. I usually start from this 
  assumption. Yesterday this new student was really agressive, and I 
  assumed he was right!
  
  Here's his mistake: with Windows the name of the directory rooted at a 
  drive name (say C:) is called 'C:\' not 'C:', and it's been that way for 
  ages.
  Well, os.listdir('C:') instead of raising an exception, for some reason 
  behaves like os.listdir('.').
 
 I believe that in Windows (and inherited from MS-DOS) there's a current
 directory for each drive. If you want to change the current directory to
 another directory on another drive in the Windows command prompt then
 you must change both the current drive and the current directory for
 that drive, eg:

Exactly (or use the /d parameter which is a newer improvement).

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of the Unicode standard

[Thorsten Kampe]

* r (Sat, 29 Aug 2009 18:30:34 -0700 (PDT))
 We don't support a Python group in Chinese or French, so why this?

We do - you don't (or to be more realistic, you simply didn't know 
it).

 Makes no sense to me really.

Like probably 99.9% of all things you hear, read, see and encounter 
during the day.

By the way: the dumbness of your Unicode rant would have even ashamed 
the great XL himself.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of the Unicode standard

[Thorsten Kampe]

* Neil Hodgson (Sun, 30 Aug 2009 06:17:14 GMT)
 Chris Jones:
 
  I am not from these climes but all the same, I do find you tone of
  voice rather offensive, considering that you are referring to a
  culture that's about 3000 years older and 3000 richer than ours and
  certainly deserves our respect.
 
 Eh? Was Unicode developed in India? China?

Chris was obviously talking about Sanskrit...

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of the Unicode standard

[Thorsten Kampe]

* Chris Jones (Sun, 30 Aug 2009 00:22:00 -0400)
 On Sat, Aug 29, 2009 at 11:07:17PM EDT, Neil Hodgson wrote:
  Sanskrit is mostly written in Devanagari these days which is also
  useful for selling things to people who speak Hindi and other Indian
  languages.
 
 Is the implication that the principal usefulness of such languages as
 Hindi and other Indian languages is us selling things to them..? I
 am not from these climes but all the same, I do find you tone of voice
 rather offensive, considering that you are referring to a culture that's
 about 3000 years older and 3000 richer than ours and certainly deserves
 our respect.

Neil was obviously talking about Devanagari. Please also mind the 
principal difference between Neil's also useful and your principal 
useful(ness).

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: An assessment of the Unicode standard

[Thorsten Kampe]

* John Machin (Sat, 29 Aug 2009 17:20:47 -0700 (PDT))
 On Aug 30, 8:46 am, r rt8...@gmail.com wrote:
 
  Take for instance the Chinese language with it's thousands of
  characters and BS, it's more of an art than a language.  Why do we
  need such complicated languages in this day and time. Many languages
  have been perfected, (although not perfect) far beyond that of
  Chinese language.
 
 The Chinese language is more widely spoken than English, is quite
 capable of expression in ASCII (r tongzhi shi sha gua) and doesn't
 have those pesky it's/its problems.

You could also put it differently: the Chinese language (like any other 
language) doesn't even have characters. It's really funny to see how 
someone who rants about Unicode doesn't event knows the most basic 
facts.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: (Simple?) Unicode Question

[Thorsten Kampe]

* Rami Chowdhury (Thu, 27 Aug 2009 09:44:41 -0700)
  Further, does anything, except a printing device need to know the
  encoding of a piece of text?

Python needs to know if you are processing the text.
 
 I may be wrong, but I believe that's part of the idea between separation  
 of string and bytes types in Python 3.x. I believe, if you are using  
 Python 3.x, you don't need the character encoding mumbo jumbo at all ;-)

Nothing has changed in that regard. You still need to decode and encode 
text and for that you have to know the encoding.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Colors on IDLE

[Thorsten Kampe]

* vsoler (Sat, 29 Aug 2009 04:01:46 -0700 (PDT))
 On Aug 29, 1:27 am, r rt8...@gmail.com wrote:
  Have you tried saving the files as MYScriptName.py? notice the py
  extension, very important ;)
 
 That was it!!!
 
 I see the colors again. Thank you.

I suggest you start using familiar technical terms. Like syntax 
highlighting instead of see colours. That would increase the number 
of useful answers you get - at least it will stop people from thinking 
you talk about controlled substances.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Scraping Wikipedia with Python

[Thorsten Kampe]

* Dotan Cohen (Tue, 11 Aug 2009 21:29:40 +0300)
     Wikipedia has an API for computer access.  See
 
         http://www.mediawiki.org/wiki/API
 
 
 Yes, I am aware of this as well. Does anyone know of a python class
 for easily interacting with it, or do I need to roll my own.

http://pypi.python.org/pypi?%3Aaction=searchterm=wikipedia ?

Thorsten 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* Steven D'Aprano (08 Aug 2009 03:29:43 GMT)
 On Fri, 07 Aug 2009 17:13:07 +0200, Thorsten Kampe wrote:
  One guy claims he has times between 2.7 and 5.7 seconds when
  benchmarking more or less randomly generated one million different
  lines. That *is* *exactly* nothing.
 
 We agree that in the grand scheme of things, a difference of 2.7 seconds 
 versus 5.7 seconds is a trivial difference if your entire program takes 
 (say) 8 minutes to run. You won't even notice it.

Exactly.

 But why assume that the program takes 8 minutes to run? Perhaps it takes 
 8 seconds to run, and 6 seconds of that is the decoding. Then halving 
 that reduces the total runtime from 8 seconds to 5, which is a noticeable 
 speed increase to the user, and significant if you then run that program 
 tens of thousands of times.

Exactly. That's why it doesn't make sense to benchmark decode()/unicode
() isolated - meaning out of the context of your actual program.

 By all means, reminding people that pre-mature optimization is a 
 waste of time, but it's possible to take that attitude too far to Planet 
 Bizarro. At the point that you start insisting, and emphasising, that a 
 three second time difference is *exactly* zero,

Exactly. Because it was not generated in a real world use case but by 
running a simple loop one millions times. Why one million times? Because 
by running it only one hundred thousand times the difference would 
have seen even less relevant.

 it seems to me that this is about you winning rather than you giving
 good advice.

I already gave good advice:
1. don't benchmark
2. don't benchmark until you have an actual performance issue
3. if you benchmark then the whole application and not single commands

It's really easy: Michael has working code. With that he can easily 
write two versions - one that uses decode() and one that uses unicode(). 
He can benchmark these with some real world input he often uses by 
running it a hundred or a thousand times (even a million if he likes). 
Then he can compare the results. I doubt that there will be any 
noticeable difference.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* alex23 (Fri, 7 Aug 2009 10:45:29 -0700 (PDT))
 garabik-news-2005...@kassiopeia.juls.savba.sk wrote:
  I am not sure I understood that. Must be my English :-)
 
 I just parsed it as blah blah blah I won't admit I'm wrong and
 didn't miss anything substantive.

Alex, there are still a number of performance optimizations that require 
a thorough optimizer like you. Like using short identifiers instead of 
long ones. I guess you could easily prove that by comparing a = 0 to 
a_long_identifier = 0 and running it one hundred trillion times. The 
performance gain could easily add up to *days*. Keep us updated.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* garabik-news-2005...@kassiopeia.juls.savba.sk (Fri, 7 Aug 2009 
17:41:38 + (UTC))
 Thorsten Kampe thors...@thorstenkampe.de wrote:
  If you increase the number of loops to one million or one billion or
  whatever even the slightest completely negligible difference will
  occur. The same thing will happen if you just increase the corpus of
  words to a million, trillion or whatever. The performance
  implications of that are exactly none.
 
 I am not sure I understood that. Must be my English :-)

I guess you understand me very well and I understand you very well. If 
the performance gain you want to prove doesn't show with 600,000 words, 
you test again with 18,000,000 words and if that is not impressive 
enough with 600,000,000 words. Great.

Or if a million repetitions of your improved code don't show the 
expected performance advantage you run it a billion times. Even 
greater. Keep on optimzing.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* Michael Ströder (Sat, 08 Aug 2009 15:09:23 +0200)
 Thorsten Kampe wrote:
  * Steven D'Aprano (08 Aug 2009 03:29:43 GMT)
  But why assume that the program takes 8 minutes to run? Perhaps it takes 
  8 seconds to run, and 6 seconds of that is the decoding. Then halving 
  that reduces the total runtime from 8 seconds to 5, which is a noticeable 
  speed increase to the user, and significant if you then run that program 
  tens of thousands of times.
  
  Exactly. That's why it doesn't make sense to benchmark decode()/unicode
  () isolated - meaning out of the context of your actual program.
 
 Thorsten, the point is you're too arrogant to admit that making such a general
 statement like you did without knowing *anything* about the context is simply
 false.

I made a general statement to a very general question (These both 
expressions are equivalent but which is faster or should be used for any 
reason?). If you have specific needs or reasons then you obviously 
failed to provide that specific context in your question.
 
  By all means, reminding people that pre-mature optimization is a 
  waste of time, but it's possible to take that attitude too far to Planet 
  Bizarro. At the point that you start insisting, and emphasising, that a 
  three second time difference is *exactly* zero,
  
  Exactly. Because it was not generated in a real world use case but by 
  running a simple loop one millions times. Why one million times? Because 
  by running it only one hundred thousand times the difference would 
  have seen even less relevant.
 
 I was running it one million times to mitigate influences on the timing by
 other background processes which is a common technique when benchmarking.

Err, no. That is what repeat is for and it defaults to 3 (This means 
that other processes running on the same computer may interfere with the 
timing. The best thing to do when accurate timing is necessary is to 
repeat the timing a few times and use the best time. [...] the default 
of 3 repetitions is probably enough in most cases.)

Three times - not one million times. You choose one million times (for 
the loop) when the thing you're testing is very fast (like decoding) and 
you don't want results in the 0.0n range. Which is what you asked 
for and what you got.

  I already gave good advice:
  1. don't benchmark
  2. don't benchmark until you have an actual performance issue
  3. if you benchmark then the whole application and not single commands
 
 You don't know anything about what I'm doing and what my aim is. So your
 general rules don't apply.

See above. You asked a general question, you got a general answer.
 
  It's really easy: Michael has working code. With that he can easily 
  write two versions - one that uses decode() and one that uses unicode().
 
 Yes, I have working code which was originally written before .decode() being
 added in Python 2.2. Therefore I wondered whether it would be nice for
 readability to replace unicode() by s.decode() since the software does not
 support Python versions prior 2.3 anymore anyway. But one aspect is also
 performance and hence my question and testing.

You haven't done any testing yet. Running decode/unicode one million 
times in a loop is not testing. If you don't believe me then read at 
least Martelli's Optimization chapter in Python in a nutshell (the 
chapter is available via Google books).

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* alex23 (Fri, 7 Aug 2009 06:53:22 -0700 (PDT))
 Thorsten Kampe thors...@thorstenkampe.de wrote:
  Bollocks. No one will even notice whether a code sequence runs 2.7 or
  5.7 seconds. That's completely artificial benchmarking.
 
 But that's not what you first claimed:
 
  I don't think any measurable speed increase will be
  noticeable between those two.
 
 But please, keep changing your argument so you don't have to admit you
 were wrong.

Bollocks. Please note the word noticeable. noticeable as in 
recognisable as in reasonably experiencable or as in whatever.

One guy claims he has times between 2.7 and 5.7 seconds when 
benchmarking more or less randomly generated one million different 
lines. That *is* *exactly* nothing.

Another guy claims he gets times between 2.9 and 6.2 seconds when 
running decode/unicode in various manifestations over 18 million 
words (or is it 600 million?) and says the differences are pretty 
significant. I think I don't have to comment on that.

If you increase the number of loops to one million or one billion or 
whatever even the slightest completely negligible difference will occur. 
The same thing will happen if you just increase the corpus of words to a 
million, trillion or whatever. The performance implications of that are 
exactly none.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* Michael Ströder (Fri, 07 Aug 2009 03:25:03 +0200)
 Thorsten Kampe wrote:
  * Michael Ströder (Thu, 06 Aug 2009 18:26:09 +0200)
  timeit.Timer(unicode('äöüÄÖÜß','utf-8')).timeit(1000)
  17.23644495010376
  timeit.Timer('äöüÄÖÜß'.decode('utf8')).timeit(1000)
  72.087096929550171
 
  That is significant! So the winner is:
 
  unicode('äöüÄÖÜß','utf-8')
  
  Unless you are planning to write a loop that decodes äöüÄÖÜß one 
  million times, these benchmarks are meaningless.
 
 Well, I can tell you I would not have posted this here and checked it if it
 would be meaningless for me. You don't have to read and answer this thread if
 it's meaningless to you.

Again: if you think decoding äöüÄÖÜß one million times is a real world 
use case for your module then go for unicode(). Otherwise the time you 
spent benchmarking artificial cases like this is just wasted time. In 
real life people won't even notice whether an application takes one or 
two minutes to complete.

Use whatever you prefer (decode() or unicode()). If you experience 
performance bottlenecks when you're done, test whether changing decode() 
to unicode() makes a difference. /That/ is relevant.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* Steven D'Aprano (06 Aug 2009 19:17:30 GMT)
 On Thu, 06 Aug 2009 20:05:52 +0200, Thorsten Kampe wrote:
   That is significant! So the winner is:
   
   unicode('äöüÄÖÜß','utf-8')
  
  Unless you are planning to write a loop that decodes äöüÄÖÜß one
  million times, these benchmarks are meaningless.
 
 What if you're writing a loop which takes one million different lines of 
 text and decodes them once each?
 
  setup = 'L = [abc*(n%100) for n in xrange(100)]'
  t1 = timeit.Timer('for line in L: line.decode(utf-8)', setup)
  t2 = timeit.Timer('for line in L: unicode(line, utf-8)', setup)
  t1.timeit(number=1)
 5.6751680374145508
  t2.timeit(number=1)
 2.682251165771
 
 Seems like a pretty meaningful difference to me.

Bollocks. No one will even notice whether a code sequence runs 2.7 or 
5.7 seconds. That's completely artificial benchmarking.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is python buffer overflow proof?

[Thorsten Kampe]

* Neil Hodgson (Tue, 04 Aug 2009 13:32:55 GMT)
 Thorsten Kampe:
  You cannot create your own buffer overflow in Python as you can in 
C 
  and C++ but your code could still be vulnerable if the underlying Python 
  construct is written in C.
 
Python's standard library does now include unsafe constructs.

I don't doubt that. If Python contains a buffer overflow vulnerability 
your code will also be susceptible to that. Please read the link I 
provided as an example.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: unicode() vs. s.decode()

[Thorsten Kampe]

* Michael Ströder (Wed, 05 Aug 2009 16:43:09 +0200)
 These both expressions are equivalent but which is faster or should be
 used for any reason?
 
 u = unicode(s,'utf-8')
 
 u = s.decode('utf-8') # looks nicer

decode was added in Python 2.2 for the sake of symmetry to encode(). 
It's essentially the same as unicode() and I wouldn't be surprised if it 
is exactly the same. I don't think any measurable speed increase will be 
noticeable between those two.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list