AttributeError: 'itertools.count' object has no attribute 'next'

Arf …

Le code suivant ne fonctionne donc plus en Python 3 :

>>> import itertools, collections
>>> value_to_numeric_map = collections.defaultdict(itertools.count().next)
>>> value_to_numeric_map['a']
0
>>> value_to_numeric_map['b']
1
>>> value_to_numeric_map['c']
2
>>> value_to_numeric_map['a']
0
>>> value_to_numeric_map['b']
1

La première solution venant à l'esprit serait d'avoir à instancier une variable :

>>> c = itertools.count()
>>> value_to_numeric_map = collections.defaultdict(lambda a: next(c))

Et ça fonctionne très bien.

Mais personnellement, je préfère lorsque ça reste one-line, donc voici une alternative one-line :

J'utilise lambda pour créer une encapsulation (closure).

value_to_numeric_map = collections.defaultdict((lambda c: (lambda: next(c)))(itertools.count()))

Lien précédent : http://www.olissea.com/mb/links/1/?ibR8_g

EDIT: J'ai trouvé ce problème ceci dit: https://bugs.php.net/bug.php?id=65045
Mais j'ignore si je suis vraiment concerné : ça dépend en effet si mon script capture ces séquences à problèmes mais il me semble qu'il ne capture que les séquences valides de 4 bytes, donc pas de problème normalement.

Également, j'ai pas trop compris comment ça se fait, mais lorsque j'applique htmlspecialchars sur les séquences données sur la page, l'output n'est pas vide. Ne devrait-il pas l'être (vu que htmlspecialchars renvoie stupidement une chaîne vide lorsqu'il reçoit de l'UTF-8 invalide normalement ?).

Mmmmmh.
</EDIT>

"Plop.

Après mainte péripéties et échecs, je pense avoir trouver quelque chose de "potable".

Voir le code avec coloration syntaxique (un peu différent, manque une source) : http://sebsauvage.net/paste/?e249576d75ee9946#jBpv2UCufTQ4UC2WnTtM11gfolfGkQi61brf11pFORU=

<?php

# "😒" est codé sur 4 bytes
$body = 'lol😒a☺';

echo 'before: ',$body,'<br />'; # Output: lol😒a☺
echo 'length: ',strlen($body),'<br />'; # Output: 11 (😒 = 4, ☺ = 3)

# Le but est de remplacer uniquement les caractères de plus de 3 bytes par leur entité HTML.
# Afin d'obtenir ce code dans le cas de notre exemple
echo '😒','<br />'; # Fourni par https://duckduckgo.com/?q=html+%F0%9F%98%92

# Récupération des caractères de plus de 3 bytes uniquement
# Source: http://stackoverflow.com/a/1401716/1524913
# $body = preg_replace('/[\xF0-\xF7][\x80-\xBF]{3}/', '�', $body); # Yeah! It works!

# Ne fonctionne pas. htmlentities ne connaît pas tous les caractères unicode ( http://stackoverflow.com/a/13942507/1524913 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return htmlentities($m[0], ENT_COMPAT, 'UTF-8');}, $body); # Ignore complètement 😒

# La solution proposée au lien précédemment cité : Ne fonctionne pas non plus
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return str_replace('\\u','&#x',trim(json_encode($m[0]),'"')).';';}, $body);
# Output: lol��a☺ car json_encode considère ça comme deux caractères de deux bytes et renvoie "\ud83d\ude12"

# Ne fonctionne pas ( http://php.net/manual/en/function.htmlentities.php#107985 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_encode_numericentity($m[0], array(0x0, 0xffff, 0, 0xffff), 'UTF-8');}, $body); # Ignore complètement 😒

# Fonctionne !!! Mais renvoie &#128530 au lieu de 😒 (Pas vraiment un problème en soit)
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8');}, $body);

