private im modul

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
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 :D
elch
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
fs111
User
Beiträge: 170
Registriert: Samstag 15. November 2003, 11:42
Kontaktdaten:

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

fs111
Pydoc-Integration in vim - Feedback willkommen: http://www.vim.org/scripts/script.php?script_id=910
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

fs111 hat geschrieben:Wenn man from foo import * macht
Wusste ich noch gar nicht, aber man sollte *-Imports sowieso nicht machen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben:...
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?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

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.
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Erwin hat geschrieben:1410?
Wahnsinn.
Naja, wobei es jetzt vielleicht weniger warscheinlich ist, das ein Programm gleichzeitig drei GUIs nutzt.. mir reicht meist GTK völlig :D
Erwin hat geschrieben: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 8)

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:
import this hat geschrieben:Namespaces are one honking great idea -- let's do more of those!
Erwin hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Erwin
User
Beiträge: 141
Registriert: Donnerstag 9. Juni 2005, 08:51

Leonidas hat geschrieben: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
?
Ich mache nie einen Fehler Zweimal.
Schließlich ist die Auswahl ja groß genug.
BlackJack

Erwin hat geschrieben: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
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

fs111 hat geschrieben: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).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Olliminatore
User
Beiträge: 55
Registriert: Montag 30. Mai 2005, 16:03
Wohnort: schönsten Stadt Deutschlands
Kontaktdaten:

Sry mal Nebenfrage:
Wie kann man module/attribute wieder entladen und wann ist es nützlich? (finde es einfach nicht)
Zuletzt geändert von Olliminatore am Freitag 10. Juni 2005, 12:55, insgesamt 1-mal geändert.
[size=84][url=http://de.wikipedia.org/wiki/Jamba]Love Jamba[/url] <!--Olliminatore-->input<?/> [url=http://www.spreeblick.com/blog/index.php?p=324]Boycott Jamba[/url][code]def olliminiert(optimiert, eliminiert, terminiert):[/code][/size]
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Leonidas hat geschrieben: 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 :wink:

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

gerold hat geschrieben:fs11 schrieb from foo import *. Das macht schon einen Unterschied :wink:
Ohje, stimmt. Wie kommt es dass ich heute schon so früh so total fertig bin, dass ich so einen Schmarrn gemacht habe? :oops:
Olliminatore hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten