twitter: comp.lang.python - 25 new messages in 11 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: scope of generators, class variables, resulting in global na
http://groups.google.com/group/comp.lang.python/t/b1ff4d23cb5ec32c?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 24 2010 4:21 am
From: "Alf P. Steinbach"

* Nomen Nescio:
> Hello,
>
> Can someone help me understand what is wrong with this example?
>
> class T:
> A = range(2)
> B = range(4)
> s = sum(i*j for i in A for j in B)
>
> It produces the exception:
>
> <type 'exceptions.NameError'>: global name 'j' is not defined

Which Python implementation are you using?

I can't reproduce the error message that you cite.

<example>
C:\test> py2
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class T:
... A = range(2)
... B = range(4)
... s = sum(i*j for i in A for j in B)
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in T
File "<stdin>", line 4, in <genexpr>
NameError: global name 'B' is not defined
>>> exit()

C:\test> py3
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class T:
... A = range(2)
... B = range(4)
... s = sum(i*j for i in A for j in B)
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in T
File "<stdin>", line 4, in <genexpr>
NameError: global name 'B' is not defined
>>> exit()

C:\test> _
</example>

Reason for the NameError:

The above is a /generator expression/, evaluated in a class definition.

The docs have a similar example but I'm sorry, I'm unable to find it! Anyway the
generator expression is evaluated as if its code was put in function. And from
within the scope of that function you can't access the class scope implicitly,
hence, no access to 'B'.

> The exception above is especially confusing since the following similar example
> (I just replaced the generator by an explicit array) works:
>
> class T:
> A = range(2)
> B = range(4)
> s = sum([(i*j) for i in A for j in B])
>
> (BTW, the class scope declarations are intentional).
>
> Thanks, Leo.

