…wie Sterne- und TV- und Promi-Köche wie Alfons Schuhbeck für Convenience Lebensmittel werben können. Ist es egal dass damit Leute geschmacklich verdummt und gleichgeschaltet werden? Meinen Sie, Herr Schuhbeck, vielleicht, das einfache Volk wird sich Ihre Gourmetgenüsse eh nie leisten können oder wollen, so daß man diesen bitteschön auch Convenience Food zumuten kann? Oder wieso machen Sie sich – offensichtlich wider besseren Wissens – zur Werbe-Hure der Lebensmittelindustrie?

…wie Frau Katharina Saalfrank Ihre Rolle als Super Nanny vor ihren vier Kindern rechtfertigen will. “Egal wie peinlich und erniedrigend für die Teilnehmer der Sendung, Hauptsache die Kohle stimmt”?

Wer bleibt standhaft wenn der Dollar lockt?

Gibt es Grenzen für Erniedrigung, Bloßstellung und Abzocke von Menschen aus geistigen Unterschichten? Haben wir uns irgendwann genug an Leid, Dummheit, Naivität und Armut von Hartz-4 Empfängern ergötzt?

Sind wir uns alle selbst am nächsten?

Vielleicht kannst Du man mal wieder was für andere tun? Oder für “die anderen”, zum Beispiel in der Firma mal den Geschirrspüler befüllen oder ausräumen, den Tisch abwischen, die Spüle säubern, den Lappen ausspülen? Oder einfach mal keine großen Geschenke zu Weihnachten und stattdessen mal Geld spenden statt Geld zu scheffeln?

https://sourceforge.net/projects/mycontextmenu/

With Python 2.x on Windows the functions of the os module seem to require the encoding specified in os.getfilesystemencoding() to output/use German umlauts (äÄüÜöÖ) and “ess-zett” (ß) properly:

Probably/typically wrong:


import os
os.system("echo ä")


Output:

“
0

Probably/typically correct:


import os, sys
encoded_in_cp850 = "echo ä"
encoded_in_unicode = encoded_in_cp850.decode("cp850")
encoded_in_fs_encoding = encoded_in_unicode.encode(sys.getfilesystemencoding()
os.system(encoded_in_fs_encoding)


(“cp850″ is the codepage on my German Windows 7.)

(In short: os.system("echo ä".decode("cp850").encode(sys.getfilesystemencoding())))

Output:

ä
0

The above probably applies to os.getcwd() and others as well.

sys.stdout/stderr

And with Python 2.x on Windows the encoding used by sys.stdout and sys.stderr are available in the “encoding” property of sys.stdout and sys.stderr:

Possibly wrong when the source of “s” uses a different encoding than sys.stdout:


sys.stdout.write(s)


Probably right when the source of “s” uses a different encoding than sys.stdout:


s_unicode = s.decode("")
s_stdout_encoding = s_unicode.encode(sys.stdout.encoding)
sys.stdout.write(s_stdout_encoding)


( must be the encoding of “s”.)

(In short: sys.stdout.write(s.decode("").encode(sys.stdout.encoding)))

• Hat der Gast weitere Wünsche? Augenkontakt und Nähe des Gastes suchen; gegebenenfalls unaufdringlich ansprechen.
• Sind Tassen, Becher, Gläser des Gastes leer? Möchte er noch etwas bestellen? Ansprechen.
• Möchte der Kunde zahlen? Rechnung bringen und zahlen lassen. Falls Rechnung beim Kunden abgelegt wird, Kunden nach kurzer Zeit wieder ansprechen, da er gegebenenfalls Geld wechseln möchte.

Nachbestellungen

• Nachbestellung muss vollständig sein. (Beispiel: Bei Erstbestellung eines Milchkaffee werden Milchkaffee + Glas Wasser gereicht, dann muss die Nachbestellung eines Milchkaffee auch ein Glas Wasser enthalten.)

Sauberkeit & Ordnung

• Leere Tische zügig abräumen.
• Leere Tische säubern.
• Boden säubern.
• Umgeräumte Stühle und Tische zurück räumen.

Für Gäste zu beachten:

Guter Service muss sich im Trinkgeld (ca. 10% des Rechnungsbetrags) widerspiegeln. Im Hamburger Raum scheint dies nicht der Fall zu sein, da ich dort selten guten Service erlebe.

While it is very nice that it is possible to add this at all, I wonder if any of the SWT, JFaces, Nebula developers ever stop to think whether it really should take ~200 lines of code to get such a feature. Personally I would have expected this feature to be included already, ready to be enabled with a single line of code.

In Python they’d call such a case “no batteries included”, I guess.

And it’s far from the (alleged?) Java promise “make simple things easy and the complicated possible”, because here the simple things are complicated.

Pointing someone asking for how to rename a project programmatically to MoveResourcesOperation would be useful, if…

1) …the API documentation for the Eclipse RCP framework would pick the original poster up at that point (documented uses of the class inside the Eclipse RCP: 0; and it throws things like “IPath” at the humble reader)