# Si on veut vraiment la version hexadécimal
$body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return '&#x'.dechex(substr(mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8'), 2)).';';}, $body);

echo 'after: ',$body,'<br />'; # Output: lol😒a☺

?> "

Bronco: "Une petite idée d'amélioration possible pour pickypaste: serait-il possible d'étendre la durée de validité du message pour le user ? (ou de cocher une case "permettre au destinataire de prolonger la durée de validité")
ça permettrait de ne pas perdre direct le message si on n'a pas le temps d'y répondre dès la lecture ^^"

J'aime beaucoup l'idée (si je l'ai bien comprise), mais je ne vois pas trop (pas encore ?) comment on pourrait implémenter ça par contre…
(Le fait que PickyPaste utilise un zerobin externe au lieu d'être un fork de zerobin limite quelques possibilités ou rend les choses plus complexes...)

J'essaie de trouver quelle serait la meilleure utilisation de htmlspecialchars si on ne possède pas encore PHP 5.4 (contraintes techniques).

D'une part, par défaut, si vous passez une chaîne contenant de l'UTF-8 invalide, htmlspecialchars vous retournera une chaîne complètement vide. ("Pratique")
Pour remédier à ça, il vous faut utiliser ENT_IGNORE ou ENT_SUBSTITUTE. ........ MAIS la doc déconseille l'utilisation de ENT_IGNORE pour des raisons de sécurité. ( http://unicode.org/reports/tr36/#Deletion_of_Noncharacters )
(Source: http://stackoverflow.com/q/11088953/1524913 )

Seulement voilà, ENT_SUBSTITUE est uniquement disponible à partir de PHP 5.4.0. (Donc je fais quoi… ?)

Notez égaaaaaaalement qu'il est impossible de spécifier les paramètres par défaut de htmlspecialchars et qu'il vaudrait mieux donc que vous créez votre propre wrapper.

Puis j'ai également trouvé cette perle … jugez par vous-même. ._."

"Error handling in htmlspecialchars before PHP 5.4 was … uhm, let’s call it “unintuitive”:

If you passed a string containing an “invalid code unit sequence” (which is Unicode slang for “not encoded correctly”) htmlspecialchars would return an empty string. Well, okay, so far so good. The funny thing was that it additionally would throw an error, but only if error display was disabled. So it would only error if errors are hidden. Nice, innit?"
(Source: http://nikic.github.io/2012/01/28/htmlspecialchars-improvements-in-PHP-5-4.html)

Cette page-ci n'est pas mal non plus: http://stackoverflow.com/q/13745353/1524913

Un petit Minecraft codé en 500 lignes Python.

Depuis le projet a grossit et contient + de 8000 lignes.

Je trouve que les opérations SQL s’effectuant sur l’ensemble d’une table et qui affecte celle-ci, on devrait être obligé de l’indiquer explicitement et non implicitement comme c’est le cas pour le moment …

Je parle de faire une DELETE ou un UPDATE sans spécifier de clause WHERE (et donc affecter toute la table) par inadvertance.

En effet, l’erreur/l’oubli étant humain, il est beaucoup plus simple de commencer à écrire sa requête puis oublier de spécifier la clause WHERE.
Alors que si on était obligé de spécifier, par exemple, un simple ALL, l'erreur se produirait bien moins souvent et l'oubli ne ferait rien de critique.

C'est peu contraignant et ça sauverait des vies.

Je trouve que c'est vraiment un cas de bad design. Ça serait facile à implémenter en plus.

C'est sérieux en plus ._.'

via eijebong

Flask ne semble pas supporter la possibilité de retourner des générateurs comme WSGI peut le faire et je ne suis pas sûr qu'ils prévoient que ça soit le cas un jour … ( voir  https://github.com/mitsuhiko/flask/pull/684 )

Mais bon perso je trouve ça super sympa de pouvoir yield du contenu lorsqu'on veut dans son code. Un peu comme je pouvais le faire avec cgi ou en PHPouet.
De plus je suis entrain de migrer d'un code pur WSGI à Flask (sous les conseils de Link Mauve si je ne me méprend pas) - pour l'instant j'en suis toujours à l'étape "c'est relou". Pourvu que ça ne dure pas -, du coup c'est plus sympa pour moi de pouvoir conserver cette façon là.

(Note: J'avais également pas envie de devoir spécifier un décorateur @generator pour toutes mes fonctions contenant un yield, j'ai donc décidé de décorer app.route directement (mais ce fut un peu plus compliqué à mettre en place))

from functools import wraps

from flask import Flask, Response, stream_with_context

app = Flask(__name__)

# Decorator to make Flask accept generators

@wraps(app.route)
def route_accept_generators(*args, **kwargs):
route = route_accept_generators.app_route(*args, **kwargs)  # Getting our route decorator.

# Decorating it.
@wraps(route)
def decorated(f):

# Make so that the function that will be called return a valid Flask answer in case of returning a generator.
@wraps(f)
def function_accept_generators(*args, **kwargs):
r = f(*args, **kwargs)

if isinstance(r, types.GeneratorType):
# return Response(r, direct_passthrough=True)  # Solution proposed here: http://flask.pocoo.org/mailinglist/archive/2010/11/3/using-yield/#478b0c1829b5263700da1db7d2d22c79
return Response(stream_with_context(r))  # Solution found here: http://stackoverflow.com/q/13386681/1524913

return r

return route(function_accept_generators)

return decorated

# Store the function so that it doesn't make an infinite recursion call
# Because accessing from app.route rather than directly)
# And storing it in itself instead of creating another standalone variable
route_accept_generators.app_route = app.route

app.route = route_accept_generators

x))))

Infos intéressantes pour l'utilisation d'sqlite3 avec Python.

Je garde ça sous la main.

EDIT:

" > - Are there any peculiarities with using curs.executemany(...) vs. multiple
> curs.execute(...) ? I read a notice, sqlite3 does internally some caching,
> hence both should be similarly fast, but in my case executemany(...) is
> quite a bit faster

How many times are you calling execute vs a single executemany? The
python call overhead will add up for thousands of calls.

The relevant source code is here if you're interested:

http://svn.python.org/projects/python/trunk/Modules/_sqlite/cursor.c

>  Further, I am not quite sure about the standard usage of the cursor object
> and also the proper commiting the transactions and closing the connection.

Standard usage is here:

http://docs.python.org/lib/module-sqlite3.html

If the database supports transactions then cursors automatically use
transactions. Your changes only get committed when you call .commit().
Otherwise your changes are lost.

In the specific case of sqllite, some statements (like CREATE TABLE,
ALTER TABLE, etc) also cause a commit. This is probably where your
confusion comes from. Since this isn't part of the python DB API spec
(http://www.python.org/dev/peps/pep-0249/) I wouldn't rely on it.
Otherwise you will have problems with other databases.

Also, in your specific case you're using an 'in memory' sqllite db. So
there are less concerns with losing data between db sessions, etc. But
with most databases (on disk, running across the network on a server)
this becomes important.

>  Should one create a cursor of a connection and call the execute ... methods
> of the cursor -
>  or is it better to call the shortcut execute etc. methods of the Connection
> object directly (as suggested in the docs:
> http://docs.python.org/lib/node351.html (or are there specific use cases for
> both approaches)?

I suggest that you use the standard cursor methods instead, so you can
run your code against non-sqllite databases.  The performance etc
should be the same as using the direct method. Like the page says,
it's main benefit is consiseness.

>
> When the transactions should be commited? (creating, altering a table, or
> also selecting the results ?)
>  There seem to be some implicit handling of the transactions (
> http://docs.python.org/lib/sqlite3-Controlling-Transactions.html#sqlite3-Controlling-Transactions
> ); hence I am not sure about the standard usage of these methods; the same
> is true of connection.close() - or are these calls eventually unnecessary?

As a general rule, always use .commit() and .close(). Otherwise:

- No .commit() - you will lose db changes since the last commit or
"non-DML, non-query statement" (in the case of sqllite)
- No .close() - Your database connection will only close when your db
objects are garbage collected.

> conn_tags_DB = sqlite3.connect(':memory:')
>  curs = self.conn_tags_DB.cursor()
>  curs.execute('CREATE TABLE IF NOT EXISTS "%s" ("%s", UNIQUE("%s"))' %
> (self.text_name, index_col_name, index_col_name))
>  curs.execute(u'INSERT OR REPLACE INTO "%s"("%s") VALUES (?)' %
> (self.text_name, index_col_name), (0,))
>  for new_col in act_db_columns[1:]: # adds the needed columns (except of the
> first one: index_col_name)
>      curs.execute('ALTER TABLE "%s" ADD "%s" TEXT' % (self.text_name,
> new_col))
>  curs.executemany('INSERT OR REPLACE INTO "%s" VALUES (%s)' %
> (self.text_name, question_marks), tags_seq)
>  self.conn_tags_DB.commit()
>
> Are there maybe any comments or hints on a more elegant/efficient solution?
>

I think that dynamically creating schema (tables, based on text file
structure is a bad idea. A few reasons:

- This forces you to dynamically generate all your queries dynamically
- Not all strings are valid table/column names
- This forces the app to run as database administrator (maybe not
important for sqllite, but definitely an issue if you change to
another dbm).
- Potentially huge stability/security problems - text files can
potentially break system tables, overwrite users, etc, etc.

You're violating several rules on db design/usage.

I strongly recommend that you use a better database logic. ie, create
tables and records in advance (setup script, as db admin user if
applicable), then only use delete/insert/update/select statements (as
restricted user, if applicable).

If this is too much trouble, then I suggest storing your database in
regular Python structures instead, and use pickle/yaml/etc to write to
disk. Your current version uses a 'in memory' database, so the end
result is the same. You'll get a large performance boost also.

> Now, what's the usual way to access the database? Is it
> possible/wise/standard ... to leave the connection open for the subsequent
> queries during the whole run of the app; could even the cursor eventually be
> present as a class method, or should it rather be created repeatedly with
> each call?  (After populating, the db shouldn't be modified, but only read.)

It depends. If your app is simple, single threaded, then a single
connection (global or passed through args) should be fine. Only use
multiple cursors if you need them (multiple threads, multiple
databases, multiple transaction/db isolation levels, etc).

David.
"