This is a /list comprehension/, not a generator expression (although
syntactically it's almost the same).

It obeys different rules.

Essentially the generator expression produces a generator object that you may
name or pass around as you wish, while the comprehension is just a syntactical
device for writing more concisely some equivalent code that's generated inline.

However, apparently the rules changed between Python 2.x and Python 3.x.

In Python 3.x also the list comprehension fails in a class definition:

C:\test> py3
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class T:
... A = range(2)
... B = range(4)
... s = sum([(i*j) for i in A for j in B])
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in T
File "<stdin>", line 4, in <listcomp>
NameError: global name 'B' is not defined
>>> exit()

C:\test> _
</example>

From one point of view it's good that Py3 provides about the same behavior for
generator expressions and list comprehensions.

But I'd really like the above examples to Just Work. :-)

Cheers & hth.,

- Alf

== 2 of 4 ==
Date: Wed, Feb 24 2010 7:40 am
From: b3ng0

On Feb 24, 5:52 am, Nomen Nescio <nob...@dizum.com> wrote:
> Hello,
>
> Can someone help me understand what is wrong with this example?
>
> class T:
> A = range(2)
> B = range(4)
> s = sum(i*j for i in A for j in B)
>
> It produces the exception:
>
> <type 'exceptions.NameError'>: global name 'j' is not defined
>
> The exception above is especially confusing since the following similar example (I just replaced the generator by an explicit array) works:
>
> class T:
> A = range(2)
> B = range(4)
> s = sum([(i*j) for i in A for j in B])
>
> (BTW, the class scope declarations are intentional).
>
> Thanks, Leo.

The best way to mimic the same behavior, while getting around the
scoping issues, would be as follows:

class T:
A = range(2)
B = range(4)

@property
def s(self):
return sum(i*j for i in self.A for j in self.B)

T().s will now return 6

== 3 of 4 ==
Date: Wed, Feb 24 2010 7:45 am
From: Jon Clements

On Feb 24, 12:21 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Nomen Nescio:
>
> > Hello,
>
> > Can someone help me understand what is wrong with this example?
>
> > class T:
> > A = range(2)
> > B = range(4)
> > s = sum(i*j for i in A for j in B)
>
> > It produces the exception:
>
> > <type 'exceptions.NameError'>: global name 'j' is not defined
>
> Which Python implementation are you using?
>
> I can't reproduce the error message that you cite.
>
> <example>
> C:\test> py2
> Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class T:
> ... A = range(2)
> ... B = range(4)
> ... s = sum(i*j for i in A for j in B)
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 4, in T
> File "<stdin>", line 4, in <genexpr>
> NameError: global name 'B' is not defined
> >>> exit()
>
> C:\test> py3
> Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class T:
> ... A = range(2)
> ... B = range(4)
> ... s = sum(i*j for i in A for j in B)
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 4, in T
> File "<stdin>", line 4, in <genexpr>
> NameError: global name 'B' is not defined
> >>> exit()
>
> C:\test> _
> </example>
>
> Reason for the NameError:
>
> The above is a /generator expression/, evaluated in a class definition.
>
> The docs have a similar example but I'm sorry, I'm unable to find it! Anyway the
> generator expression is evaluated as if its code was put in function. And from
> within the scope of that function you can't access the class scope implicitly,
> hence, no access to 'B'.
>
> > The exception above is especially confusing since the following similar example
> > (I just replaced the generator by an explicit array) works:
>
> > class T:
> > A = range(2)
> > B = range(4)
> > s = sum([(i*j) for i in A for j in B])
>
> > (BTW, the class scope declarations are intentional).
>
> > Thanks, Leo.
>
> This is a /list comprehension/, not a generator expression (although
> syntactically it's almost the same).
>
> It obeys different rules.
>
> Essentially the generator expression produces a generator object that you may
> name or pass around as you wish, while the comprehension is just a syntactical
> device for writing more concisely some equivalent code that's generated inline.
>
> However, apparently the rules changed between Python 2.x and Python 3.x.
>
> In Python 3.x also the list comprehension fails in a class definition:
>
> <example>
> C:\test> py2
> Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class T:
> ... A = range(2)
> ... B = range(4)
> ... s = sum([(i*j) for i in A for j in B])
> ...
> >>> exit()
>
> C:\test> py3
> Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> class T:
> ... A = range(2)
> ... B = range(4)
> ... s = sum([(i*j) for i in A for j in B])
> ...
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "<stdin>", line 4, in T
> File "<stdin>", line 4, in <listcomp>
> NameError: global name 'B' is not defined
> >>> exit()
>
> C:\test> _
> </example>
>
> From one point of view it's good that Py3 provides about the same behavior for
> generator expressions and list comprehensions.
>
> But I'd really like the above examples to Just Work. :-)
>
> Cheers & hth.,
>
> - Alf

s = sum( i*j for i,j in iterools.product(A, B) ) is a possible work
around.

Which could generalise to (something like):

s = sum( reduce(op.mul, seq) for seq in product(A, B, B, A) )

Cheers,

Jon.

== 4 of 4 ==
Date: Wed, Feb 24 2010 8:14 am
From: Arnaud Delobelle

Nomen Nescio wrote:
> Hello,
>
> Can someone help me understand what is wrong with this example?
>
> class T:
> A = range(2)
> B = range(4)
> s = sum(i*j for i in A for j in B)
>
> It produces the exception:
>
> <type 'exceptions.NameError'>: global name 'j' is not defined

It's due to scoping rules for classes and/or how generator expressions
are compiled. When a function definition is executed from within the
body of a class, the body of the class doesn't act as an outer scope
for it. E.g.

class A:
x = 2
def f(self): return x

When f is defined (technically, when the closure is made), the name
'x' is not bound to 2 but is considered to be in the global namespace
(unless the class is defined within a function for example). Now
generator expressions are defined as generator functions so your
example is akin to something like:

class T:
A = range(2)
B = range(4)
def _gen(L):
for i in L:
for j in B:
yield i*j
s = sum(_gen(A))

(From memory, I might be wrong on some details)

Now looking at the above, when _gen is defined, B is considered to be
belonging to the global namespace, therefore if it is not defined
there a NameError will be thrown.

Now a safe workaround to this would be:

class T:
A = range(2)
B = range(4)
s = (lambda A=A, B=B: sum(i*j for i in A for j in B))()

The lambda form is evaluated when the body of the class is executed,
binding the names A and B to the objects you want in the generator
expression.

I remember suggesting a while ago that all generator expressions be
implicitely wrapped like the one above in order to avoid such
surprises. I can't quite remember what the arguments against were,
but you can probably find them in the archives!

--
Arnaud

==============================================================================
TOPIC: Artificial Neural Networks recommendation
http://groups.google.com/group/comp.lang.python/t/902c63263f0c3556?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 4:49 am
From: Gereon Kaiping

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd like to use ANNs in python, especially Simple Recurrent Networks.

Ideally I'd like to find a quick, pythonic module that is able to
simulate different styles of network architectures including some types
of recurrent networks (must: SRN/Elman, may: other recurrent networks
like ESN or LSTM to experiment with them).

So far I found the following Python ANN modules:
- - PyNN (just a builder, requires external simulator) –
http://neuralensemble.org/trac/PyNN/
- - Con-x (part of pyro) – http://pyrorobotics.org/?page=Conx
- - PyNeurGen (includes genetic algorithms) –
http://pyneurgen.sourceforge.net/
- - ffnet (only fast forward) – http://ffnet.sourceforge.net/
- - brian (spiking networks) – http://www.briansimulator.org/
- - PyBrain (machine learning) – http://pybrain.org/

Can you give me a recommendation or a review on some of these? Are there
other modules for simulating ANNs?

Greetings,
Gereon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuFIHIACgkQFWJnZLsO/Wvp1ACfa2dhOd0b0SIVkOzZN0ebRJdd
WFQAoIttIDNbIuqViDbPeVyS+wtGj6tI
=N1oM
-----END PGP SIGNATURE-----

== 2 of 2 ==
Date: Wed, Feb 24 2010 5:11 am
From: Paul Rudin

Gereon Kaiping <gereon.kaiping@yahoo.de> writes:

> Are there other modules for simulating ANNs?

Fann <http://leenissen.dk/fann/> has python bindings.

==============================================================================
TOPIC: Creating variables from dicts
http://groups.google.com/group/comp.lang.python/t/bb1797ffb6fc3bd7?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 24 2010 5:41 am
From: Luis M. González

On Feb 24, 8:48 am, Bruno Desthuilliers <bruno.
42.desthuilli...@websiteburo.invalid> wrote:
> Luis M. Gonz lez a crit :
> (snip)
>
> > Alright, this is what the docs say about locals:
> > "Note
> > The built-in functions globals() and locals() return the current
> > global and local dictionary, respectively, which may be useful to pass
> > around for use as the second and third argument to exec().
>
> > Note
> > The default locals act as described for function locals() below:
> > modifications to the default locals dictionary should not be
> > attempted. Pass an explicit locals dictionary if you need to see
> > effects of the code on locals after function exec() returns."
>
> > I wonder why updating locals(), not from within a function, works (at
> > least in my interactive session).
>
> Because at the top level, locals and globals are the same thing.
>
> > And what about the trick of updating globals? Is it legal?
>
> It's legal, but it's (usually) a very bad idea - at the top-level, it
> harms readability, and from within a function it's doubly bad
> (readibility + "globals are evil").
>
> Now as usual with GoldenRules(tm), it's meant to be broken - once you do
> know why you shouldn't _usually_ do it.
>
> for the very same reasons global
>
>
>
> > If not, is
> > there any "legal" way to do what the OP needs?
>
> > Luis

I still don't understand why is it a bad idea in the case of
globals().
This is the only way I know to define variables programatically in the
top-level namespace, without having to do it manually one by one.
I don't see the readability problem either.
Talking about Goldenrules(tm), what's the recomended way to do it?

Luis

== 2 of 2 ==
Date: Wed, Feb 24 2010 6:44 am
From: Bruno Desthuilliers

Luis M. González a écrit :
> On Feb 24, 8:48 am, Bruno Desthuilliers <bruno.
> 42.desthuilli...@websiteburo.invalid> wrote:
>> Luis M. Gonz lez a crit :

>>
>>> And what about the trick of updating globals? Is it legal?
>> It's legal, but it's (usually) a very bad idea - at the top-level, it
>> harms readability, and from within a function it's doubly bad
>> (readibility + "globals are evil").
>>
>> Now as usual with GoldenRules(tm), it's meant to be broken - once you do
>> know why you shouldn't _usually_ do it.
>>
>>> If not, is
>>> there any "legal" way to do what the OP needs?
>
> I still don't understand why is it a bad idea in the case of
> globals().

please not the _usually_.

> This is the only way I know to define variables programatically in the
> top-level namespace, without having to do it manually one by one.

> I don't see the readability problem either.

# wrong.py

x = 42

def bar():
return x + 1

def test():
y = bar()
assert y==43

# snip 1kloc

def foo():
globals()[x] = 43
quux()

# snip some more core

def quux():
globals()[y] = 1138

# snip some more core

if __name__ == '__main__':
foo()

Enjoy...

> Talking about Goldenrules(tm), what's the recomended way to do it?

The "recommanded way" is
1/ to avoid using globals to share state whenever possible
2/ to avoid creating globals from a function

If your problem is to conditionnaly define globals (based on environment
value or whatnot), then just write the conditional at the top level.

Now I don't say there's no legitimate use case for updating the global
namespace from within a function - just that this is a very very very
rare beast (never meet her as far as I'm concerned, and I did write some
hairy code), and even then is BadEnough(tm) to require a good documentation.

FWIW, your example seemed to be about updating the global namespace from
within a function just to have the names available in the function,
which is about the worst possible solution to the OP problem.

wrt/ the OP question, mapping a sequence of values to a sequence of
names is a legitimate concern, but you just dont need to define these
names in the local namespace to use them - just stick'em in a dict and
you're fine.

==============================================================================
TOPIC: ANN: Leo 4.7 final released
http://groups.google.com/group/comp.lang.python/t/2677f59648821f69?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 5:58 am
From: Edward K Ream

On Tue, 23 Feb 2010 07:53:44 -0600, Edward K Ream
<edreamleo@gmail.com> wrote:

A critical bug has been reported against Leo 4.7 final, and indeed all
previous versions of Leo 4.7.

The bug can cause loss of data in @file nodes when Leo 4.7 saves .leo
files created with older versions of Leo.

This bug will be fixed in Leo 4.7.1, due in a few days. The bug has
already been fixed on Leo's trunk.

My apologies for any problems this bug may have caused.

==============================================================================
TOPIC: When will Python go mainstream like Java?
http://groups.google.com/group/comp.lang.python/t/1675ca5386896fa5?hl=en
==============================================================================

== 1 of 6 ==
Date: Wed, Feb 24 2010 5:59 am
From: Steve Holden

At 12.34 pm on November 13, 2011

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

== 2 of 6 ==
Date: Wed, Feb 24 2010 6:02 am
From: Steve Holden

Stefan Behnel wrote:
> Chris Rebert, 23.02.2010 06:45:
>> Indeed. Python is at position 7, just behind C#, in the TIOBE Index:
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> That index is clearly flawed. A language like PHP (whatever that is
> supposed to be comparable with) can't possibly be on the rise, can it?
>
Interesting that you are willing to trust your gut feeling against an
established survey. All indexes are flawed, they are merely flawed in
different ways is all. I track TIOBE because it shows trends. Python's
absolute position on the list doesn't interest me so much.

== 3 of 6 ==
Date: Wed, Feb 24 2010 6:02 am
From: Steve Holden

== 4 of 6 ==
Date: Wed, Feb 24 2010 8:05 am
From: Peter Parker

Steve Holden wrote:
> At 12.34 pm on November 13, 2011
>

At December 21, 2012 at 11:11 am (according to the Maya calendar)

== 5 of 6 ==
Date: Wed, Feb 24 2010 8:38 am
From: "Martin P. Hellwig"

On 02/24/10 16:05, Peter Parker wrote:
> Steve Holden wrote:
>> At 12.34 pm on November 13, 2011
>>
>
> At December 21, 2012 at 11:11 am (according to the Maya calendar)

On August 29, 1997, Java became mainstream. In a panic, Microsoft tried
to embrace, extend and exterminate the system, prompting Sun to
retaliate with a lawsuit, knowing that Microsoft's counterattack would
eliminate all its main competitors in the U.S. This initiates an
indeterminately long period of new language development culminating in a
battle against corporate monopoly, which gained ever-increasing
capabilities of FUD.

--
mph

== 6 of 6 ==
Date: Wed, Feb 24 2010 9:30 am
From: mk

On 2010-02-24 03:26, George Sakkis wrote:
>> Well I for one wouldn't want Python to go exactly Java way, see this:
>>
>> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=jav...
>>
>> This is the percentage of job offers in UK where the keyword "Java" appears.
>>
>> Same for C#, it looks like C# is eating Java's lunch now:
>>
>> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=csh...
>
> This seems to be a UK-specific trend; in the US (and most other
> countries I know of) Java is still going strong, e.g.
> http://www.indeed.com/jobtrends?q=java%2C+c%23&l=

Interesting, and I was thinking that UK sample was big enough for such
things not to matter.

Regards,
mk

==============================================================================
TOPIC: How to make an empty generator?
http://groups.google.com/group/comp.lang.python/t/7320d6a8eabd2152?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 24 2010 6:07 am
From: Steve Holden

John Posner wrote:
> On 2/19/2010 2:25 PM, Terry Reedy wrote:
>> On 2/19/2010 12:44 PM, Stephen Hansen wrote:
>>
>>> Much to my embarrassment, sometime last night I realized I was being a
>>> complete idiot, and the 'correct' way to handle this in my scenario is
>>> really just:
>>>
>>> def initialize():
>>> # do one time processing here
>>>
>>> return []
>>>
>>> A generator is just a callable that returns an iterator, after all.
>>
>> Confusing generators and generator functions is, well, confusing.
>> For future reference, and clarity of communication in Pythonland,
>>
>> generator function: function that produces a generator when called; if
>> python coded, its body contains 'yield'.
>>
>> generator: iterator produced by a generator function;
>
> I suggest:
>
> iterator produced by a generator function or a generator expression;
>
> has .__next__ and
>> self-returning .__init__, like all other iterators.
>>
>> generator expression: an expression that evaluates to a generator; the
>> expression is used to create a temporary anonymous generator function
>> that is called to produce the generator and is then discarded.
>
> Note that the Py2.6.4 documentation is inconsistent. AFAICT, it conforms
> to Terry's definitions above in most places. But the Glossary says:
>
> generator
> A function which returns an iterator. <... more ...>
>
> generator expression
> An expression that returns a generator. <... more ...>
>
> The additional verbiage in these definitions mitigates the damage, but I
> think the first entry should be headlined *generator function* instead
> of *generator*. And the Glossary should include Terry's additional entry
> [ as amended by me :-) ]:
>
> generator
> An iterator produced by a generator function or a generator
> expression.
>
> -John
>
+1. Can someone submit a documentation patch, please?

== 2 of 3 ==
Date: Wed, Feb 24 2010 6:48 am
From: John Posner

On 2/24/2010 9:07 AM, Steve Holden wrote:
> John Posner wrote:

>> Note that the Py2.6.4 documentation is inconsistent. AFAICT, it conforms
>> to Terry's definitions above in most places. But the Glossary says:
>>
>> generator
>> A function which returns an iterator.<... more ...>
>>
>> generator expression
>> An expression that returns a generator.<... more ...>
>>
>> The additional verbiage in these definitions mitigates the damage, but I
>> think the first entry should be headlined *generator function* instead
>> of *generator*. And the Glossary should include Terry's additional entry
>> [ as amended by me :-) ]:
>>
>> generator
>> An iterator produced by a generator function or a generator
>> expression.
>>
>> -John
>>
> +1. Can someone submit a documentation patch, please?
>

