private im modul

[elch]

hallo.

gibt es eine möglichkeit die "attribute" eines moduls A nicht zugänglich zu machen für andere module, die A importieren?
für klassen ist das ja kein thema, aber bei modulen bin ich ratlos.

könnte so was nämlich gut gebrauchen.

vielen dank
elch

[Leonidas]

Nein, aber die Attribute kannst du mit _attribut oder __attrirubut benennen (also mit einem oder zwei Unterstrichen). Das ist Python Konvention und bedeutet, dass Programmierer darauf nicht zugreifen sollten. Aber darauf zugreifen kann man schon noch, von dem her unterstützt Python kein private (und es fehlt auch nicht).

[fs111]

Wenn man from foo import * macht, werden die "_"-Sachen übrigens nicht mitimportiert, also schon in gewisser Weise private.

fs111

[Leonidas]

Wenn man from foo import * macht

Wusste ich noch gar nicht, aber man sollte *-Imports sowieso nicht machen.

[Erwin]

...
Wusste ich noch gar nicht, aber man sollte *-Imports sowieso nicht machen.

Davon habe ich schon mal gelesen.
Weil dies dann mehr an Speicher ect. braucht?
Ist das wirklich so gravierend?
Oder gibt es da noch einen anderen Grund?

[Leonidas]

Das nicht, nur dadurch:

