Pycante 0.1a

Hace un tiempo vi u proyecto interesante que se llamaba mu-dev. Me intereso la funcionalidad asi que me contacte con el desar

rollador para colaborar pero el desarrollador me dijo “la colaboración con parches va a estar disponible en un futuro”. Asi que me dije a mi mismo “Puedo hacer algo similar (o mejor)” asi que bueno… asi nació pycante.

Pycante

La idea del proyecto es utilizar de manera comoda los archivos “.ui” de QtDesigner de la siguiente manera:

import pycante

from PyQt import QtGui

# using path
class Window0(pycante.E("path/to/file/window0.ui")):

    def on_buttonBox_accepted(self):
        # buttonBox exist inside "window.ui"
        print "you push accept"

# using file
class Window1(pycante.E(open("path/to/file/window0.ui"))):

    def on_buttonBox_accepted(self):
        # buttonBox exist inside "window.ui"
        print "you push accept"

# using widget
class Window2(pycante.E(QtGui.QDialog)):

    def setupUi(self, Dialog):
        self.buttonBox = QtGui.QDialogButtonBox(Dialog)
        self.buttonBox.setOrientation(QtCore.Qt.Horizontal)
        self.buttonBox.setStandardButtons(QtGui.QDialogButtonBox.Cancel|QtGui.QDialogButtonBox.Ok)
        self.buttonBox.setObjectName(_fromUtf8("buttonBox"))

        self.retranslateUi(Dialog)
        QtCore.QObject.connect(self.buttonBox, QtCore.SIGNAL(_fromUtf8("accepted()")), Dialog.accept)
        QtCore.QObject.connect(self.buttonBox, QtCore.SIGNAL(_fromUtf8("rejected()")), Dialog.reject)
        QtCore.QMetaObject.connectSlotsByName(Dialog)

    def retranslateUi(self, Dialog):
        Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog", "Dialog", None,                QtGui.QApplication.UnicodeUTF8))

    def on_buttonBox_accepted(self):
        # buttonBox exist inside "window.ui"
        print "you push accept"

if __name__ == "__main__":
    w0 = Window0()
    w0.show()

    w1 = Window1()
    w1.show()

    w2 = Window2()
    w2.show()

    pycante.run()

Para instalar:

$ pip install pycante

o

$ easy_install pycante

o bajarlo de aca: https://bitbucket.org/leliel12/pycante/

Disclaimers:

  • Lo hice por una necesidad muy puntual
  • El codigo de “W3″ no lo probe aunque puede usarse asi pycante
  • Como notaran en ni un momento llame a SetupUi()… eso pycante lo hace solo.


				

Leer Más

A PARTIR DE HOY…

A PARTIR DE HOY…
  • No quiero escuchar quejarse a las amas de casa por la inflación;
  • no quiero escuchar quejarse a la gente del campo.
  • No quiero escuchar a los jubilados diciendo que no les alcanza para vivir.
  • No quiero escuchar a nadie hablar de INSEGURIDAD Y DELINCUENCIA.
  • No quiero escuchar decir que es el país de mayor corrupción.

EN ARGENTINA LA GENTE ELIGIÓ ESTE MODELO DE PAÍS Y DE VIDA

Leer Más

Django-hateconf 0.2.3

Odio configurar cosas, y mas odio olvidarme que mi settings.py de django esta versionado y subir algún password mio a un repo publico.

Así que probé varias soluciones de archivos de conf distribuidos pero todos metían conceptos nuevos que no me interesaba descular.

En fin… hice esto

django-hateconf

Las premisas eran:

  • el setttings.py original es suficiente información para utilizar de templates y de schema para los archivos externos.
  • Las conf pueden guardarse en varios formatos a gusto del usuario del proyecto.

Bueno a los bifes:

  • Paso 1:  Instalar

$ pip install django-hateconf

o

$ easy_install django-hateconf