Will do. -John

== 3 of 3 ==
Date: Wed, Feb 24 2010 9:15 am
From: John Posner

>>> generator
>>> An iterator produced by a generator function or a generator
>>> expression.
>>>
>>> -John
>>>
>> +1. Can someone submit a documentation patch, please?
>>
>
> Will do. -John

[sorry if this is a dup]

Done: #8012 "Revise generator-related Glossary entries"

-John

==============================================================================
TOPIC: Spam from gmail (Was: fascism)
http://groups.google.com/group/comp.lang.python/t/6635d24df3ece879?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 7:57 am
From: Robert Kern

On 2010-02-23 22:09 PM, Grant Edwards wrote:
> On 2010-02-24, Robert Kern<robert.kern@gmail.com> wrote:
>
>>> comp.lang.python.spam_prevention_discussion
>>
>> Which doesn't exist and never will. Sorry, but
>> meta-discussions about the group are typically on-topic for
>> all groups with some few exceptions (e.g. non-discussion,
>> binary-only groups with associated .d groups, for instance).
>
> Since now we are discussing meta-discussions, is this now a
> meta-meta-discussion?

If you like, but I tend to interpret "meta-" as idempotent. It's easier on my
aspirin budget.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

==============================================================================
TOPIC: parametrizing a sqlite query
http://groups.google.com/group/comp.lang.python/t/3e6109bdf7336729?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 24 2010 9:07 am
From: Sebastian Bassi

