Reprise du message précédent :
attention, c'est super-débile :
y'a juste un handler de base qui s'appelle wsgi-script (il faut ajouter le droit d'execCGI avec), du coup c'est pas la peine d'aller chercher dans la conf de mod_wsgi, c'est de la conf apache de base.
 
J'ai juste mis ça dans un .htaccess :

 
Je le mets ici parce que c'est tellement con que c'est difficile à trouver dans la doc (je l'ai vu en passant dans un exemple).

Petit truc à faire attention si vous faites des scripts standalones utilisant l'ORM de Django. Il ne faut pas oublier de fermer manuellement la connexion à la fin du script avec un connection.close(), ce n'est pas fait automatiquement.
Or certains SGDB (MySQL par exemple), bloque un hote si trop de connexions successives sont interrompues... Du coup si vous avez un script en cron et peu d'activité (la nuit par exemple) pour "reset" ce counter... Vous pouvez bloquer votre hôte sans le vouloir (bon y a toujours la possibilité d'augmenter le nombre de fails consécutifs sous MySQL, mais c'est pas top )

quelqu'un sait comment une OSError est sensée remonter dans les logs ? là elle est bouffée et *tout* peut avoir été touché.

Pas compris la question
T'as une OSError mais tu vois rien dans tes logs ? Comment tu sais que c'est une OSError alors ?
 
Normalement si t'as rien configuré de spécial tu dois avoir au moins un truc qui passe dans le error.log d'apache

c'est bon, j'ai été emmerdé par : http://python.6.n6.nabble.com/Logg [...] 82168.html
 

pour les migrations, vous voyez mieux que south ? On doit en mettre un, alors c'est l'occasion d'étudier le marché.

J'avoue avoir pris south y a 2/3 ans et être resté dessus depuis, sans trop regarder ce qu'il y avait à coté depuis. Faut dire qu'une fois un système de migration choisi tu t'amuses rarement à en changer en cours de route.
Si tu trouves des trucs intéressants par ailleurs ça m’intéresse aussi.

j'ai vaguement googlé et j'ai pris south, c'est le plus connu, et y'a pas d'autre tendance.

C'est peut être déjà passé, mais un blog super intéressant sur PostgreSQL, Django et son ORM. ca couvre aussi des notions assez génériques sur les SGBD et les ORM, même si c'est axé principalement sur ces 2 technos :
 
http://thebuild.com/blog/

if request.method == 'POST':
        pass #blah
    response = HttpResponse(status=405)
    response['Allow'] = 'POST'
    return response

j'ai bon ?

edit : http://www.w3.org/Protocols/rfc261 [...] ml#sec14.7
http://www.w3.org/Protocols/rfc261 [...] #sec10.4.5
je demande si j'ai bien capté la spec.

if request.method == 'POST':
        pass #blah
    response = HttpResponse(status=405)
    response['Allow'] = 'POST'
    return response

Ça me semble correct, mais complètement redondant

(et j'aurais tendance à inverser la condition pour faire un early return, tu risques moins de retourner dans le cas d'erreur et ça évite de nester la partie contenant ta logique)

Les prés de la DjangoCon EU sont dispo sur http://klewel.com/conferences/djangocon-2012/

Hello,
 
J'ai une question concernant le RequestContext.
 
Faut le passer au template lors de l'appel de render_to_response() si on veut utiliser {% csrf_token %}, ou si on veut pouvoir utiliser "user" ...
 
Autrement dit, souvent, surtout sur un site qui gère les users authentifiés, et j'ai du mal à comprendre pourquoi ce n'est pas un comportement par défaut.

My guess:
 
http://www.python.org/dev/peps/pep-0020/
 

 
Partant de ce principe, il faudrait aussi balancer manuellement le Context au lieu du RequestContext non ?

Dans la signature de render_to_response les 2e et 3e params sont optionnels, donc non.

 
T'as django.shortcuts.render qui est plus concis que render_to_response dans ce cas.

Bon, chtite question.
 
J'ai un modèle abstrait, nommé File.
 
Il sert de base à d'autres modèles pour gérer différents types de fichier.
 
Tout se passe bien, mais lorsque je supprime une entrée, le fichier associé ne l'est pas.
 
Je pensais donc utiliser les "Signals", notamment le pre_delete.
 
J'ai donc (je zappe les classes qui étendent File) :
 

from django.db.models.signals import pre_delete
 
class File(models.Model):
    title = models.CharField(max_length=100, verbose_name=_("Titre" ))
    description = models.CharField(max_length=250, verbose_name=_("Description" ))
    file = models.FileField(upload_to="uploads", verbose_name=_("Fichier" ))
    publish_at = models.DateTimeField(default=datetime.now, verbose_name=_("Mise en ligne" ))
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
 
    class Meta:
        abstract = True
 
def delete_file(sender, **kwargs):
    sender.file.delete()
 
pre_delete.connect(delete_file)

 
Lorsque je supprime une entrée, j'ai l'erreur suivante :
 

 
Donc je suppose que je ne dois pas m'y prendre correctement...

Ok, trouvé.
 
En fait au lieu de :

def delete_file(sender, **kwargs):
    sender.file.delete()

Il faut utiliser :

def delete_file(sender, **kwargs):
    kwargs['instance'].file.delete()

Par contre je ne sais pas trop ce qu'en penseront les autres, mais à ta place j'aurais plus surchargé la méthode delete de ta classe File que de passé via un Signal.

 
Je pense aussi oui. Je ne suis pas encore assez familiarisé avec Python/Django.
 
Je viens donc de virer tout ce qui est Signal, et j'ai rajouté ça dans ma classe File :
 

def delete(self):
        self.file.delete()
        super(File, self).delete()

 
Ça marche.
 
Je ne sais pas si c'est bien comme ça qu'il faut faire, mais ça me semble fonctionner.
 

Bon en fait ça ne va pas comme je veux.
 
Je viens de lire la doc, et ils précisent :
 

 
Et en effet, si je supprime un élément en OneToMany sur File... ça fait un bulk delete des File en question, et le delete() n'est pas utilisé.
 
Obligé de passer par les signaux finalement.

Alors oui, le soucis que moi j'avais rencontré avec les signaux c'est que dès que t'as un gros QS, c'est assez coûteux en perf (bon ceci étant c'était des signaux plus complexes, qui mettaient notamment à jour des champs dénormalisés). Du coup quand j'avais des script, ou des trucs batchs à faire sur des gros QS, je me retrouvais à désactiver temporairement les signaux pour éviter que ça prenne trois plombes. Du coup l'intéret des signaux par rapport aux __save__(), __delete()__ était limité.
 
Masklinn t'as pas un avis sur la question ?

Original

'tain je suis paumé là :

@require_POST
def create(request):
    print settings.DEFAULT_CHARSET
    print request.body
    print request.POST
    print request.POST['contact']

 
edit: le log de chrome :  

Je vois pas le problème, t'as "éé" dans ton request.POST['contact'], il arrive décodé dans request.POST (d'où le préfixe u quand tu print request.POST), print appelle str. str(unicode) fait unistr.encode(sys.getdefaultencoding()) qui dans python 2 par défaut correspond à unistr.encode('ascii').

"é" ne peut pas être encodé en ASCII, donc UnicodeEncodeError.

(le str() d'une collection Python fait des repr() sur les membres, et le repr(unicode) affiche les caractères non-ascii en hexa escapé au lieu de tenter de les encoder, donc ça ça marche)

j'essaye de comprendre ton post, ça veut dire qu'on peut pas faire un print d'une chaine utf-8 alors que tout l'OS et tout le système est UTF-8 ?

Traduction :

Quand tu fait un print sur le request.POST['contact'], en python 2, ça équivaut à print request.POST['contact'].encode('ascii') (soit request.POST['contact'] une chaine unicode)

Quand tu fais un print sur une collection ça affiche la version escapée des caractères non ascii.

Donc non, tu peux printer avec le mechanisme par défaut.

Tu peux faire un print d'une chaîne utf-8, tu peux pas nécessairement faire un print d'une chaîne unicode dans Python 2 (c'est pas du tout la même chose, une chaîne utf-8 c'est une séquence de bytes, un objet unicode c'est une séquence de codepoints)

Techniquement, pour préciser sur le commentaire précédent, ça dépend de ton sys.stdout.encoding, qui va être utilisé pour encoder un objet unicode quand il est transformé en str pour être balancé dans stdout.

Par défaut, son encodage est (je crois) sys.getdefaultencoding() qui est grosso merdo hardcodé à ASCII. Au démarrage, Python regarde les envvars PYTHONIOENCODING et LC_CTYPE et utilise la première qui ne soit pas vide.

Donc t'as pas tout l'OS et le système en UTF-8, parce que ni LC_CTYPE ni PYTHONIOENCODING ne sont set, et Python fallback sur le seul truc safe qu'il ait: ascii.

la classe totale mecs de PHP devraient passer à python.
 
Bon ça veut dire que c'est ma tentative de débuggage qui a un problème plus que mon système.

PHP n'a effectivement pas le problème, vu que le concept d'unicode est manquant à l'appel/

hum, je m'étais vautré là dessus aussi...c'est vrai qu'une fois qu'on t'explique le catch c'est évident, mais c'est super casse-gueule...
 
sur un mac en 2012, tu t'attends pas à ce que ton programme se mette pas défaut en ASCII

yo, j'ai encore un pb à la con.
 
J'ai une appli qui est optionnelle, certains sites la déploieront et d'autres pas.
Mon idée c'est de simplement l'ajouter ou non aux INSTALLED_APPS du settings.py général.
 
Mais ça pose le problème des URLs de cette appli. Je peux mettre un urls.py dedans, mais comment faire pour qu'il aille se greffer au truc de routage général quand il est activé, sans toucher au urls.py général ? (le truc général a pas à connaître les plugins optionnels)

Sans y réfléchir plus que ça, j'irais sans doute faire un truc dans le urls.py général qui genre listerait toutes les applications présentes et intègrerait automatiquement le urls.py qui se trouve dans chaque appli.
 
Un peu a la manière de l'admin autodiscover, qui cherche tous les fichier admin.py présent dans chaque appli au moment du lancement.

c'est une idée

J'aurais juste fais ça :
 

if 'special_app' in settings.INSTALLED_APPS:
    urlpattern += pattern('',
        url((r'^special_app_root/', include('special_app.urls'))

 
Rapport au fait que même si tu listes automatiquement les urls.py d'applis, tu sauras pas à quelle url racine les rattacher (à moins d'avoir une convention spécifique pour les applis optionnelles, et de ne traiter automatiquement que celles là).
 
Et sinon je me serais posé la question de savoir si c'est vraiment important que l'appli ne soit pas chargée du tout pour les sites non-concernés. C'est peut-être plus sûr de l'activer partout (pour éviter les variations dans la table de routage et les modules/deps chargés).
 
De plus si l'appli est tout le temps activée mais qu'elle a un booléen en base pour savoir si elle bosse ou si elle répond 404, tu peux l'activer/désactiver sans redémarrer le serveur (le contenu du settings.py étant censé être constant).

0x90, je ne suis pas sur que ta solution soit compatible avec son

Pour moi ton "if special_app" dans le urls.py c'est justement une ligne qui montre que ton truc général connait a priori la liste de toutes les modules possibles installables, ce qui me semble pas aller avec sa contrainte.
 
Mais si j'ai mal compris ce que j'ai quoté, la solution de 0x90 est sans doute la meilleure

j'pense que 0x90 est pas d'accord avec ma contrainte tout court en fait.