o bajarlo de aca: https://bitbucket.org/leliel12/django-hateconf/

  • Paso 2: Crear proyecto django

$ django-admin start-project myproject
  • Paso 3: Editar el “settings.py” y agregar a la variable INSTALLED_APPS, django_hateconf.

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',

"django_hateconf",
)
  • Paso 4: Editar al “settings.py” de myproject y agregar esta variable

SETTINGS_BIND = {
    "file":
        "archivo.yaml",
    "bind":
        ("DATABASES", "DEBUG"),
    "header":
        "Este es un archivo de configuracion del proyecto myproject"
}

Esta diccionario tiene las siguientes llaves:

  • file: El cual es un path a un archivo que va a contener la configuración que va  a utilizar nuestro proyecto. El formato del archivo se deduce desde su extensión (NO es case sensitive); las cuales pueden ser:
  • “.yml” o “.yaml”  para  formato yaml YAML (
  •  “.json” para formato JSON (http://www.json.org/).
  •  “.xml” para formato XML (http://www.w3.org/XML/).
  •  “.cfg” o “.ini” pata formato que consiste en secciones que empiezan con la cabecera “[section]”y continua con combinaciones de “llave = valor” en el estilo
    de la RFC 822.
  • bind: Es una lista o tupla que contiene los nombres de las variables de settings.py que se deseamos que se configuren desde nuestro archivo. Con este campo, django-hateconf, busca por su nombre a las  variables en el settings.py y con su contenido genera un template en el formato especificado en el campo file. Las reglas para el contenido del campo bind son:
  • Las variables deben existir en el settings.py
  • No se puede “bindear” SETTINGS_BIND
  • Si en nuestro archivo declarado en file, por ejemplo, bindeamos la variable “TIME_ZONE” y esta no esta en el campo bind, django-hateconf  ignorará el bindeo y se utilizara el valor dentro del settings.py,
  • El valor que se asigne a las variables dentro de nuestro file, tiene que ser un valor “casteable” al que tenemos asignado a la misma variable dentro del settings.py. Para entender si decimos que la variable “A = 1″ en nuestro settings.py cualquier cosa que pueda convertirse automaticamente a un “int” puede existir dentro de nuestro archivo declarado en file. Un caso particular es el valor None el cual acepta cualquier objeto sin castearlo cuando se bindea.
  • Si el valor es una lista, tupla, diccionario o set; el casteo se hace recursivamente. Asi que los valores internos a estas colecciones también deben ser casteables.
  • header: Es el comentario que llevara en la cabecera el archivo declarado en file. Este campo es opcional.
  • Paso 5: Agregar al final de “settings.py” estas dos lineas:

import django_hateconf
django_hateconf.patch(locals())
  • Paso 6: Ejecutar…

$ python manage.py settings --sync

Con esto deberia haberse creado un nuevo archivo “archivo.yaml” en la misma carpeta del proyecto exactamente así:

# Este es un archivo de configuracion del proyecto myproject
– DATABASES:
default:
ENGINE: django.db.backends.dummy
HOST: ”
NAME: ”
OPTIONS: {}
PASSWORD: ”
PORT: ”
TEST_CHARSET: null
TEST_COLLATION: null
TEST_MIRROR: null
TEST_NAME: null
TIME_ZONE: America/Chicago
USER: ”
– DEBUG: true

Bueno para configurar su database solo tiene que editar su archivo.yaml.

Las otras opciones que da django hateconf son:

python manage.py settings --path                 Dice donde esta el archivo de configuración
 python manage.py settings --show                 Muestra el settings ya mergeado.
 python manage.py settings --sync                 Sincroniza los archivos
 python manage.py settings --vars     Muestra los valores de las variables ya bindeados
 python manage.py settings --formats              Lista los formatos validos para los archivos de configuración
 python manage.py settings --validate             Busca errores en nuestro archivo de bindeo
 python manage.py settings -h, --help             Muestra una ayuda

Links al proyecto

Leer Más