c.execute("SELECT bin FROM bins WHERE qtl LIKE '%:keys%'",{'keys':keywords})

This query returns empty. When it is executed, keywords = 'harvest'.
To check it, I do it on the command line and it works as expected:

sqlite> SELECT bin FROM bins WHERE qtl LIKE '%harvest%';
11C
11D
12F

I guess there is a problem with the "%".

== 2 of 3 ==
Date: Wed, Feb 24 2010 9:21 am
From: Jon Clements

On Feb 24, 5:07 pm, Sebastian Bassi <sba...@clubdelarazon.org> wrote:
> c.execute("SELECT bin FROM bins WHERE qtl LIKE '%:keys%'",{'keys':keywords})
>
> This query returns empty. When it is executed, keywords = 'harvest'.
> To check it, I do it on the command line and it works as expected:
>
> sqlite> SELECT bin FROM bins WHERE qtl LIKE '%harvest%';
> 11C
> 11D
> 12F
>
> I guess there is a problem with the "%".

You might want:
c.execute("SELECT bin FROM bins where qtl like $keys", {'keys':
keywords} )

Cheers,

Jon.

== 3 of 3 ==
Date: Wed, Feb 24 2010 9:29 am
From: Jon Clements

On Feb 24, 5:21 pm, Jon Clements <jon...@googlemail.com> wrote:
> On Feb 24, 5:07 pm, Sebastian Bassi <sba...@clubdelarazon.org> wrote:
>
> > c.execute("SELECT bin FROM bins WHERE qtl LIKE '%:keys%'",{'keys':keywords})
>
> > This query returns empty. When it is executed, keywords = 'harvest'.
> > To check it, I do it on the command line and it works as expected:
>
> > sqlite> SELECT bin FROM bins WHERE qtl LIKE '%harvest%';
> > 11C
> > 11D
> > 12F
>
> > I guess there is a problem with the "%".
>
> You might want:
> c.execute("SELECT bin FROM bins where qtl like $keys", {'keys':
> keywords} )
>
> Cheers,
>
> Jon.