2) … or if the internet would spill over with examples for using MoveResourcesOperation (10 hits for “new MoveResourcesOperation”).

What can be done to improve the current situation? Maybe every new API, method, class, extension point, etc. in the Eclipse RCP framework must be accompanied by a tiny and self-contained example before a release build of Eclipse is allowed to be shipped as “stable” or “final”.

As it is now, the Eclipse RCP is horribly frustrating to develop for, not because it is a vast and over-engineered framework (which it is in my opinion), but because of lack of examples and documentation for a vast number of very common use cases.

Moving the folder back via Windows Explorer takes about 23 to 25 seconds (!).

Moving the folder back and forth via “move” command in cmd.exe takes roughly 1 second.

Given that moving a directory on the same partition is a very cheap operation on NTFS, the last figure seems acceptable, the second one leaves me unsatisfied and the first figure – plus the fact that it is 4+ times as slow to move in the other direction – leaves me with the feeling that some Microsoft developers suck just as much as everybody else at programming.

Throw in the complaints about perceived performance issues in Windows Vista and I am at wits end as to what the heck the product managers and developers at Microsoft are thinking when they decide not to fix these issues.

The system specs:

Windows Vista Ultimate, SP1
AMD Dual Core 4450e
4 GB RAM

def test():
    """Documentation for method test."""

    # If file exists:
    ...
        # Delete file
        ...
    # Do this
    ...
    # Do that
    ...

But what if you want to document the algorithm used in the body of that method so that it shows up in the pydoc output as well? You could just add it to the pydoc comment explicitly:

def test():
    """Documentation for method test.

    It uses the following steps:
        If file exists
            Delete file
        Do this
        Do that"""

    # If file exists:
    ...
        # Delete file
        ...
    # Do this
    ...
    # Do that
    ...

Because the code already contains the documentation of each step adding each to the pydoc comment is uncomfortable, a duplication of effort.

By “extending” pydoc the duplication effort can be removed, so that documenting the algorithm could look like this:

def test():
    """Documentation for method test."""

    #ALGO: If file exists:
    ...
        #ALGO: Delete file
        ...
    #ALGO: Do this
    ...
    #ALGO: Do that
    ...

Note how the prefix “ALGO” in the comments is used to mark a comment as a comment for the algorithm.

Here is how to “extend” pydoc to support this functionality (contents of a file “pydoc_algo.py” created by you):

import pydoc
import inspect

def test():
    """This is an example of algorithm documentation entries.

    Note using capitalized keyword "ALGO" to see
    algorithm pydoc entries more quickly in the
    code.

    Also note the use of "pass" in the example: If
    a comment is not followed by at least one line
    of actual code it does not end up in
    inspect.getsource() and inspect.getsourcelines."""

    #ALGO: If file exists:
    if True:
        #ALGO: Delete file
        pass

    #ALGO: Create the file
    pass

    #ALGO: Open file
    pass

    #ALGO: Write data to file
    pass

    #ALGO: Close file
    pass

def getdoc(object):
    algoComments = []
    sourceLines = inspect.getsourcelines(object)[0]
    for line in sourceLines:
        lineLower = line.lower()

        while True:
            s = "# algo "
            if lineLower.find(s) != -1:
                break
            s = "# algo: "
            if lineLower.find(s) != -1:
                break
            s = "#algo "
            if lineLower.find(s) != -1:
                break
            s = "#algo: "
            if lineLower.find(s) != -1:
                break

            s = None
            break

        if s is not None:
            start       = lineLower.find(s)
            end         = start + len(s)
            indent      = line[:start - 1]
            algoComment = line[end:]
            algoComments.append(indent + algoComment)

    s = inspect_getdoc(object)

    if len(algoComments) > 0:
        s += "\n\nAlgorithm:\n"
        for c in algoComments:
            s += c

    return s

# "Install" the extension by replacing inspect.getdoc().
# Keep the reference to the previous inspect.getdoc()
# to call it ourselves.
inspect_getdoc = inspect.getdoc
inspect.getdoc = getdoc

if __name__ == "__main__":
    pydoc.help(test)

Here is an example call:

>>> import pydoc
>>> pydoc.help(pydoc_algo.test)
Help on function test in module pydoc_algo:

test()
    This is an example of algo documentation entries.

    Note using capitalized keyword "ALGO" to see
    algorithm pydoc entries more quickly in the
    code.

    Also note the use of "pass" in the example: If
    a comment is not followed by at least one line
    of actual code it does not end up in
    inspect.getsource() and inspect.getsourcelines.

    Algorithm:
       If file exists:
           Delete file
       Create the file
       Open file
       Write data to file
       Close file

>>>

This approach could be useful for “To do” entries too (“#ToDo: Do this and that here in the code!”).