• Werden vielleicht deinen Variablen überschrieben (promenintestes Beispiel ist PIL, die man mit import Image einbindet und dann von Tkinter .Image überschrieben wird (ohne jegliche Warnung)
• es den Namensraum deines Programmes zumüllt. Ich nutze gerne dir() um zu schauen was in einem Modul drin ist. Dazu mal eine kleine Übung in der Konsole.
  

  Code: Alles auswählen

  >>> dir()
['__builtins__', '__doc__', '__name__']
>>> len(dir())
3
>>> from Tkinter import *
>>> len(dir())
177
>>> from qt import *
>>> len(dir())
476
>>> from gtk import *
>>> len(dir())
1410
• Alles in allem macht es deinen Code großartig unlesbar und ist nicht zu empfehlen. Parktisch ist es eigentlich nur, wenn du in der Python Konsole schnell was ausprobieren willst.

[Erwin]

1410?
Wahnsinn.
Also am besten alles extra importieren?
Dann bekommt man eigentlich auch automatisch mit, wenn etwas doppelt vorhanden ist, also Namentlich?
Das kann teilweise heiter werden.
Schade daß sich einiges Namentlich gegenseitig überschreibt.

[Leonidas]

1410?
Wahnsinn.

Naja, wobei es jetzt vielleicht weniger warscheinlich ist, das ein Programm gleichzeitig drei GUIs nutzt.. mir reicht meist GTK völlig

Also am besten alles extra importieren?
Dann bekommt man eigentlich auch automatisch mit, wenn etwas doppelt vorhanden ist, also Namentlich?

Ja, du kannst folgendes machen:

Code: Alles auswählen

import Image
from Tkinter import Image

und dann merkst du es schon, wenn du nicht schon viel zu lange am Rechner sitzt

Aber Tkinter würde ich so importieren:

Code: Alles auswählen

import Tkinter as tk
import Image

damit kann ich auf sowohl auf PILs Image zugreifen als auch auf tk.Image. Was mich bei Qt genervt hat, ist dass wenn man

Code: Alles auswählen

import qt

macht, dass man dann vor allen Namen ein 'Q' hat, also 'QApplication' usw. Dann muss man auf qt.QApplication zugreifen und das finde ich, ist doppelt gemoppelt. Das hat mich soweit gestört, dass ich ein Modul namens qtwrap geschrieben habe, das beim importieren die ganzen Namen ändert und ich dann so porgrammieren kann:

Code: Alles auswählen

import qtwrap as qt
app = qt.Application([])

was mir schon wesentlich besser gefällt. Ich programmiere sehr gerne mit Namespaces, die eignen sich gut um Ordnung in den Programmen zu halten und stimme dem "Zen of Python" zu:

Namespaces are one honking great idea -- let's do more of those!

Das kann teilweise heiter werden.
Schade daß sich einiges Namentlich gegenseitig überschreibt.

Ich mache es so wie hier beschrieben, damit habe ich praktisch nie Probleme.

Und dass es sich überschreibt, ist ja eigentlich auch ganz logisch, was soll es denn sonst tun? Mit dem bewussten Überschreiben kann man zum Teil auch nützliche DInge machen.

[Erwin]

Aber Tkinter würde ich so importieren:

Code: Alles auswählen

import Tkinter as tk
import Image

damit kann ich auf sowohl auf PILs Image zugreifen als auch auf tk.Image.

Oje oje.
Hört sich alles etwas verwirrend an, wenn es mehre Möglichkeiten gibt.
Irgendwie sehne ich mich jetzt wieder nach Omicron-Basic zurück.
Was hat es sich mit den 'as' auf sich?
Wo ist da der Unterschied zwischen
- from Tkinter import Tk
und
- import Tkinter as Tk
?

[BlackJack]

Was hat es sich mit den 'as' auf sich?

Damit kann man etwas importieren und an einen anderen Namen binden.

Wo ist da der Unterschied zwischen
- from Tkinter import Tk
und
- import Tkinter as Tk
?

Das erste importiert nur die Klasse `Tk` aus dem Modul `Tkinter` und das zweite importiert das Modul `Tkinter` und bindet es an den Namen `Tk`. Auf die Klasse greift man dann mit `Tk.Tk()` zu. Am besten probiert man solche Sachen im interaktiven Interpreter aus und schaut sich sozusagen "live" an, was passiert.

Es gibt noch eine Falle bei dem Import mit ``*``: Die Attribute aus dem importierten Modul werden alle an Namen im importierenden Modul gebunden. Wenn man zum Beispiel eine Anwendung hat, die man auf mehrere Module, sagen wir mal `mod_a` und `mod_b` aufgeteilt hat und nun ein Modul mit dem Namen `optionen` erstellt, um gemeinsame Optionen zu speichern, dann macht folgendes nicht das, was man vielleicht annehmen könnte:

Code: Alles auswählen

# optionen.py
blah = 42

Code: Alles auswählen

# mod_a.py
from optionen import *
blah = 5
import mod_b

Code: Alles auswählen

# mod_b.py
import optionen
print optionen.blah

Da wird 42 ausgegeben, weil in Modul A nicht der Name `blah` im Modul `optionen` an die 5 gebunden wird, sondern der Namen `blah` im Modul A selbst.

[Leonidas]

Wenn man from foo import * macht, werden die "_"-Sachen übrigens nicht mitimportiert, also schon in gewisser Weise private.

Ich habe das jetzt mal gecheckt:

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
_val = True
__val = True

Das wäre mal das Modul privmod.

Code: Alles auswählen

>>> import privmod
>>> dir(privmod)
['__builtins__', '__doc__', '__file__', '__name__', '__val', '_val']
>>> privmod._val
True
>>> True
>>> privmod.__val
True

Nein, so wie ich sehe werden die Sachen doch importiert (Python 2.4.1).

[Olliminatore]

Sry mal Nebenfrage:
Wie kann man module/attribute wieder entladen und wann ist es nützlich? (finde es einfach nicht)

[gerold]

Nein, so wie ich sehe werden die Sachen doch importiert (Python 2.4.1).

Hi Leonidas!

fs11 schrieb from foo import *. Das macht schon einen Unterschied

lg
Gerold

[Leonidas]

fs11 schrieb from foo import *. Das macht schon einen Unterschied

Ohje, stimmt. Wie kommt es dass ich heute schon so früh so total fertig bin, dass ich so einen Schmarrn gemacht habe?

Wie kann man module/attribute wieder entladen und wann ist es nützlich? (finde es einfach nicht)

Die kannst mit del <Modul> die Referenz löschen. Nützlich ist es.. nie, denn wenn du das Modul zwischendrin geändert hast, wird sowieso per import wieder die alte Version geladen. Deswegen gibt es um Module neu zu laden das Builtin reload().

del braucht man sowieso recht selten, da der GC die Objekte löscht, wenn sie nicht mehr benötigt werden, somit muss der Programmierer sich nicht darum kümmern.