As soon as I posted that, the $ didn't look right; the docs use :keys
syntax.

Cheers,

Jon.

==============================================================================
TOPIC: Is this secure?
http://groups.google.com/group/comp.lang.python/t/ffff2b290db4e811?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 9:23 am
From: mk

On 2010-02-24 03:50, Paul Rubin wrote:
> The stuff about converting 4 random bytes to a decimal string and then
> peeling off 2 digits at a time is pretty awful, and notice that since
> 2**32 is 4294967296, in the cases where you get 10 digits, the first
> 2-digit pair is never higher than 42.

Yikes! I didn't think about that. This is probably where (some part of)
probability skewing comes from.

Anyway, the passwords for authorized users will be copied and pasted
from email into in the application GUI which will remember it for them,
so they will not have to remember and type them in. So I have little in
the way of limitations of password length - even though in *some* cases
somebody might have to (or be ignorant enough) to retype the password
instead of pasting it in.

In that case the "diceware" approach is not necessary, even though I
will certainly remember this approach for a case when users will have to
remember & type the passwords in.

The main application will access the data using HTTP (probably), so the
main point is that an attacker is not able to guess passwords using
brute force.

Using A-z with 10-char password seems to provide 3 orders of magnitude
more combinations than a-z:

>>> 57 ** 10
362033331456891249L
>>> 25 ** 10
95367431640625L

Even though I'm not sure it is worth it, assuming 1000 brute-force
guesses per second (which over the web would amount pretty much to DOS),
this would take # days:

>>> 57 ** 10 / (1000 * 3600 * 24)
4190200595L
>>> 25 ** 10 / (1000 * 3600 * 24)
1103789L

Even then I'm not getting completely uniform distribution for some reason:

d 39411
l 39376
f 39288
a 39275
s 39225
r 39172
p 39159
t 39073
k 39071
u 39064
e 39005
o 39005
n 38995
j 38993
h 38975
q 38958
c 38938
b 38906
g 38894
i 38847
m 38819
v 38712
z 35321
y 35228
w 35189
x 35075

Code:

import operator

def gen_rand_word(n):
with open('/dev/urandom') as f:
return ''.join([chr(ord('a') + ord(x) % 26) for x in f.read(n)])

def count_chars(chardict, word):
for c in word:
try:
chardict[c] += 1
except KeyError:
chardict[c] = 0

if __name__ == "__main__":
chardict = {}
for i in range(100000):
w = gen_rand_word(10)
count_chars(chardict, w)
counts = list(chardict.items())
counts.sort(key = operator.itemgetter(1), reverse = True)
for char, count in counts:
print char, count

> I'd write your code something like this:
>
> nletters = 5
>
> def randomword(n):
> with open('/dev/urandom') as f:
> return ''.join([chr(ord('a')+ord(c)%26) for c in f.read(n)])
>
> print randomword(nletters)

Aw shucks when will I learn to do the stuff in 3 lines well instead of
20, poorly. :-/

Regards,
mk

==============================================================================
TOPIC: How to measure elapsed time under Windows?
http://groups.google.com/group/comp.lang.python/t/340c476d0357a7bd?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 9:32 am
From: "Gabriel Genellina"

En Sat, 13 Feb 2010 17:29:45 -0300, Tim Roberts <timr@probo.com> escribi�:
> "Gabriel Genellina" <gagsl-py2@yahoo.com.ar> wrote:
>>
>> The original problem was with the RDTSC instruction on multicore CPUs;
>> different cores may yield different results because they're not
>> synchronized at all times.
>
> Not true. The synchronization issue has two causes: initial
> synchronization at boot time, and power management making microscopic
> adjustments to the clock rate. In Windows NT 4, Microsoft took extra
> pains
> to adjust the cycle counters on multiprocessor computers during boot so
> that the processors started out very close together. Once set, they
> naturally remained in lock step, until aggressive power management
> because
> more prevalent. In XP, they stopped trying to align at boot time.

Thanks for the detailed explanation!

--
Gabriel Genellina

==============================================================================
TOPIC: Intra-package C extensions with freeze.py
http://groups.google.com/group/comp.lang.python/t/d24467f0e560e269?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 9:47 am
From: mk

On 2010-01-13 20:52, Pascal Chambon wrote:

> I've managed to solve that by manually "monkey patching" sys.modules,
> before fusemodule's actual import. But this looks like an unsatisfying
> solution, to me.

Geez..

> Does anyone have a clue about how to freeze a python program cleanly, in
> case such inner C extensions are involved ? Does any of the freezers
> (freeze.py, py2exe, pyrex, cx_freeze...) do that ? I haven't seen such
> things so far in their docs.

Go for pyinstaller, I have successfully packaged an app using compiled C
extensions this way. Although you will have to add those extensions in
"hook" script.

Regards,
mk

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, February 24, 2010

comp.lang.python - 25 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts