Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Steven D'Aprano:

On Sat, 19 Dec 2009 04:29:22 +0100, Alf P. Steinbach wrote:


* Steven D'Aprano:

On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:


That said, and a bit off-tangent to your comment's main thrust, the
time spent on coding that repeated-division-by-2 optimization would, I
think, be better spent googling "Collatz Conjecture"  --  avoiding
writing /any/ code. ;-)

That's a strange thing to say.

No. The code shown was like attacking Fermat's last theorem with a
little Python script checking out number triplets. It's already been
done (not to mention that that theorem's been proven, although that's,
AFAIK, not the case for Collatz').


You're assuming that Mensanator's motive for writing code is to challenge 
the Collatz Conjecture, rather than to just have fun doing maths and 
programming, or to build up his skills for a serious effort at extending 
the domain of values for which it is known to be true. Or just because he 
needs a function that calculates the hailstone numbers.


I would rather not speculate about motives.

I can say things about the code that was presented, and I did, but as for the 
motives that went into creating it or presenting it in this thread, well I'm not 
telepathic.




Now, it's a different story if you're using the gmpy module. You
DON'T want to use literals in loops involving gmpy, because they
would have to be coerced to .mpz's on every pass through the loop.

[...]

Yeah, good point. Few languages have compile time evaluation of
logically constant expressions.

Surely that's an implementation issue rather than a language issue.

No, it isn't.

An optimizer can only do so much, as you yourself note below!


You make no sense here. What I note below is the existence of an 
implementation-specific optimizer. And your conclusion? That such 
optimization is language specific! How does that make sense?


No, I meant exactly what I wrote, that an optimizer only can do so much, which 
you also noted yourself; that language support facilitates this optimization; 
and that few languages have that support (but e.g. C++0x will have it).



[snip]


With language support it's a very different matter because guarantees
propagate so that sophisticated analysis is no longer necessary: the
compiler /knows/, because it's explicitly being told.


Of course if a language makes a certain guarantee (for example, that 
calls to math.exp(0) will be replaced at compile-time with 1.0) then the 
compiler can make that substitution.


Yes, that's what C++0x 'constexpr' is about.

But I've lost the context here, not sure what this is all about.


[snip]


(1) It's not meaningless to talk about renaming names.


Well, as good as meaningless, IMHO. In fact, earlier, when you wrote under the 
assumption that I was talking about such renaming, you seemed to maintain that 
it was pretty meaningless. I conclude from that that also this is relative.



(2) I will not try to guess what you mean on the basis of what I consider 
sensible, rather than respond to what you actually say.


I rather hoped you would try to employ the "sensible" heuristic.

The problem so far has, apparently, been that you refuse to accept the language 
specification's definition, in §4.1, of variable as name and vice versa.


An "is-it-sensible" heuristic could have cleared that up, I think.


(3) I've already gone over the name/value thing to death in another post, 
so I'll do everyone a favour and not continue it here.


But when that is the problem, a basic misunderstanding of what a word means, 
then it's worth uh, harping on the issue, I think:




[...]

The terms
"constant" and "variable" refer to the values bound to a name, not the
name itself:

I'm sorry, that's incorrect.

Quote from §4.1 "Naming and binding" of the Python 3.1.1 language spec:

"If a name is bound in a block, it is a local variable of that block,
unless declared as nonlocal. If a name is bound at the module level, it
is a global variable. (The variables of the module code block are local
and global.) If a variable is used in a code block but not defined
there, it is a free variable."


Since the above quote doesn't mention "constant", how on earth can you 
use it as evidence for what "constant" refers to?


I don't. I use it as evidence for what "name" refers to. A constant "name" is 
then, logically, a constant such thing, to wit, a constant variable. You may 
find that terminology paradoxical. For C++, which has the means of enforcing it, 
it's a FAQ (many novices have some trouble accepting constant /variables/...). 
If it helps let's adopt Java's terminology and talk about "final" variables. Or, 
as Bjarne had it in original C++, "readonly" variables.



In any case, the words "constant" and "variable" have multiple meanings. 
They can be either nouns or adjectives. Constants (nouns) are called 
constants because of the value is constant (adjective) -- and similar for 
variables.


Yeah, but you're not seriously suggesting th

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Steven D'Aprano:

On Sat, 19 Dec 2009 04:04:51 +0100, Alf P. Steinbach wrote:


* Steven D'Aprano:

On Fri, 18 Dec 2009 19:00:48 +0100, Alf P. Steinbach wrote:


In fact almost no Python
code does, but then it seems that people are not aware of how many of
their names are constants and think that they're uppercasing constants
when in fact they're not. E.g. routine arguments

Routine arguments are almost never constants, since by definition they
will vary according to the value passed by the caller.

I'm sorry, but that requires a definition of "constant" that explicitly
excludes routine arguments, 


/s/explicitly/implicitly



which is like saying horses are not mammals, just "because".


No, it's like saying that horses are not apes, because the definition of 
apes excludes horses.


On the contrary. Apes are not superclass of horses.


But in any case, rather than continue my argument (which was absolutely 
brilliant and flawless, I might add... *wink*), I'm going to skip ahead 
to the place where the penny drops and I understand what you were trying, 
but failed, to say.




Consider some C++ code:

   void foo( SomeType const v )
   {
   // Here the name v is constant: that name's value can't change.
   // (Except that in C++ you can do anything by using low-level
   stuff.)
   }


*penny drops*

Ahaha!!! Now I get it! You want to make the *parameter* of the function a 
constant, rather than the *argument* passed to the function. In other 
words, you want to prohibit something like this:


def f(x):
y = x + 1  # do something with the value passed by the caller
x = 0  # changing the binding will fail INSIDE the function

while still allowing the caller to call the function with variables.


I would want the possibility of having that enforced, of course, because the 
more you know about what can't take place in the code, i.e. the more easy-to-see 
constraints there are, the easier it is to understand and reason about the code, 
not to mention modifying it without breaking original assumptions.


But I wasn't talking about such a language feature (which I believe could also 
greatly improve Python's efficiency by removing the need for many lookups).


Rather, I was remarking that in the absence of such a language feature, to be 
consistent those who insist on using naming conventions to indicate design level 
constraints should use those naming conventions also for this case and others. 
For there's little point in making some occurrences of a constraint visually 
explicit and others not. That just means that one cannot rely on the convention 
to tell where the constraint is (meant to be) in effect or not.



Right -- now what you say makes sense, and is a perfectly reasonable 
thing to do in languages that support constants.


You weren't clear about what you wanted, and the only thing I could think 
of which matched your description was something completely bizarre: given 
some function f with one parameter, you wanted to declare that parameter 
as a constant with some value (say 42), so that calling the function with 
an argument of any other value would be an error, e.g.:


x = 42
f(x)  # succeeds
x = 43
f(x)  # fails

E.g. implemented something like this:

def f(x):
if x != 42:
raise ConstantError('x is not the constant 42')
...

except that the test is done automatically by the compiler.



To be pedantic, original routine names are usually absolutely not meant
to be assigned to.

If you have

   def foo(): whatever()

you simply shouldn't, in general, do

   foo = bar

I think you understood that, i.e., that the above comment of yours is
just rhetoric?


First of all, I think you're underestimating the usefulness and frequency 
of rebinding names to functions. I'll accept that it's uncommon, but it's 
not *that* uncommon to justify "absolutely not meant to be assigned to".


Yeah, hence the weasel term "in general".


In fact, it's so common that we have special syntax for one special case 
of it. Instead of:


def f():
...

f = g(f)

we can write:

@g
def f():
...

While decorator syntax can only be used at function-definition time, the 
concept of function decoration is far more general. You can decorate any 
function, at any time, and doing so is very, very useful for (e.g.) 
debugging, logging, monkey-patching, introspection, error-checking, and 
others. And decoration itself is only one special case of function 
rebinding.


But usually this wrapping occurs before the function is first used by other 
code, i.e. it's usually part of initialization  --  isn't it?


For debugging purposes you might want to replace a function on-the-fly, in the 
middle of the program execution.


But debugging does all sorts of things not commonly accepted for normal 
execution.


As for your second point, my earlier comment is mostly aimed at what I 
see as your misleading habit of referring to *names* as being constants, 
rather than the value assigned to the 

Re: iterators and views of lists

[Lie Ryan]

On 12/17/2009 4:44 AM, Francesco Bochicchio wrote:

On Dec 16, 1:58 pm, Anh Hai Trinh  wrote:



You might be interested in this library.

You can easily create arbitrary "slice", for example

   i = mylist>>  takei(primes())

will return an iterator over the items of mylist with a prime number
index, given that primes() return an iterator over prime numbers.




Nice :-)

I was starting to experiment data flow programming with python myself,
although I'm just playing with it..
I find the idea of data flow programming fascinatin, and wonder if it
can be considered a general-purpose program paradigm.


It is actually. http://en.wikipedia.org/wiki/Pipeline_programming
http://en.wikipedia.org/wiki/Flow-based_programming
--
http://mail.python.org/mailman/listinfo/python-list

Re: Object Relational Mappers are evil (a meditation)

[Lie Ryan]

On 12/17/2009 3:17 PM, J Kenneth King wrote:

A language is a thing.  It may have syntax and semantics that bias it
towards the conventions and philosophies of its designers.  But in the
end, a language by itself would have a hard time convincing a human
being to adopt bad practises.


Perhaps someone should make a research whether if you teach a language 
to kids, where one group is taught the language filtered from "bad 
words" and another group is taught all the languages' "bad words" on 
purpose. Will one group have more behavioral problems compared to the other?

--
http://mail.python.org/mailman/listinfo/python-list

Anybody use web2py?

[AppRe Godeck]

Just curious if anybody prefers web2py over django, and visa versa. I 
know it's been discussed on a flame war level a lot. I am looking for a 
more intellectual reasoning behind using one or the other.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Sat, 19 Dec 2009 04:29:22 +0100, Alf P. Steinbach wrote:

> * Steven D'Aprano:
>> On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:
>> 
>>> That said, and a bit off-tangent to your comment's main thrust, the
>>> time spent on coding that repeated-division-by-2 optimization would, I
>>> think, be better spent googling "Collatz Conjecture"  --  avoiding
>>> writing /any/ code. ;-)
>> 
>> That's a strange thing to say.
> 
> No. The code shown was like attacking Fermat's last theorem with a
> little Python script checking out number triplets. It's already been
> done (not to mention that that theorem's been proven, although that's,
> AFAIK, not the case for Collatz').

You're assuming that Mensanator's motive for writing code is to challenge 
the Collatz Conjecture, rather than to just have fun doing maths and 
programming, or to build up his skills for a serious effort at extending 
the domain of values for which it is known to be true. Or just because he 
needs a function that calculates the hailstone numbers.



 Now, it's a different story if you're using the gmpy module. You
 DON'T want to use literals in loops involving gmpy, because they
 would have to be coerced to .mpz's on every pass through the loop.
>> [...]
>>> Yeah, good point. Few languages have compile time evaluation of
>>> logically constant expressions.
>> 
>> Surely that's an implementation issue rather than a language issue.
> 
> No, it isn't.
> 
> An optimizer can only do so much, as you yourself note below!

You make no sense here. What I note below is the existence of an 
implementation-specific optimizer. And your conclusion? That such 
optimization is language specific! How does that make sense?

Obviously it wouldn't be sensible for CPython to optimize numeric 
literals as mpz objects, because that would be a lot of overhead for very 
little gain. But it might make sense for somebody to create a "Numeric 
Python" implementation which used mpz as the standard integer type.

A slightly more tricky case is optimizing away more complex runtime 
expressions. len("abc") is not necessarily the constant 3, because the 
function len may have been replaced by something else, thus requiring it 
to be calculated at runtime rather than compile-time. But an 
implementation might relax that condition and treat built-ins as 
constants. Guido probably will never allow such a thing in CPython, but 
other implementations are free to do things differently. Even if people 
argue that such a behavioural change is "no longer Python", there's 
nothing preventing an optimizing implementation from replacing 
"abc".__len__() with the constant 3 except the complexity of 
implementation and the diminishing returns of doing so.


> With language support it's a very different matter because guarantees
> propagate so that sophisticated analysis is no longer necessary: the
> compiler /knows/, because it's explicitly being told.

Of course if a language makes a certain guarantee (for example, that 
calls to math.exp(0) will be replaced at compile-time with 1.0) then the 
compiler can make that substitution. But such optimizations tend not to 
be specified by the language (in fact languages like C often tend to 
leave large amounts of behaviour as implementation-defined), and even 
when languages do make certain guarantees, implementations are free to 
implement any behaviour not implicitly or explicitly forbidden. 



 Mine does when I use gmpy. Otherwise, the notion that "most names are
 constants" is generally false.
>>> No, it depends on what you mean by "constant".
>> 
>> All names are constant. Always. The Python language does not support
>> renaming names -- as far as I know, no language does.
> 
> No-ones been talking about renaming names. I think that's purely
> rhetorical on your part but it may be that you really believe so. In the
> latter case, just try to interpret statements so that they're meaningful
> instead of meaningless. :-)

(1) It's not meaningless to talk about renaming names.

(2) I will not try to guess what you mean on the basis of what I consider 
sensible, rather than respond to what you actually say.

(3) I've already gone over the name/value thing to death in another post, 
so I'll do everyone a favour and not continue it here.



[...]
>> The terms
>> "constant" and "variable" refer to the values bound to a name, not the
>> name itself:
> 
> I'm sorry, that's incorrect.
> 
> Quote from §4.1 "Naming and binding" of the Python 3.1.1 language spec:
> 
> "If a name is bound in a block, it is a local variable of that block,
> unless declared as nonlocal. If a name is bound at the module level, it
> is a global variable. (The variables of the module code block are local
> and global.) If a variable is used in a code block but not defined
> there, it is a free variable."

Since the above quote doesn't mention "constant", how on earth can you 
use it as evidence for what "constant" refers to?

In any case, the w

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - RequestFor Comments

[Lie Ryan]

On 12/19/2009 12:56 PM, Steven D'Aprano wrote:

As far as I know, no programming language provides a standard facility
for renaming entities, be they data or routines:


The C-preprocessor does to C/C++, in a limited fashion.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Mensanator]

On Dec 19, 12:21 am, "Alf P. Steinbach"  wrote:
> * Mensanator:
>
>
>
> >> That said, and a bit off-tangent to your comment's main thrust, the time 
> >> spent
> >> on coding that repeated-division-by-2 optimization would, I think, be 
> >> better
> >> spent googling "Collatz Conjecture"  --  avoiding writing /any/ code. ;-)
>
> > Ha! I know more about Collatz than you can ever find by Googling!
> > And how did I achieve that? By writing such code. Be a good boy and
> > maybe I'll show you how to do Ulam's Spiral with Turtle Graphics.
>
> It's probably good for you that you know so much about Collatz.
>
> I fail to see the relevance to anything.

No kidding. Here let me explain it:

You said my time would be better spent googling "Collatz Conjecture".

I said I know more than can be found by googling. Therefore,
it follows that my time could NOT be better spent googling.

Thus, your staement is shown to be false.

QED

>
> Cheers & hth.,
>
> - Alf

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[Lie Ryan]

On 12/19/2009 9:34 AM, mattia wrote:

Can you provide me a much pythonic solution (with comments if possible,
so I can actually learn something)?


If you only need to get i'th element sometimes, sorting the dict is 
fine. Otherwise, you might want to use collections.OrderedDict.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Mensanator:


That said, and a bit off-tangent to your comment's main thrust, the time spent
on coding that repeated-division-by-2 optimization would, I think, be better
spent googling "Collatz Conjecture"  --  avoiding writing /any/ code. ;-)


Ha! I know more about Collatz than you can ever find by Googling!
And how did I achieve that? By writing such code. Be a good boy and
maybe I'll show you how to do Ulam's Spiral with Turtle Graphics.


It's probably good for you that you know so much about Collatz.

I fail to see the relevance to anything.


Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Mensanator]

On Dec 18, 6:25 pm, "Alf P. Steinbach"  wrote:
> * Mensanator:
>
> >> The second deviation is that since most names are constants,
>
> > Really? Does that mean you don't use literals, to save the time
> > required to convert them to integers? Isn't that done at compile
> > time?
>
> > So, instead of doing the Collatz Conjecture as
>
> > while a>1:
> >   f = gmpy.scan1(a,0)
> >   if f>0:
> >     a = a >> f
> >   else:
> >     a = a*3 + 1
>
> > You would do this?
>
> > zed = 0
> > one = 1
> > two = 2
> > twe = 3
> > while a>one:
> >   f = gmpy.scan1(a,zed)
> >   if f>zed:
> >     a = a >> f
> >   else:
> >     a = a*twe + one
>
> That seems to have no relation to what you quoted / responded to.

Whose fault is that? Here's a hint: when people's replies don't
make any sense, it's because they don't understand your prattle.
That's not good for someone who fancies himself a teacher of
programming.


>
> On the other hand, if there is some specific rôle played by the 3 above, where
> some other value (like e.g. 5) might be used instead, then a self descriptive
> name for that rôle might be good.
>
> Such reasonable naming (not what you did above) then allows easier 
> modification
> of and makes it easier to understand the code.
>
> That said, and a bit off-tangent to your comment's main thrust, the time spent
> on coding that repeated-division-by-2 optimization would, I think, be better
> spent googling "Collatz Conjecture"  --  avoiding writing /any/ code. ;-)

Ha! I know more about Collatz than you can ever find by Googling!
And how did I achieve that? By writing such code. Be a good boy and
maybe I'll show you how to do Ulam's Spiral with Turtle Graphics.

>
> > Does this really save any time?
>
> If by "it" you mean the silly naming, no it doesn't.
>
> On the contrary, it wastes time, both for writing the code and reading it.
>
> Generally, IMO, think about the clarity of your code. If naming something
> increases clarity, then name the thing. If it doesn't increase clarity, don't.
>
>
>
>
>
> > Now, it's a different story if you're using the gmpy module.
> > You DON'T want to use literals in loops involving gmpy, because
> > they would have to be coerced to .mpz's on every pass through the
> > loop.
>
> > In that case, you DO want to use constants as opposed to literals:
>
> > ZED = gmpy.mpz(0)
> > ONE = gmpy.mpz(1)
> > TWO = gmpy.mpz(2)
> > TWE = gmpy.mpz(3)
> > while a>ONE:
> >   f = gmpy.scan1(a,0) # int used here, so it can be a literal
> >   if f>ZED:
> >     a = a >> f
> >   else:
> >     a = a*TWE + ONE
>
> > And yes, the time savings can be tremendous, especially when 'a'
> > has over 50,000 decimal digits.
>
> Yeah, good point. Few languages have compile time evaluation of logically
> constant expressions. C++0x will have that feature (called 'constexpr' IIRC) 
> but
> in Python, current C++ etc. it's just a good idea to precompute values, and 
> name
> them, rather than computing them again and again where they're needed.
>
> > . I do not follow PEP
> >> 8's recommendation to use uppercase names of constants. In fact almost no 
> >> Python
> >> code does,
>
> > Mine does when I use gmpy. Otherwise, the notion that "most names
> > are constants" is generally false.
>
> No, it depends on what you mean by "constant".

Why don't you try using what PEP 8 means by "constant".

> The problem with Python, as
> Google noted, is that the language is so excessively dynamic: even names of
> routines are variables, and there /are/ no named user defined constants except
> logically, in the programmer's mind. And logically (that is, at the "in the
> programmer's mind" level), if you define "constant" as a name whose value will
> not change after initialization, then routine names are constants.

You're sitting too close to the fire. Why don't you back off and
quit overanalizing things.

>
> However, if you define "constant" as only a global scope (that is, module 
> scope)
> name that denotes a boolean, numerical or string or Null value and that 
> doesn't
> change after initialization, then your statement about the scarcity of 
> constants
> appears to be true, but using a practically useless definition.
>
> I think for such constants exported by modules it's a good idea to at least
> provide uppercase names so as conform to very firmly established convention.
> There might even be tools that rely on that convention. But for application 
> code
> the uppercase names are just distracting, and they don't help you...

They help when I look at something like

a = (i-ONE)*NIN**(k-ONE) + (NIN**(k-ONE) - ONE)//TWO + ONE

>
> Cheers & hth.,
>
> - Alf

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Sat, 19 Dec 2009 04:04:51 +0100, Alf P. Steinbach wrote:

> * Steven D'Aprano:
>> On Fri, 18 Dec 2009 19:00:48 +0100, Alf P. Steinbach wrote:
>> 
>>> In fact almost no Python
>>> code does, but then it seems that people are not aware of how many of
>>> their names are constants and think that they're uppercasing constants
>>> when in fact they're not. E.g. routine arguments
>> 
>> Routine arguments are almost never constants, since by definition they
>> will vary according to the value passed by the caller.
> 
> I'm sorry, but that requires a definition of "constant" that explicitly
> excludes routine arguments, 

/s/explicitly/implicitly


> which is like saying horses are not mammals, just "because".

No, it's like saying that horses are not apes, because the definition of 
apes excludes horses.

But in any case, rather than continue my argument (which was absolutely 
brilliant and flawless, I might add... *wink*), I'm going to skip ahead 
to the place where the penny drops and I understand what you were trying, 
but failed, to say.


> Consider some C++ code:
> 
>void foo( SomeType const v )
>{
>// Here the name v is constant: that name's value can't change.
>// (Except that in C++ you can do anything by using low-level
>stuff.)
>}

*penny drops*

Ahaha!!! Now I get it! You want to make the *parameter* of the function a 
constant, rather than the *argument* passed to the function. In other 
words, you want to prohibit something like this:

def f(x):
y = x + 1  # do something with the value passed by the caller
x = 0  # changing the binding will fail INSIDE the function

while still allowing the caller to call the function with variables.


Right -- now what you say makes sense, and is a perfectly reasonable 
thing to do in languages that support constants.

You weren't clear about what you wanted, and the only thing I could think 
of which matched your description was something completely bizarre: given 
some function f with one parameter, you wanted to declare that parameter 
as a constant with some value (say 42), so that calling the function with 
an argument of any other value would be an error, e.g.:

x = 42
f(x)  # succeeds
x = 43
f(x)  # fails

E.g. implemented something like this:

def f(x):
if x != 42:
raise ConstantError('x is not the constant 42')
...

except that the test is done automatically by the compiler.


> To be pedantic, original routine names are usually absolutely not meant
> to be assigned to.
> 
> If you have
> 
>def foo(): whatever()
> 
> you simply shouldn't, in general, do
> 
>foo = bar
> 
> I think you understood that, i.e., that the above comment of yours is
> just rhetoric?

First of all, I think you're underestimating the usefulness and frequency 
of rebinding names to functions. I'll accept that it's uncommon, but it's 
not *that* uncommon to justify "absolutely not meant to be assigned to".

In fact, it's so common that we have special syntax for one special case 
of it. Instead of:

def f():
...

f = g(f)

we can write:

@g
def f():
...

While decorator syntax can only be used at function-definition time, the 
concept of function decoration is far more general. You can decorate any 
function, at any time, and doing so is very, very useful for (e.g.) 
debugging, logging, monkey-patching, introspection, error-checking, and 
others. And decoration itself is only one special case of function 
rebinding.

As for your second point, my earlier comment is mostly aimed at what I 
see as your misleading habit of referring to *names* as being constants, 
rather than the value assigned to the name. Such terminology is 
misleading. So if you want to call that rhetoric, I won't argue.



>> As far as I know, no programming language provides a standard facility
>> for renaming entities, be they data or routines:
> 
> Eiffel (IIRC) and C++ come pretty close.
> 
> E.g., in C++:
> 
>int a;
>int& b = a;// A new name for a.
> 
>b = 123;  // Assigns to a.

No, that's not a renaming operation. a still exists; you haven't told the 
compiler "stop accepting a as the name for this memory location, and 
accept b instead". It's an aliasing operation: name b and name a both 
refer to the same memory location and hence the same value.

Even if C++ had an operation for "delete this name from the compiler's 
symbol table" (equivalent to del in Python), that's still a two-step 
process: create a new name that co-exists with the original name, then 
delete the original name. The fact that the C++ designers didn't see fit 
to give the language a way to change a name demonstrates that it's not 
the mutability of *names* which matter, but of *values* assigned to the 
names.

I can think of a language where it would probably be possible, but non-
standard, to write a rename instruction: Forth. It should be possible to 
use the tick instruction to get the address of a variable, constant or 
function, then dir

Re: iterators and views of lists

[Brendan Miller]

On Fri, Dec 18, 2009 at 2:47 PM, Bearophile  wrote:
> Brendan Miller:
>> I agree though, it doesn't matter to everyone and anyone. The reason I
>> was interested was because i was trying to solve some specific
>> problems in an elegant way. I was thinking it would be cool to make
>> python more usable in programming competitions by giving it its own
>> port of the STL's algorithm library, which needs something along the
>> lines of C++'s more powerful iterators.
>
> It seems you have missed my post, so here it is, more explicitly:
>
> http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf
>
> Bye,
> bearophie
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Andrei is arguing for replacing iterators with ranges, which are
equivalently powerful to C++ iterators but easier to use. Actually,
what I want in python is something like this.

If you look at Anh Hai Trinh's posts he implemented something
basically like a python version of andre's ranges, which he called
listagents. That pdf is interesting though because he's thought
through what an interface for bidrectional ranges should look like
which I had not yet.

However, you should note that andrei's ranges allow mutation of the
original datastructure they are a range over. My impression from your
earlier post was that you disagreed with that idea of mutating
algorithms and wanted something more functional, whereas I, and andrei
in that pdf, are more concerned with imperative programming and in
place algorithms.

I don't want to get into a big discussion about FP vs imperative
programming, as that is simply too large a topic and I have had that
discussion many times before. I'm more of a turing machine than a
lambda calculus guy myself, but if other people make other choices
that's fine with me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Fri, 18 Dec 2009 21:29:27 -0600, John Bokma wrote:

> Steven D'Aprano  writes:
> 
>> CPython 2.5 and on has a keyhole optimizer that replaces many constant
>   ^^^
> Shouldn't that be peephole?

Alternate names for the same thing.


>> expressions with pre-computed values.
> 
> And that's called constant folding.

Yes.

> Unless I misread your post (or have been out of touch with compiler
> building too long)

No :)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[Gregory Ewing]

Ryan Kelly wrote:

Someone else wrote:

It will be the
same as the difference between a for loop and a call to map.


Not so.  If you use the "dis" module to peek at the bytecode generated
for a list comprehension, you'll see it's very similar to that generated
for an explicit for-loop.


The usual advice is that if you have a built-in function that
does what you want done for each element, then using map() is
probably the fastest way.

However, if you need to create a Python function to pass to
map(), the list comprehension may well be faster, because it
avoids the cost of a Python function call per element.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Gregory Ewing]

Mensanator wrote:

Really? Does that mean you don't use literals, to save the time
required to convert them to integers?


I think all he means is that when he *does* use a named
constant, he spells it in lower case rather than upper
case, e.g. 'twopi' rather than 'TWOPI'.

I don't think there's anything much wrong with that. It
can be useful sometimes to visually distinguish constants
from variables, but it's not a necessity. Also the all-
uppercase convention isn't the only way to do that -- it's
a C-ism that isn't universally followed in Python. An
alternative often used is just to uppercase the first
character. Python itself uses that for many of its
built-in constants, such as None, True, False.

Arguing that functions are usually constants and should
therefore have uppercase names is missing the point --
everyone expects them to be constant anyway, so there's
no need for a typographical convention to indicate that.
In the rare cases where they're not constant, they can
usually be named in a way that makes this obvious.

(And BTW, looking up a global name is *slower* than using
a literal. Although a local name is probably about the
same speed as a literal, as they're both array accesses.)

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dangerous behavior of list(generator)

[Gregory Ewing]

Albert van der Horst wrote:


An important feature that is not documented is a severe defect.


This isn't something that I would expect to find documented
under the heading of generator expressions, because it doesn't
have anything to do with them. It's an interaction between
the iterator protocol and the list() constructor. Any other
iterable that leaked a StopIteration exception would cause
the same effect.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Gregory Ewing]

Terry Reedy wrote:
On the other hand, Python indexes are a form of 
random access iterator, the top of the hierarchy.


The term "random access iterator" seems oxymoronic to
me. Iteration is all about operating on things in
sequence. If you're accessing elements arbitrarily,
then you're not iterating.

Python, traditionally, only came with one mutable builtin sequence type, 
so the sort function was made a method of that type.


Also it probably operates rather more efficiently
than a generic one would, as it doesn't have to go
through a general mechanism to access elements, but
can take advantage of its knowledge of the internal
structure of a list.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Creating Classes

[Dave Angel]

Alf P. Steinbach wrote:
* Dave 
Angel -> seafoid:


One other point:  you should always derive a class from some other 
class, or 'object' by default.  So you should being the class 
definition by:


class Seq(object):

Why?  It mainly has to do with super().  But in any case if you omit 
the 'object' it's an "old style" class, and that's not even supported 
in 3.x, so it's better to just get in the habit before it matters.


I think it's best to mention that the above applies to Python 2.x.

In Python 3.x, writing

   class Seq:

is equivalent to writing

   class Seq( object ):


We were talking about 2.x   And I explicitly mentioned 3.x because if 
one develops code that depends on old-style classes, they'll be in 
trouble with 3.x, which has no way to specify old-style classes.  In 
3.x, all classes are new-style.  And although it'll no longer matter 
whether you specify (object), it doesn't do any harm.  As I said, it's a 
good habit for a beginner to get into when defining classes.


DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: Creating Classes

[Alf P. Steinbach]

* Dave Angel -> seafoid:


One other point:  you should always derive a class from some other 
class, or 'object' by default.  So you should being the class definition 
by:


class Seq(object):

Why?  It mainly has to do with super().  But in any case if you omit the 
'object' it's an "old style" class, and that's not even supported in 
3.x, so it's better to just get in the habit before it matters.


I think it's best to mention that the above applies to Python 2.x.

In Python 3.x, writing

   class Seq:

is equivalent to writing

   class Seq( object ):

E.g.,

  >>> class A: pass
  ...
  >>> A.__bases__
  (,)
  >>>
  >>> class B( object ): pass
  ...
  >>> B.__bases__
  (,)
  >>> _


Curiously I can't find anything about 'object' in the language spec, but in the 
3.1.1 standard library spec §2 "Built-in functions" it says "object is a base 
for all classes."



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Seek support for new slice syntax PEP.

[Nobody]

On Fri, 18 Dec 2009 09:49:26 -0500, Colin W. wrote:

> You don't say, but seem to imply that the slice components include None.

That's how missing components are implemented at the language level:

> class foo:
=   def __getitem__(self, s):
= return s
= 
> x = foo()
> x[::]
slice(None, None, None)
> x[1::2]
slice(1, None, 2)

The defaults of zero, sys.maxint and one apply to built-in types, but
nothing forces user-defined types to behave this way.

Or maybe I misunderstood your point.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating Classes

[Dave Angel]

seafoid wrote:

Hey Guys,

I have started to read over classes as a brief respite from my parsing
problem.

When a class is defined, how does the class access the data upon which the
class should act?

Example:

class Seq:


def __init__(self, data, alphabet = Alphabet.generic_alphabet):
self.data = data 
self.alphabet = alphabet


def tostring(self):   
return self.data  


def tomutable(self):
return MutableSeq(self.data, self.alphabet)

def count(self, item):

return len([x for x in self.data if x == item])

I know what it should do, but have no idea how to feed it the data.

Methinks I need to invest in actual computing books as learning from
biologists is hazy!

Kind regards,
Seafoid.
	  
  
Steve's message was good, but I feel he kind of jumped in the middle.  A 
class is a description of a type of object, and the behaviors and data 
that each instance of the object supports.


You create the object by using the class name like a function call.  The 
arguments to that "call" are passed to the __init__ method.


So  obj = Seq("abcd")or   obj = Seq("defg", "abcdefg")would each 
create an object of the class.  But generally, many objects will exist, 
each with different data.


The data in the object is accessed in what appears to be the "self" 
namespace.  The name self is just a convention, but it's the first 
argument of each method of the class.  So when somebody calls the 
count() method, they pass 'item' a value, but self is used to refer to 
that particular object's data.


So how does 'self' get assigned?  That's what Steve was describing.  
When you use the syntax:

obj.count("value")

you actually call the count method with self referring to "obj" and item 
referring to "value".  obj does double-duty here, both defining which 
class' count() method will be called, and also supplying the first 
parameter to the call, the "self" parameter.


There are more complex things that can go on, like creating "bound" 
function objects, but  I think this should get you pretty far.


One other point:  you should always derive a class from some other 
class, or 'object' by default.  So you should being the class definition by:


class Seq(object):

Why?  It mainly has to do with super().  But in any case if you omit the 
'object' it's an "old style" class, and that's not even supported in 
3.x, so it's better to just get in the habit before it matters.


DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Fri, 18 Dec 2009 15:26:05 -0800, Mensanator wrote:

>> The second deviation is that since most names are constants,
> 
> Really? Does that mean you don't use literals, to save the time required
> to convert them to integers? Isn't that done at compile time?
> 
> So, instead of doing the Collatz Conjecture as
> 
> while a>1:
>   f = gmpy.scan1(a,0)
>   if f>0:
> a = a >> f
>   else:
> a = a*3 + 1
> 
> You would do this?
> 
> zed = 0
> one = 1
> two = 2
> twe = 3
> while a>one:
>   f = gmpy.scan1(a,zed)
>   if f>zed:
> a = a >> f
>   else:
> a = a*twe + one
> 
> Does this really save any time?

There are some people who might argue that using *any* magic constants in 
code is wrong, and that *all* such values should be declared as a 
constant.

It's easy to take the mickey out of such an extreme position:

zed = 0  # in case we need to redefine 0 as something else
one = 1  # likewise
two = 3  # changed from 2 to 3 to reflect the end of the Mayan calendar

# The following is guaranteed to pass unless the world is ending.
assert one+one == two-zed



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Steven D'Aprano:

On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:


That said, and a bit off-tangent to your comment's main thrust, the time
spent on coding that repeated-division-by-2 optimization would, I think,
be better spent googling "Collatz Conjecture"  --  avoiding writing
/any/ code. ;-)


That's a strange thing to say. 


No. The code shown was like attacking Fermat's last theorem with a little Python 
script checking out number triplets. It's already been done (not to mention that 
that theorem's been proven, although that's, AFAIK, not the case for Collatz').




Now, it's a different story if you're using the gmpy module. You DON'T
want to use literals in loops involving gmpy, because they would have
to be coerced to .mpz's on every pass through the loop.

[...]

Yeah, good point. Few languages have compile time evaluation of
logically constant expressions. 


Surely that's an implementation issue rather than a language issue.


No, it isn't.

An optimizer can only do so much, as you yourself note below!

With language support it's a very different matter because guarantees propagate 
so that sophisticated analysis is no longer necessary: the compiler /knows/, 
because it's explicitly being told.




C++0x will have that feature (called
'constexpr' IIRC) but in Python, current C++ etc. it's just a good idea
to precompute values, and name them, rather than computing them again
and again where they're needed.


CPython 2.5 and on has a keyhole optimizer that replaces many constant 
expressions with pre-computed values.


# Python 2.4

dis.dis(compile('1+1', '', 'eval'))

  0   0 LOAD_CONST   0 (1)
  3 LOAD_CONST   0 (1)
  6 BINARY_ADD
  7 RETURN_VALUE

# Python 2.5

dis.dis(compile('1+1', '', 'eval'))

  1   0 LOAD_CONST   1 (2)
  3 RETURN_VALUE


Unfortunately it doesn't help Mensanator's case, because there's no way 
to tell the compiler to generate mpz objects instead of int objects, and 
expressions such as gmpy.mpz(0) are not recognised as compile-time 
constants.


See?

;-)



Mine does when I use gmpy. Otherwise, the notion that "most names are
constants" is generally false.
No, it depends on what you mean by "constant". 


All names are constant. Always. The Python language does not support 
renaming names -- as far as I know, no language does.


No-ones been talking about renaming names. I think that's purely rhetorical on 
your part but it may be that you really believe so. In the latter case, just try 
to interpret statements so that they're meaningful instead of meaningless. :-)




The problem with Python,
as Google noted, is that the language is so excessively dynamic: even
names of routines are variables, 


Don't say that, that is confusing the name with the value.


Nope.


The terms 
"constant" and "variable" refer to the values bound to a name, not the 
name itself:


I'm sorry, that's incorrect.

Quote from §4.1 "Naming and binding" of the Python 3.1.1 language spec:

"If a name is bound in a block, it is a local variable of that block, unless 
declared as nonlocal. If a name is bound at the module level, it is a global 
variable. (The variables of the module code block are local and global.) If a 
variable is used in a code block but not defined there, it is a free variable."




what you mean is that even routines are variables.


I'm sorry but I can't make sense of what you write here. In addition I'm not 
sure what you mean because there are two main interpretations.


If you mean that user defined Python routines are mutable, yes that's right, but 
not what I was talking about (which you can easily see by checking whether it 
makes sense in context; it doesn't).


If you mean that a routine of itself is a variable, no it isn't, but the name of 
a routine, like "foo" in


   def foo: print( "uh" )

or "bar" in

   bar = lambda: print( "oh" )

is a variable, per the language specification's definition quoted above (and 
also by any reasonable meaning of "variable"!).


The meaning of "variable" for Python terminology is specified by the language 
specification, as quoted above: a variable is a name.



[snipped rest, irrelevant]


Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[John Bokma]

Steven D'Aprano  writes:

> CPython 2.5 and on has a keyhole optimizer that replaces many constant 
   ^^^
Shouldn't that be peephole?

> expressions with pre-computed values.

And that's called constant folding.

Unless I misread your post (or have been out of touch with compiler
building too long)

-- 
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Steven D'Aprano]

On Sat, 19 Dec 2009 02:24:00 +, MRAB wrote:

> Gregory Ewing wrote:
>> MRAB wrote:
>> 
>>> In simple cases you might be replacing with the same string every
>>> time, but other cases you might want the replacement to contain
>>> substrings captured by the regex.
>> 
>> But you can give it a function that has access to the match object and
>> can produce whatever replacement string it wants.
>> 
>> You already have a complete programming language at your disposal.
>> There's no need to invent yet another mini-language for the replacement
>> string.
>> 
> There's no need for list comprehensions either, but they're much-used
> shorthand.

The same can't be said for regex replacement strings, which are far more 
specialised.

And list comps don't make anything *harder*, they just make things 
easier. In contrast, the current behaviour of regex replacements makes it 
difficult to use special characters as part of the replacement string. 
That's not good.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Webpy and UnicodeDecodeError

[Dave Angel]

Oscar Del Ben wrote:



You'll notice that one of the strings is a unicode one, and another one
has the character 0x82 in it.  Once join() discovers Unicode, it needs
to produce a Unicode string, and by default, it uses the ASCII codec to
get it.

If you print your 'l' list (bad name, by the way, looks too much like a
'1'), you can see which element is Unicode, and which one has the \xb7
in position 42.  You'll have to decide which is the problem, and solve
it accordingly.  Was the fact that one of the strings is unicode an
oversight?  Or did you think that all characters would be 0x7f or less?  
Or do you want to handle all possible characters, and if so, with what

encoding?

DaveA



Thanks for your reply DaveA.

Since I'm dealing with file uploads, I guess I should only care about
those. I understand the fact that I'm trying to concatenate a unicode
string with a binary, but I don't know how to deal with this. Perhaps
the uploaded file should be encoded in some way? I don't think this is
the case though.

  
You have to decide what the format of the file is to be.  If you have 
some in bytes, and some in Unicode, you have to be explicit about how 
you merge them.  And that depends who's going to use the file, and for 
what purpose.


Before you try to do a join(), you have to do a conversion of the 
Unicode string(s) to bytes.  Try str.encode(), where you get to specify 
what encoding to use.


In general, you want to use the same encoding for all the bytes in a 
given file.  But as I just said, that's entirely up to you.


DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError: logging module bug ?

[Peter]

./of/logger.py

from logging import Formatter

class RootFormatter(Formatter):
 pass
class ModuleFormatter(Formatter):
 pass
class ClassFormatter(Formatter):
 pass
class DataFormatter(Formatter):
 pass

(and an empty ./of/__init__.py) your initial script runs without error. If
you want external help please

(1) make sure that you provide all necessary files needed to reproduce the
error

(2) remove as much of the code as possible that does not contribute to the
problem. (This is also an effective debugging technique)

Peter
   
(1), (2): That is sometimes easier said than done, especially if you 
still lack experience in a given language. You are right, though, my 
request lacked precision, sorry for the noise !

Your answer helped me to find the problem:

given the minimal files above, in my logging.cfg file , I specified:

[formatter_root]
format=%(levelname)s %(name)s %(message)s
datefmt=%S
# does not work:
class = of.logger.RootFormatter

based on my misunderstanding, that the path to the RootFormatter could 
be specfied as a normal python class defined in a package.module .


It seems that I have to say instead:

# works:
class = logger.RootFormatter

This was somehow unexpected for me, since in a module using logger.py, I 
could use either import:


from mylogger import logger  # without package name

or

from of.mylogger import logger  # with package name

but this does not seem to work for the class specification in the config 
file (only the former works).


Again, thanks a lot !
Peter



--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Steven D'Aprano:

On Fri, 18 Dec 2009 19:00:48 +0100, Alf P. Steinbach wrote:


In fact almost no Python
code does, but then it seems that people are not aware of how many of
their names are constants and think that they're uppercasing constants
when in fact they're not. E.g. routine arguments 


Routine arguments are almost never constants, since by definition they 
will vary according to the value passed by the caller.


I'm sorry, but that requires a definition of "constant" that explicitly excludes 
routine arguments, which is like saying horses are not mammals, just "because".


There are two sensible definitions of "constant": compile time constant, and 
constant-after-initialization.


And since Python doesn't have or support user defined compile time (named) 
constants even in the way that a programmer views the execution of a program, 
only the const after initialization meaning can /reasonably/ apply.


I hope you see that with the constant-after-initialization meaning it's rather 
irrelevant that an argument's value "will vary according to [the actual 
argument]"  --  for an argument A, id(A) does in general not vary after 
initialization, after creation of A; and it can certainly not vary before!


Consider some C++ code:

  void foo( SomeType const v )
  {
  // Here the name v is constant: that name's value can't change.
  // (Except that in C++ you can do anything by using low-level stuff.)
  }

As the comment there exemplifies, in addition to the 2 main meanings of 
constness one can differentiate between constness at different levels of an 
expression, e.g., in Python, with respect to what the language enforces,


  s = "blah"

is a non-constant name referring to a constant (immutable value), while

  a = ["blah"]

is a non-constant name referring to a non-constant value (a Python 'list') 
containing a constant value  --  but with respect to intended constness there 
might be more constness here, although there can't be less.


Since Python doesn't support constness enforcement, your statement that routine 
arguments are almost never constants must refer to their actual usage, i.e. 
intention. It may be the case that in most code you're familiar with routine 
arguments are generally modified. And/or it may be that in code you're familiar 
with routines regularly modify the objecs that their arguments refer to, i.e. 
that the arguments are constant names referring to mutable objects.


In code that I'm familiar with, but that's admittedly mostly in other languages, 
most argument names are constant at the top level of constness, i.e., translated 
to Python, id(A) does generally not change when A is a formal argument.



(The exception is that some formal parameters in Python are given default 
values and flagged as "do not use", e.g. some methods in the random 
module. One might argue that they are constants in the sense that the 
caller is warned not to use them at all.)


Huh.



and in particular
routine NAMES are usually constants, absolutely not meant to be
modified, but it would be silly to UC...

[emphasis added by me]


The only thing sillier than uppercasing routine names is to confuse the 
name of a thing for the thing it represents. The names of *all* entities, 
whether of constants, variables or routines, are "not meant to be 
modified". As a general rule, programs will no more work if you rename a 
variable 'x' to 'y' than if you rename a function 'f' to 'g' -- that's 
why refactoring requires that any renamings be done carefully. There's no 
need to single out routines for special treatment in that regard.


To be pedantic, original routine names are usually absolutely not meant to be 
assigned to.


If you have

  def foo(): whatever()

you simply shouldn't, in general, do

  foo = bar

I think you understood that, i.e., that the above comment of yours is just 
rhetoric?


As far as I know, no programming language provides a standard facility 
for renaming entities, be they data or routines:


Eiffel (IIRC) and C++ come pretty close.

E.g., in C++:

  int a;
  int& b = a;// A new name for a.

  b = 123;  // Assigns to a.


the closest we have is 
something like Python where you can do this:


# make an entity x
x = 23
# use it
x += 1
# make a new name that refers to the same entity as x
y = x  
# delete the old name

del x
# now use the new name
y += 1


Well, you're off on the wrong track as far as convincing me about something is 
concerned. First, your belief about renaming not being supported by any 
languages is largely incorrect, as shown above. Secondly, I was not talking 
about renaming things  --  that creative interpretation is pretty meaningless...



[snipped the rest, irrelevant]

Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cookie name and expiration

[ShoqulKutlu]

I'd already found my problem, that I had to set the "path" propert of
a cookie object something like below:

myCookie.path = '/'

This is not the cookie content and not documented in the mod_python
cookie module documentation.

I hope this will help anyone else..

Regards,
Kutlu


On Nov 26, 1:32 am, ShoqulKutlu  wrote:
> Hi,
>
> I'm testing the Cookie module's MarshalCookie in mod_python on my
> localhost environment. Everything looks ok and cookie set, get and
> update operations work well. But I'm not sure about the cookie name
> could be set by Cookie module. I mean the name of cookie file saved in
> the Temporary Internet Files directory of Internet Explorer. Consider
> that I run the script ashttp://localhost:8080/myScripts/myScript
> When I look at the Temporary Internet Files dir, not like other
> cookies came from normal websites, the cookie file was saved as
> "myScript/" and the cookie address is shown ashttp://localhost:8080/myScripts/
> I don't know this is normal behaviour of the browser or there is an
> option to set the name of cookie file.
>
> I mentioned the expiration in the subject but maybe it's not related
> to expiration. For example if I run 
> directlyhttp://localhost:8080/myScripts/myScript2
> after a day and look for the temporary internet directory again, I see
> a second cookie named "myScript2/" and the first cookie (myScript/)
> still exists there. But the first cookie seems no longer valid for
> this domain although I set the expire range for 30 days.
>
> Do I miss something about cookies concept and behaviour of browsers?
> Could anyone please clarify?
>
> Thanks and regards,Kutlu

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:

> That said, and a bit off-tangent to your comment's main thrust, the time
> spent on coding that repeated-division-by-2 optimization would, I think,
> be better spent googling "Collatz Conjecture"  --  avoiding writing
> /any/ code. ;-)

That's a strange thing to say. 


>> Now, it's a different story if you're using the gmpy module. You DON'T
>> want to use literals in loops involving gmpy, because they would have
>> to be coerced to .mpz's on every pass through the loop.
[...]
> Yeah, good point. Few languages have compile time evaluation of
> logically constant expressions. 

Surely that's an implementation issue rather than a language issue.


> C++0x will have that feature (called
> 'constexpr' IIRC) but in Python, current C++ etc. it's just a good idea
> to precompute values, and name them, rather than computing them again
> and again where they're needed.

CPython 2.5 and on has a keyhole optimizer that replaces many constant 
expressions with pre-computed values.

# Python 2.4
>>> dis.dis(compile('1+1', '', 'eval'))
  0   0 LOAD_CONST   0 (1)
  3 LOAD_CONST   0 (1)
  6 BINARY_ADD
  7 RETURN_VALUE

# Python 2.5
>>> dis.dis(compile('1+1', '', 'eval'))
  1   0 LOAD_CONST   1 (2)
  3 RETURN_VALUE


Unfortunately it doesn't help Mensanator's case, because there's no way 
to tell the compiler to generate mpz objects instead of int objects, and 
expressions such as gmpy.mpz(0) are not recognised as compile-time 
constants.


>> Mine does when I use gmpy. Otherwise, the notion that "most names are
>> constants" is generally false.
> 
> No, it depends on what you mean by "constant". 

All names are constant. Always. The Python language does not support 
renaming names -- as far as I know, no language does.


> The problem with Python,
> as Google noted, is that the language is so excessively dynamic: even
> names of routines are variables, 

Don't say that, that is confusing the name with the value. The terms 
"constant" and "variable" refer to the values bound to a name, not the 
name itself: what you mean is that even routines are variables.

Consider the following Pascal declaration:

const
  a = 1;
var
  b: integer;

Neither name 'a' nor 'b' ever change; a is always a and b is always b. 
You wouldn't describe b as a constant because the name never changes, 
would you? What matters is that the value assigned to the name can, or 
can't, be changed by the caller.

Like any other language, Python *names* are always constant: you can 
create them at will (without needing a declaration); you can delete them 
(with the del statement, something Pascal doesn't allow you to do); but 
there's no way to change a name once it exists. Obviously it would be 
misleading to claim that Python name/object bindings ("variables") are 
therefore constant because of this.

So how would I say what you are trying to say, but in a less-misleading 
fashion?

Names can always (well, almost -- there are a few exceptions) be rebound, 
regardless of whether they are currently bound to a data object (string, 
int, float...) or a routine (function, method...). Since the name by 
which we refer to a function can be rebound, we refer to the name/object 
binding as variable rather than constant -- exactly the same as any other 
name/object binding.

Or the shorter way:

Since all names can be rebound, regardless of what value they have (int, 
string, function, whatever) all names are variables and Python has no 
constants other than special pre-defined names like None.



> and there /are/ no named user defined
> constants except logically, in the programmer's mind. 

Yes, that is correct, although there are tricks you can do to make 
slightly-more-constant-like constants, such as Alex Martelli's "constant 
module" recipe in the Cookbook, but there are no true constants in Python.


> And logically
> (that is, at the "in the programmer's mind" level), if you define
> "constant" as a name whose value will not change after initialization,
> then routine names are constants.

Some languages enforce that, and in those languages, it makes sense to 
describe functions as constants. Python is not one of those languages.


> However, if you define "constant" as only a global scope (that is,
> module scope) name that denotes a boolean, numerical or string or Null
> value and that doesn't change after initialization, then your statement
> about the scarcity of constants appears to be true, but using a
> practically useless definition.

I won't speak for Mensanator, but I wouldn't be so restrictive about the 
*types* of data that constants can hold. Not in Python, at least, other 
languages can and do limit the types of constants to a handful of 
predefined types known to the compiler.

Nor would I say that "constants" (note the scare-quotes) can only occur 
in module scope. There's nothing

Re: Raw string substitution problem

[MRAB]

Gregory Ewing wrote:

MRAB wrote:


In simple cases you might be replacing with the same string every
time, but other cases you might want the replacement to contain
substrings captured by the regex.


But you can give it a function that has access to the match object
and can produce whatever replacement string it wants.

You already have a complete programming language at your disposal.
There's no need to invent yet another mini-language for the
replacement string.


There's no need for list comprehensions either, but they're much-used
shorthand.
--
http://mail.python.org/mailman/listinfo/python-list

Re: tarfiles usage on python 2.4.4

[MRAB]

tekion wrote:

All,
I am using tarfile module and my python is version 2.4.4.  When I call
method extractall, I am getting error method does not exist. Could
someone confirm if the method exist on python 2.4.4? Thanks


It's new in Python 2.5.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Fri, 18 Dec 2009 19:00:48 +0100, Alf P. Steinbach wrote:

> In fact almost no Python
> code does, but then it seems that people are not aware of how many of
> their names are constants and think that they're uppercasing constants
> when in fact they're not. E.g. routine arguments 

Routine arguments are almost never constants, since by definition they 
will vary according to the value passed by the caller.

(The exception is that some formal parameters in Python are given default 
values and flagged as "do not use", e.g. some methods in the random 
module. One might argue that they are constants in the sense that the 
caller is warned not to use them at all.)


> and in particular
> routine NAMES are usually constants, absolutely not meant to be
> modified, but it would be silly to UC...
[emphasis added by me]


The only thing sillier than uppercasing routine names is to confuse the 
name of a thing for the thing it represents. The names of *all* entities, 
whether of constants, variables or routines, are "not meant to be 
modified". As a general rule, programs will no more work if you rename a 
variable 'x' to 'y' than if you rename a function 'f' to 'g' -- that's 
why refactoring requires that any renamings be done carefully. There's no 
need to single out routines for special treatment in that regard.

As far as I know, no programming language provides a standard facility 
for renaming entities, be they data or routines: the closest we have is 
something like Python where you can do this:

# make an entity x
x = 23
# use it
x += 1
# make a new name that refers to the same entity as x
y = x  
# delete the old name
del x
# now use the new name
y += 1

So while it is true that routine names are not meant to be modified, 
neither are variable names (that is, the names of variables) or the names 
of anything else either. But this is not what is meant by "constant": 
being a constant means that the *value*, not the *name*, is never meant 
to change.

It is true that, usually, the names of certain types of object (usually 
functions, classes, methods and modules) are typically expected to not be 
re-bound. Having done this:

def parrot(colour='blue'):
return "Norwegian %s" % colour.titlecase()


I would *rarely* rebind the name parrot to another object. Rarely, but 
not quite never: I might monkey-patch the function, or decorate it in 
some way, or change the implementation, so such routines aren't quite 
constant in the sense you mean. While it's unusual to vary a function, it 
isn't forbidden.

Even in languages where routines are "first class objects" like ints and 
strings, we treat such objects as special. Even if the function named 
parrot above was expected to never change, I wouldn't describe it as a 
constant. "Constant" and "variable" refer to *data*, not routines or 
other special objects like modules.

It's illustrative to consider what we might do when writing a program 
that does treat functions as data, say, a program that integrated other 
functions. One might very well do something like this:

function_to_be_integrated = math.sin  # a variable
SIMPSONS = integrators.simpsons_method  # a constant
UPPER_RECT = monkey_patch(integrators.upper)
LOWER_RECT = monkey_patch(integrators.lower)

integrate(function_to_be_integrated, 
  limits=(-math.pi/2, math.pi),
  method=SIMPSONS
  )

This would clearly indicate that `function_to_be_integrated` holds 
variable data (which happens to be a function) while `SIMPSONS` etc are 
expected to hold constant data (which also happen to be functions).


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

tarfiles usage on python 2.4.4

[tekion]

All,
I am using tarfile module and my python is version 2.4.4.  When I call
method extractall, I am getting error method does not exist. Could
someone confirm if the method exist on python 2.4.4? Thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[Ryan Kelly]

> > Tenting the time spent by each approach (using time.clock()), with a
> > file with about 100,000 entries, I get 0.03s for the loop and 0.05s
> > for the listcomp.
>
> Anything else being equal, list comprehensions will be the faster
> becuase they incur fewer name and attribute lookups. It will be the
> same as the difference between a for loop and a call to map. A list
> comprehension is basically an enhancement of map.

Not so.  If you use the "dis" module to peek at the bytecode generated
for a list comprehension, you'll see it's very similar to that generated
for an explicit for-loop.  The byte-code for a call to map is very
different.

Basically:  both a for-loop and a list-comp do the looping in python
bytecode, while a call to map will do the actual looping in C.

>>> def comper():
... return [i*2 for i in xrange(10)]
... 
>>> 
>>> dis.dis(comper)
  2   0 BUILD_LIST   0
  3 DUP_TOP 
  4 STORE_FAST   0 (_[1])
  7 LOAD_GLOBAL  0 (xrange)
 10 LOAD_CONST   1 (10)
 13 CALL_FUNCTION1
 16 GET_ITER
>>   17 FOR_ITER17 (to 37)
 20 STORE_FAST   1 (i)
 23 LOAD_FAST0 (_[1])
 26 LOAD_FAST1 (i)
 29 LOAD_CONST   2 (2)
 32 BINARY_MULTIPLY 
 33 LIST_APPEND 
 34 JUMP_ABSOLUTE   17
>>   37 DELETE_FAST  0 (_[1])
 40 RETURN_VALUE
>>>
>>>
>>>
>>> def maper():
... return map(lambda i: i*2,xrange(10))
... 
>>> dis.dis(maper)
  2   0 LOAD_GLOBAL  0 (map)
  3 LOAD_CONST   1 (>> 



  Cheers,

Ryan

-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
r...@rfk.id.au|  http://www.rfk.id.au/ramblings/gpg/ for details



signature.asc
Description: This is a digitally signed message part
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: withrestart 0.2.1

[Ryan Kelly]

On Fri, 2009-12-18 at 07:12 -0500, Neal Becker wrote:
> I haven't tried it, but it sounds really cool.  I suppose I should expect a 
> lot more overhead compared to try/except, since it's not built-in to python?

It's a pretty thin layer on top of try/except so I'll be surprised if
there is *too* much overhead.  The only overhead is at establishment
and/or invocation time - calling some extra functions, walking a few
stack frames, etc.

I've attached a highly scientific benchmark I threw together this
morning.  Results:

  Establishing a restart/tryexcept but not using it:

test_tryexcept0:  1.23 usec
test_restarts0:  34.90 usec

  Establishing a restart/tryexcept, returning a new value:

test_tryexcept1:  3.56 usec
test_restarts1:  67.30 usec

  Establishing a restart/tryexcept, raising a new error: 

test_tryexcept2:  5.86 usec
test_restarts2:  90.20 usec

  Not having to pass status flags or callback functions through every
layer of your API to properly recover from errors:

tryexcept:impossible :-(
withrestart:  priceless  :-)


  Cheers,

  Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
r...@rfk.id.au|  http://www.rfk.id.au/ramblings/gpg/ for details


from withrestart import *


def test_tryexcept0():
def raiser():
return 7
def invoker():
return raiser()
def catcher():
try:
return invoker()
except ValueError:
return 7
assert catcher() == 7

def test_tryexcept1():
def raiser():
raise ValueError
def invoker():
return raiser()
def catcher():
try:
return invoker()
except ValueError:
return 7
assert catcher() == 7

def test_tryexcept2():
def raiser():
raise ValueError
def invoker():
raiser()
def catcher():
try:
invoker()
except ValueError:
raise TypeError
try:
catcher()
except TypeError:
pass
else:
raise AssertionError



def test_restarts0():
def raiser():
return 7
def invoker():
with restarts(use_value) as invoke:
return invoke(raiser)
def catcher():
with Handler(ValueError,"use_value",7):
return invoker()
assert catcher() == 7

def test_restarts1():
def raiser():
raise ValueError
def invoker():
with restarts(use_value) as invoke:
return invoke(raiser)
def catcher():
with Handler(ValueError,"use_value",7):
return invoker()
assert catcher() == 7

def test_restarts2():
def raiser():
raise ValueError
def invoker():
with restarts(raise_error) as invoke:
invoke(raiser)
def catcher():
with Handler(ValueError,"raise_error",TypeError):
invoker()
try:
catcher()
except TypeError:
pass
else:
raise AssertionError




signature.asc
Description: This is a digitally signed message part
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Steven D'Aprano]

On Fri, 18 Dec 2009 10:39:15 -0800, Carl Banks wrote:

> It is true that Python iterators can't be used to mutate the underlying
> structure--if there is actual underlying data structure-- 

An iterator is a protocol. So long as you have __iter__ and next (or 
__next__ in Python 3) methods, your class is an iterator. What you do in 
those methods are up to you. If you want to mutate the underlying data, 
you're free to do so.

Just for chuckles, here's a quick-and-dirty iterator version of the Tower 
of Hanoi that mutates itself as needed. (I make no promise that it is 
either efficient or bug-free.)


class Hanoi:
def __init__(self, n=5):
self.a = range(n, 0, -1)
self.b = []
self.c = []
self.num = 0
def __str__(self):
template = "Needle %d: %s"
d = [template % (i, data) for (i,data) in 
enumerate([self.a, self.b, self.c])]
return '\n'.join(d) + '\n'
def __iter__(self):
return self
def next(self):
if [] == self.a == self.c:
raise StopIteration
self.num += 1
if self.num % 2:
# Odd-numbered move: move the smallest disk one 
# position clockwise.
needle = self.find_smallest()
nxt = "bca"["abc".find(needle)]
else:
# Even-numbered move: make the only legal move of the 
# next-smallest disk.
needle, nxt = self.find_legal()
self.move(needle, nxt)
return str(self)
def move(self, frm, to):
"""Move the top disk from needle `frm` to needle `to`."""
from_needle = getattr(self, frm)
to_needle = getattr(self, to)
to_needle.append(from_needle[-1])
del from_needle[-1]
def find_smallest(self):
for needle in 'abc':
if 1 in getattr(self, needle):
return needle
def find_legal(self):
"""Find the only legal move not using the smallest disk."""
ignore = self.find_smallest()
if ignore == 'a':  disks = 'bc'
elif ignore == 'b':  disks = 'ac'
else:  disks = 'ab'
left_needle = getattr(self, disks[0])
right_needle = getattr(self, disks[1])
if left_needle == []:
return disks[1], disks[0]
elif right_needle == []:
return disks[0], disks[1]
elif left_needle[-1] < right_needle[-1]:
return disks[0], disks[1]
else:
return disks[1], disks[0]




And in use:


>>> p = Hanoi()
>>> for state in p:
... print state
...
Needle 0: [5, 4, 3, 2]
Needle 1: [1]
Needle 2: []

Needle 0: [5, 4, 3]
Needle 1: [1]
Needle 2: [2]

[ rest of output skipped for brevity ]


Python iterators don't generally mutate the thing they are iterating 
over, not because they can't, but because it's generally a bad idea to do 
so. In general, it really only makes sense as an optimization in 
situations where you have so much data that you can't afford to make a 
copy of it. For the occasional time where it does make sense, Python 
iterators are perfectly capable of doing so.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

* Mensanator:

The second deviation is that since most names are constants,


Really? Does that mean you don't use literals, to save the time
required to convert them to integers? Isn't that done at compile
time?

So, instead of doing the Collatz Conjecture as

while a>1:
  f = gmpy.scan1(a,0)
  if f>0:
a = a >> f
  else:
a = a*3 + 1

You would do this?

zed = 0
one = 1
two = 2
twe = 3
while a>one:
  f = gmpy.scan1(a,zed)
  if f>zed:
a = a >> f
  else:
a = a*twe + one


That seems to have no relation to what you quoted / responded to.

On the other hand, if there is some specific rôle played by the 3 above, where 
some other value (like e.g. 5) might be used instead, then a self descriptive 
name for that rôle might be good.


Such reasonable naming (not what you did above) then allows easier modification 
of and makes it easier to understand the code.


That said, and a bit off-tangent to your comment's main thrust, the time spent 
on coding that repeated-division-by-2 optimization would, I think, be better 
spent googling "Collatz Conjecture"  --  avoiding writing /any/ code. ;-)




Does this really save any time?


If by "it" you mean the silly naming, no it doesn't.

On the contrary, it wastes time, both for writing the code and reading it.

Generally, IMO, think about the clarity of your code. If naming something 
increases clarity, then name the thing. If it doesn't increase clarity, don't.




Now, it's a different story if you're using the gmpy module.
You DON'T want to use literals in loops involving gmpy, because
they would have to be coerced to .mpz's on every pass through the
loop.

In that case, you DO want to use constants as opposed to literals:

ZED = gmpy.mpz(0)
ONE = gmpy.mpz(1)
TWO = gmpy.mpz(2)
TWE = gmpy.mpz(3)
while a>ONE:
  f = gmpy.scan1(a,0) # int used here, so it can be a literal
  if f>ZED:
a = a >> f
  else:
a = a*TWE + ONE

And yes, the time savings can be tremendous, especially when 'a'
has over 50,000 decimal digits.


Yeah, good point. Few languages have compile time evaluation of logically 
constant expressions. C++0x will have that feature (called 'constexpr' IIRC) but 
in Python, current C++ etc. it's just a good idea to precompute values, and name 
them, rather than computing them again and again where they're needed.




. I do not follow PEP

8's recommendation to use uppercase names of constants. In fact almost no Python
code does,


Mine does when I use gmpy. Otherwise, the notion that "most names
are constants" is generally false.


No, it depends on what you mean by "constant". The problem with Python, as 
Google noted, is that the language is so excessively dynamic: even names of 
routines are variables, and there /are/ no named user defined constants except 
logically, in the programmer's mind. And logically (that is, at the "in the 
programmer's mind" level), if you define "constant" as a name whose value will 
not change after initialization, then routine names are constants.


However, if you define "constant" as only a global scope (that is, module scope) 
name that denotes a boolean, numerical or string or Null value and that doesn't 
change after initialization, then your statement about the scarcity of constants 
appears to be true, but using a practically useless definition.


I think for such constants exported by modules it's a good idea to at least 
provide uppercase names so as conform to very firmly established convention. 
There might even be tools that rely on that convention. But for application code 
the uppercase names are just distracting, and they don't help you...



Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Eclipse Carriage Return Workaround

[Gregory Ewing]

Steve Holden wrote:


Can anyone think of a simple way work around this issue by overriding
__builtins__.input() with a function that calls input() and then returns
an rstrip()ped version of the input string? I though of setting a
PYTHONSTARTUP environment variable, but that only affects interactive
interpreter instances.


Maybe you could put something in site.py?

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[MRAB]

Rory Campbell-Lange wrote:

On 18/12/09, mattia (ger...@gmail.com) wrote:
Hi all, I have a dictionary that uses dates and a tuples ad key, value 
pairs. I need to sort the values of the dict and insert everything in a 
tuple. The additional problem is that I need to sort the values looking 
at the i-th element of the list. I'm not that good at python (v3.1), but 
this is my solution:



d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)}
t = [x for x in d.values()]
def third(mls):

... return mls[2]
...

s = sorted(t, key=third)
pres = []
for x in s:

... for k in d.keys():
... if d[k] == x:
... pres.append(k)
... break
...

res = []
for x in pres:

... res.append((x, d[x]))
...

res

[(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]


How about 


mylist = [z for z in zip(list(d), list(d.values()))]



The Pythonic way for the above line is:

>>> mylist = list(d.items())


and then sort on your sort criteria, either i[0], i[0][1], i[0][2] or
i[0][3].

Rory





--
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Gregory Ewing]

MRAB wrote:


In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.


But you can give it a function that has access to the
match object and can produce whatever replacement string
it wants.

You already have a complete programming language at
your disposal. There's no need to invent yet another
mini-language for the replacement string.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[Rory Campbell-Lange]

On 18/12/09, mattia (ger...@gmail.com) wrote:
> Hi all, I have a dictionary that uses dates and a tuples ad key, value 
> pairs. I need to sort the values of the dict and insert everything in a 
> tuple. The additional problem is that I need to sort the values looking 
> at the i-th element of the list. I'm not that good at python (v3.1), but 
> this is my solution:
> 
> >>> d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)}
> >>> t = [x for x in d.values()]
> >>> def third(mls):
> ... return mls[2]
> ...
> >>> s = sorted(t, key=third)
> >>> pres = []
> >>> for x in s:
> ... for k in d.keys():
> ... if d[k] == x:
> ... pres.append(k)
> ... break
> ...
> >>> res = []
> >>> for x in pres:
> ... res.append((x, d[x]))
> ...
> >>> res
> [(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]

How about 

>>> mylist = [z for z in zip(list(d), list(d.values()))]

and then sort on your sort criteria, either i[0], i[0][1], i[0][2] or
i[0][3].

Rory



-- 
Rory Campbell-Lange
Director
r...@campbell-lange.net

Campbell-Lange Workshop
www.campbell-lange.net
0207 6311 555
3 Tottenham Street London W1T 2AF
Registered in England No. 04551928
-- 
http://mail.python.org/mailman/listinfo/python-list

Acceesing python httplib2 over a network share in windows 7

[aj]

I am trying to run python from a network share on windows 7.
The network share is T:

>t:\python-2.6.1\python
Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import httplib2
httplib2\__init__.py:29: DeprecationWarning: the md5 module is
deprecated; use hashlib instead
import md5
Traceback (most recent call last):
File "", line 1, in 
File "T:\python-2.6.1\lib\python2.6\site-packages
\httplib2\__init__.py", line 36, in 
import httplib
File "T:\python-2.6.1\lib\httplib.py", line 77, in 
import mimetools
File "T:\python-2.6.1\lib\mimetools.py", line 6, in 
import tempfile
File "T:\python-2.6.1\lib\tempfile.py", line 34, in 
from random import Random as _Random
File "T:\python-2.6.1\lib\random.py", line 871, in 
_inst = Random()
File "T:\python-2.6.1\lib\random.py", line 96, in __init__
self.seed(x)
File "T:\python-2.6.1\lib\random.py", line 110, in seed
a = long(_hexlify(_urandom(16)), 16)
WindowsError: [Error 127] The specified procedure could not be
found


When I copy python-2.6.1 to my local drive it works fine. It also
works fine on my windows XP machine using the same network share.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Mensanator]

> The second deviation is that since most names are constants,

Really? Does that mean you don't use literals, to save the time
required to convert them to integers? Isn't that done at compile
time?

So, instead of doing the Collatz Conjecture as

while a>1:
  f = gmpy.scan1(a,0)
  if f>0:
a = a >> f
  else:
a = a*3 + 1

You would do this?

zed = 0
one = 1
two = 2
twe = 3
while a>one:
  f = gmpy.scan1(a,zed)
  if f>zed:
a = a >> f
  else:
a = a*twe + one

Does this really save any time?

Now, it's a different story if you're using the gmpy module.
You DON'T want to use literals in loops involving gmpy, because
they would have to be coerced to .mpz's on every pass through the
loop.

In that case, you DO want to use constants as opposed to literals:

ZED = gmpy.mpz(0)
ONE = gmpy.mpz(1)
TWO = gmpy.mpz(2)
TWE = gmpy.mpz(3)
while a>ONE:
  f = gmpy.scan1(a,0) # int used here, so it can be a literal
  if f>ZED:
a = a >> f
  else:
a = a*TWE + ONE

And yes, the time savings can be tremendous, especially when 'a'
has over 50,000 decimal digits.

. I do not follow PEP
> 8's recommendation to use uppercase names of constants. In fact almost no 
> Python
> code does,

Mine does when I use gmpy. Otherwise, the notion that "most names
are constants" is generally false.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[mattia]

Il Fri, 18 Dec 2009 18:00:42 -0500, David Robinow ha scritto:

> On Fri, Dec 18, 2009 at 5:34 PM, mattia  wrote:
>> Hi all, I have a dictionary that uses dates and a tuples ad key, value
>> pairs. I need to sort the values of the dict and insert everything in a
>> tuple. The additional problem is that I need to sort the values looking
>> at the i-th element of the list. I'm not that good at python (v3.1),
>> but this is my solution:
>>
> d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)} t = [x for x in
> d.values()]
> def third(mls):
>> ...     return mls[2]
>> ...
> s = sorted(t, key=third)
> pres = []
> for x in s:
>> ...     for k in d.keys():
>> ...         if d[k] == x:
>> ...             pres.append(k)
>> ...             break
>> ...
> res = []
> for x in pres:
>> ...     res.append((x, d[x]))
>> ...
> res
>> [(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]
>
>
>> Can you provide me a much pythonic solution (with comments if possible,
>> so I can actually learn something)?
>>
>> Thanks, Mattia
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
> I won't engage in any arguments about pythonicity but it seems simpler
> if you convert to a list of tuples right away.
> 
> d = {1:('a', 1, 12), 5:('r',21,10), 2:('u',9,8)} l = [(x, d[x]) for x in
> d.keys()]
> def third(q):
> return q[1][2]
> 
> s = sorted(l, key=third)
> print s

Thanks, I'm not yet aware of all the wonderful conversions python can do, 
amazing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[David Robinow]

On Fri, Dec 18, 2009 at 5:34 PM, mattia  wrote:
> Hi all, I have a dictionary that uses dates and a tuples ad key, value
> pairs. I need to sort the values of the dict and insert everything in a
> tuple. The additional problem is that I need to sort the values looking
> at the i-th element of the list. I'm not that good at python (v3.1), but
> this is my solution:
>
 d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)}
 t = [x for x in d.values()]
 def third(mls):
> ...     return mls[2]
> ...
 s = sorted(t, key=third)
 pres = []
 for x in s:
> ...     for k in d.keys():
> ...         if d[k] == x:
> ...             pres.append(k)
> ...             break
> ...
 res = []
 for x in pres:
> ...     res.append((x, d[x]))
> ...
 res
> [(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]

>
> Can you provide me a much pythonic solution (with comments if possible,
> so I can actually learn something)?
>
> Thanks, Mattia
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I won't engage in any arguments about pythonicity but it seems simpler
if you convert to a list of tuples right away.

d = {1:('a', 1, 12), 5:('r',21,10), 2:('u',9,8)}
l = [(x, d[x]) for x in d.keys()]
def third(q):
return q[1][2]

s = sorted(l, key=third)
print s
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Bearophile]

Brendan Miller:
> I agree though, it doesn't matter to everyone and anyone. The reason I
> was interested was because i was trying to solve some specific
> problems in an elegant way. I was thinking it would be cool to make
> python more usable in programming competitions by giving it its own
> port of the STL's algorithm library, which needs something along the
> lines of C++'s more powerful iterators.

It seems you have missed my post, so here it is, more explicitly:

http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf

Bye,
bearophie
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[mattia]

Actually, in order to use duplicate values I need something like:

>>> import copy
>>> d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8), 3:('u', 9, 8) }
>>> dc = copy.deepcopy(d)
>>> t = [x for x in d.values()]
>>> def third(mls):
... return mls[2]
...
>>> s = sorted(t, key=third)
>>> pres = []
>>> for x in s:
... for k in d.keys():
... if d[k] == x:
... pres.append(k)
... del d[k] # speedup and use duplicate values
... break
...
>>> res = []
>>> for x in pres:
... res.append((x, dc[x]))
...
>>> res
[(2, ('u', 9, 8)), (3, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 
12))]
>>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sort the values of a dict

[Chris Kaynor]

I'd write it as:
s = sorted(d.iteritems(), key=lambda i: i[1][2])

If using python 3, it should be d.items() instead of d.iteritems().

d.iteritems() is a generator yielding tuples of (key, value) from
the dictionary 'd'.
lambda i: i[1][2] is the same as:
def sort_(i):
return i[1][2]
but in-line.

Chris


On Fri, Dec 18, 2009 at 2:34 PM, mattia  wrote:

> Hi all, I have a dictionary that uses dates and a tuples ad key, value
> pairs. I need to sort the values of the dict and insert everything in a
> tuple. The additional problem is that I need to sort the values looking
> at the i-th element of the list. I'm not that good at python (v3.1), but
> this is my solution:
>
> >>> d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)}
> >>> t = [x for x in d.values()]
> >>> def third(mls):
> ... return mls[2]
> ...
> >>> s = sorted(t, key=third)
> >>> pres = []
> >>> for x in s:
> ... for k in d.keys():
> ... if d[k] == x:
> ... pres.append(k)
> ... break
> ...
> >>> res = []
> >>> for x in pres:
> ... res.append((x, d[x]))
> ...
> >>> res
> [(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]
> >>>
>
> Can you provide me a much pythonic solution (with comments if possible,
> so I can actually learn something)?
>
> Thanks, Mattia
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Sort the values of a dict

[mattia]

Hi all, I have a dictionary that uses dates and a tuples ad key, value 
pairs. I need to sort the values of the dict and insert everything in a 
tuple. The additional problem is that I need to sort the values looking 
at the i-th element of the list. I'm not that good at python (v3.1), but 
this is my solution:

>>> d = {1:('a', 1, 12), 5:('r', 21, 10), 2:('u', 9, 8)}
>>> t = [x for x in d.values()]
>>> def third(mls):
... return mls[2]
...
>>> s = sorted(t, key=third)
>>> pres = []
>>> for x in s:
... for k in d.keys():
... if d[k] == x:
... pres.append(k)
... break
...
>>> res = []
>>> for x in pres:
... res.append((x, d[x]))
...
>>> res
[(2, ('u', 9, 8)), (5, ('r', 21, 10)), (1, ('a', 1, 12))]
>>>

Can you provide me a much pythonic solution (with comments if possible, 
so I can actually learn something)?

Thanks, Mattia
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Setting Parameters inside of code

[David Robinow]

On Fri, Dec 18, 2009 at 10:46 AM, Jim Valenza  wrote:
> Hello All - I have a very novice question for any of you out there.  I need
> to assign several parameters to a code in python. I have an example of a
> code that was in DOS that I would need to set as parameters in my Python
> script.
>
> SetLocal EnableDelayedExpansion
> SET OUTPUT=..\log
> SET LOG=..\log
> SET COMPLETED=..\Loaded

You have an unusual use of the word "parameter". What you are doing is
setting environment variables. You can read these values in Python

import os
outvar = os.getenv("OUTPUT")
logvar = os.getenv("LOG")
completevar = os.getenv("COMPLETED")

# etc
print outvar
print logvar
print completevar

--
You may also want to pass arguments (I think 'argument' is what you
called 'parameter') to your script:
   myScript.py firstArg secondArg thirdArg

hunt for sys.argv in the documentation.


For more sophisticated argument passing you may want to look at the
'optparse' module
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Setting Parameters inside of code

[Terry Reedy]

On 12/18/2009 10:46 AM, Jim Valenza wrote:

Hello All - I have a very novice question for any of you out there.  I
need to assign several parameters to a code in python.


In Python, a 'parameter' is a function local name defined in the header 
of the function and bound to an argument when the function is called.


 I have an example

of a code that was in DOS that I would need to set as parameters in my
Python script.
SetLocal EnableDelayedExpansion

SET OUTPUT=..\log


OUTPUT = '../log/


SET LOG=..\log
SET COMPLETED=..\Loaded
SET FAILED=..\Errors
SET REPORT=..\log\batch_projectdb.txt
SET SOURCE=..\InBox
SET BACKUP=..\Backup
SET SERVER=housdep01
SET INSTANCE=port:5151
SET DATASET=sde
SET /a LOADED=0
SET /a POSTED=0
  :: If the directories don't exist, later commands run into problems.

MD %OUTPUT%


MD = make directory. Look for this in the os or os.path modules.
Do read the tutorial.

Terry Jan Reedy



MD %LOG%
MD %COMPLETED%
MD %FAILED%
MD %BACKUP%
I've been researching Parameters with the Python manuals and have not
found the help to be usefull as there is not much documentation for some
reason. I am new to the Python world so maybe I'm missing an important
piece of vocab.
Thanks A lot
Jim




--
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Terry Reedy]

On 12/18/2009 1:00 AM, Brendan Miller wrote:


For the benefit of those of us who aren't C++ programmers, what do its
iterators do that Python's don't?


It depends on what one means by 'iterator'. Python iterators do not fit 
in the STL hierarchy. On the other hand, Python indexes are a form of 
random access iterator, the top of the hierarchy.



Python iterators basically only have one operation:



next(), which returns the next element or throws StopIteration.

In C++ terminology this is a Input iterator. It is good for writing
"for each" loops or map reduce operations.

An input iterator can't mutate the data it points to.


For that, Python uses indexes. Random access 'iterators' are a 
generalization of sequence indexes.



C++ also has progressively stronger iterators:
http://www.sgi.com/tech/stl/Iterators.html

InputIterator<- read only, one direction, single pass
ForwardIterator<- read/write, one direction, multi pass
BidirectionalIterator<- read/write, can move in either direction
RandomAccessIterator<- read/write, can move in either direction by an
arbitrary amount in constant time (as powerful as a pointer)


An index can be incremented or decremented an arbitrary amount. Note 
that Python indexes are object pointers, not memory byte pointers, so 
that index + 1 points to the next object, not the next byte of memory in 
possibly the same object. They are, however, much safer than pointers in 
that x[i] can only retrieve objects of x and never, surprise, surprise, 
of some other collection.



Each only adds extra operations over the one before. So a
RandomAccessIterator can be used anywhere a InputIterator can, but not
vice versa.

Also, this is a duck typing relationship, not a formal class
inheritance. Anything that quacks like a RandomAccessIterator is a
RandomAccessIterator, but there is no actual RandomAccessIterator
class.

So, for instance stl sort function takes pair of random access
iterator delimiting a range, and can sort any datastructure that can
provide that powerful of an iterator (arrays, vectors, deques).


Python, traditionally, only came with one mutable builtin sequence type, 
so the sort function was made a method of that type. There is also the 
importable array module. Apparently, there has been little demand for a 
generic array.sort method as there is none. One could easily write a 
function that took an array or other seqeunce and two indexes as args.


The generic reversed() builtin function by default uses sequence indexes 
in the obvious manner to return a reversed version of *any* sequence, 
mutable or not.



http://www.sgi.com/tech/stl/sort.html

MyCollection stuff;
// put some stuff in stuff

sort(stuff.begin(), stuff.end());

Where begin() and end() by convention return iterators pointing to the
beginning and end of the sequence.


start,stop = 0, len(seq)

Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list

Re: PyArg_ParseTupleAndKeywords in Python3.1

[casevh]

On Dec 18, 10:28 am, Joachim Dahl  wrote:
> My mistake seems to be that I declared
>
> char a, b;
>
> instead of
>
> int a, b;
>
> Thank you for sorting this out.
>
> Joachim

I think you need to initialize them, too.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[seafoid]

Rory,

You are a gentleman!

Thank you very much for your suggestion!

Kind Regards,
Seafoid.


Rory Campbell-Lange wrote:
> 
> On 18/12/09, seafoid (fitzp...@tcd.ie) wrote:
>> http://old.nabble.com/Parsing-file-format-to-ensure-file-meets-criteria-to26837682.html
> 
> Your specification is confusing. However I suggest you break it down
> the code so that the steps in your programme are logical. Good luck.
> 
> # example psuedocode
> headers = {}
> header_clauses = {}
> current_header = None
> 
> def header_parser (input):
> split input into parts
> make unique header desciptor
> check not in headers else abort with error (?)
> add descriptor to headers hash
> # eg descriptor 1 = [attrib1, attrib2, attrib3]
> return descriptor
> 
> def clause_parser (input, current_header):
> if current_header is None: abort
> split clause into parts
> store in array in header_clauses [current_header]
> # this will make a data structure like this:
> # header_clauses = {
> #   descriptor1 = {[ clause parts ], [ clause parts ], ... }
> #   descriptor2 = {[ clause parts ], [ clause parts ], ... }
> 
> def comment_parser (input)
> pass
> 
> # now run over the file
> for l in lines:
> if l[0] == 'c':
> comment_parser(l)
> elif l[0] == 'p':
> current_header = header_parser(l)
> else:
> clause_parser(l, current_header)
> 
> # now that we have stored everything, check the data
> for h in headers:
> attrib1, attrib2, attrib3  = headers[h]
> for c in header_clauses:
> iterate over the arrays of clause parts either adding them
> up or comparing them to the header attributes
> 
> -- 
> Rory Campbell-Lange
> Director
> r...@campbell-lange.net
> 
> Campbell-Lange Workshop
> www.campbell-lange.net
> 0207 6311 555
> 3 Tottenham Street London W1T 2AF
> Registered in England No. 04551928
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Line-indexing-in-Python-tp26845253p26849944.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[seafoid]

Hey folks,

Is it possible to assign a list within a nested list to a variable?

Example:

l = [['1', '2', '3'], ['4', '5', '6']]

for i in l:
if i[0][1] == '1':
m = i

Indeed, I generally do not understand how to assign variables within a loop!

Is there an easy way to 'flatten' a nested list and assign the lists to
variables?

Thanks,
Seafoid.
-- 
View this message in context: 
http://old.nabble.com/Line-indexing-in-Python-tp26845253p26849921.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[Rory Campbell-Lange]

On 18/12/09, seafoid (fitzp...@tcd.ie) wrote:
> http://old.nabble.com/Parsing-file-format-to-ensure-file-meets-criteria-to26837682.html

Your specification is confusing. However I suggest you break it down
the code so that the steps in your programme are logical. Good luck.

# example psuedocode
headers = {}
header_clauses = {}
current_header = None

def header_parser (input):
split input into parts
make unique header desciptor
check not in headers else abort with error (?)
add descriptor to headers hash
# eg descriptor 1 = [attrib1, attrib2, attrib3]
return descriptor

def clause_parser (input, current_header):
if current_header is None: abort
split clause into parts
store in array in header_clauses [current_header]
# this will make a data structure like this:
# header_clauses = {
#   descriptor1 = {[ clause parts ], [ clause parts ], ... }
#   descriptor2 = {[ clause parts ], [ clause parts ], ... }

def comment_parser (input)
pass

# now run over the file
for l in lines:
if l[0] == 'c':
comment_parser(l)
elif l[0] == 'p':
current_header = header_parser(l)
else:
clause_parser(l, current_header)

# now that we have stored everything, check the data
for h in headers:
attrib1, attrib2, attrib3  = headers[h]
for c in header_clauses:
iterate over the arrays of clause parts either adding them
up or comparing them to the header attributes

-- 
Rory Campbell-Lange
Director
r...@campbell-lange.net

Campbell-Lange Workshop
www.campbell-lange.net
0207 6311 555
3 Tottenham Street London W1T 2AF
Registered in England No. 04551928
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating Classes

[seafoid]

Steve, that has indeed clarified matters!

Thanks!

-- 
View this message in context: 
http://old.nabble.com/Creating-Classes-tp26848375p26849864.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Brendan Miller]

On Fri, Dec 18, 2009 at 10:39 AM, Carl Banks  wrote:
> On Dec 17, 10:00 pm, Brendan Miller  wrote:
>> On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano
>>
>>  wrote:
>> > On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote:
>>
>> >> I was thinking it would be cool to make python more usable in
>> >> programming competitions by giving it its own port of the STL's
>> >> algorithm library, which needs something along the lines of C++'s more
>> >> powerful iterators.
>>
>> > For the benefit of those of us who aren't C++ programmers, what do its
>> > iterators do that Python's don't?
>>
>> Python iterators basically only have one operation:
>>
>> next(), which returns the next element or throws StopIteration.
>>
>> In C++ terminology this is a Input iterator. It is good for writing
>> "for each" loops or map reduce operations.
>
> Hmm.  I guess the main thing that's bothering me about this whole
> thread is that the true power of Python iterators is being overlooked
> here, and I don't think you're being fair to call Python iterators
> "weak" (as you did in another thread) or say that they are only good
> for for-else type loops.
>
> The fact is, Python iterators have a whole range of powers that C++
> iterators do not.  C++ iterators, at least the ones that come in STL,
> are limited to iterating over pre-existing data structures.  Python
> iterators don't have this limation--the data being "iterated" over can
> be virtual data like an infinite list, or data generated on the fly.
> This can be very powerful.
>
> Here's a cool slideshow on what can be done with iterators in Python
> (generators specifically):
>
> http://www.dabeaz.com/generators/
>
> It is true that Python iterators can't be used to mutate the
> underlying structure--if there is actual underlying data structure--
> but it doesn't mean they are weak or limited.  Python and C++
> iterators are similar in their most basic usage, but grow more
> powerful in different directions.
>

When I said they are "weak" I meant it in sense that the algorithms
writeable against an InputerIterator interface (which is what python's
iterator protocol provides) is a proper subset of the algorithms that
can be written against a RandomAccessIterator interface. The class of
algorithms expressible against a python iterator is indeed limited to
those that can be expressed with a for each loop or map/reduce
operation.

Yes, python iterators can indeed iterate over infinite lists. All that
you need to do is have the next() operation never throw. The same
thing can be done in c++, or any other language that has iterators.

Generators provide a convenient way to write input iterators; however,
the same thing can be done in any language. It just requires more
boilerplate code to keep track of the iteration state.

Of course, that's not to say generators aren't important. They make it
that much easier to write your own iterators, so in a practical sense,
people are more likely to write their own iterators in python than in
C++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Creating Classes

[Steve Holden]

seafoid wrote:
> Hey Guys,
> 
> I have started to read over classes as a brief respite from my parsing
> problem.
> 
> When a class is defined, how does the class access the data upon which the
> class should act?
> 
> Example:
> 
> class Seq:
> 
> def __init__(self, data, alphabet = Alphabet.generic_alphabet):
> self.data = data 
> self.alphabet = alphabet
> 
> def tostring(self):   
> return self.data  
> 
> def tomutable(self):
> return MutableSeq(self.data, self.alphabet)
> 
> def count(self, item):
> return len([x for x in self.data if x == item])
> 
> I know what it should do, but have no idea how to feed it the data.
> 
> Methinks I need to invest in actual computing books as learning from
> biologists is hazy!
> 
> Kind regards,
> Seafoid.
> 

Supposing you create an instance of your Seq class

seq = Seq("aggadgaga")

When you call (let's say) the tostring() method of the *instance* the
interpreter automatically provides that as the first (self) argument to
the method call.

So in fact

   seq.tostring()

is exactly the same as

   Seq.tostring(seq)

but considerably shorter and easier to understand. Try asking the
interpreter what Seq.tostring and seq.tostring are, and you will find
one is an
unbound method", the other is a "bound method" (which means "bound to a
given instance" - in other words, it "knows" which instance it's a
method *of*.

Does this clarify it or make it more obscure?

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[Brian J Mingus]

On Fri, Dec 18, 2009 at 11:55 AM, sturlamolden wrote:

> On 17 Des, 18:37, Carlos Grohmann  wrote:
>
> > Tenting the time spent by each approach (using time.clock()), with a
> > file with about 100,000 entries, I get 0.03s for the loop and 0.05s
> > for the listcomp.
> >
> > thoughts?
>
> Let me ask a retoric question:
>
> - How much do you really value 20 ms of CPU time?
>

If it takes 1 nanosecond to execute a single instruction then 20
milliseconds represents 20 million instructions. Therefore I value 20ms of
CPU time very much indeed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Alf P. Steinbach]

* Carl Banks:

On Dec 18, 11:08 am, "Alf P. Steinbach"  wrote:

* Carl Banks:




On Dec 17, 10:00 pm, Brendan Miller  wrote:

On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano
 wrote:

On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote:

I was thinking it would be cool to make python more usable in
programming competitions by giving it its own port of the STL's
algorithm library, which needs something along the lines of C++'s more
powerful iterators.

For the benefit of those of us who aren't C++ programmers, what do its
iterators do that Python's don't?

Python iterators basically only have one operation:
next(), which returns the next element or throws StopIteration.
In C++ terminology this is a Input iterator. It is good for writing
"for each" loops or map reduce operations.

Hmm.  I guess the main thing that's bothering me about this whole
thread is that the true power of Python iterators is being overlooked
here, and I don't think you're being fair to call Python iterators
"weak" (as you did in another thread) or say that they are only good
for for-else type loops.
The fact is, Python iterators have a whole range of powers that C++
iterators do not.  C++ iterators, at least the ones that come in STL,
are limited to iterating over pre-existing data structures.  Python
iterators don't have this limation--the data being "iterated" over can
be virtual data like an infinite list, or data generated on the fly.
This can be very powerful.

It's good that Python iterators can do things.

However, it's not the case that C++ iterators can't do those things.

C++ iterators very much routinely do such things.


STL Iterators?  No.  Maybe if you're talking about boost or homemade
iterators or something I could buy it, though I'd still bs suspicious
of "routinely".


The intersection of STL and the C++ standard library is of nearly the same size 
as the STL, but I don't understand why you're limiting yourself to the STL.


After all, the STL was first developed for the Ada language, IIRC.

Using the standard C++ library, per the 1998 first (and current!) C++ standard, 
below is an idiomatic "copy Carl Banks to output" C++ program where, you might 
note, the "ostream_iterator" has a sister "istream_iterator" that definitely 
does not only iterat over a "pre-existing data structure", as you wrote.


Of course, mostly one defines iterators in the source code or by using Boost or 
similar libraries; that's how C++ works.


There's no special language support for iterators in C++; it's wholly a library 
and application defined concept.




#include 
#include 
#include 
#include 

int main()
{
using namespace std;
static char const* constwords[] =
{ "Carl", "Banks", "is", "wrong", "on", "the", "Internet", "!" };

copy(
words, words + sizeof(words)/sizeof(*words),
ostream_iterator( cout, "\n" )
);
}



Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Help with invoking standard mail app in windows

[Kev Dwyer]

On Sat, 19 Dec 2009 06:36:32 +1100, Astan Chee wrote:

> Kev Dwyer wrote:
>> Hello Astan,
>>
>> Your code executes without error for me on Win98 (!) with Python 2.5 or
>> XP with Python 2.6.
>>
>> It would help people to help you if you could provide the *exact*
>> console output from when you try to execute the code, *including* the
>> traceback. That way we can work out which line of code is hitting the
>> exception.
>>
>> Cheers,
>>
>> Kev
>>
>>
> Hi,
> My mistake. The length of body is over 1400 characters. Here is my
> updated code and result:
> 
> import urllib, webbrowser, win32api
> def mailto_url(to=None,subject=None,body=None,cc=None):
> """
> encodes the content as a mailto link as described on
> http://www.faqs.org/rfcs/rfc2368.html """ url = "mailto: " +
> urllib.quote(to.strip(),"@,") sep = "?"
> if cc:
> url+= sep + "cc=" + urllib.quote(cc,"@,") sep = "&"
> if subject:
> url+= sep + "subject=" + urllib.quote(subject,"") sep = "&"
> if body:
> # Also note that line breaks in the body of a message MUST be #
> encoded with "%0D%0A". (RFC 2368)
> body="\r\n".join(body.splitlines())
> url+= sep + "body=" + urllib.quote(body,"") sep = "&"
> return url
> 
> txtTo = "t...@com.com"
> txtSubject = "Test Subject"
> body = "Test body"
> for t in range(278):
> body+="test "
> txtCC = "cc_t...@com.com"
> 
> url = mailto_url(txtTo,txtSubject,body,txtCC)
> #win32api.ShellExecute(0,'open',url,None,None,0)
> webbrowser.open(url,new=1)
> # os.startfile(url)
> 
> result:
> 
> Traceback (most recent call last):
>   File "C:/stanc_home/python/mail_test.py", line 32, in 
> webbrowser.open(url,new=1)
>   File "C:\Python25\lib\webbrowser.py", line 61, in open
> if browser.open(url, new, autoraise):
>   File "C:\Python25\lib\webbrowser.py", line 518, in open
> os.startfile(url)
> WindowsError: [Error 5] Access is denied: 'mailto:
> t...@com.com?cc=cc_test@com.com&subject=Test%20Subject&body=Test%
20bodytest%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20t
>  est%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20te
>  st%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20tes
>  t%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test
%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%
20test%20test%20test%20test%20test%20test%20test
>  %20test%20test%20test%20test%20test%20'
> 
> Is there some sort of limitation here? If I shorten the string, it works
> fine. You're right, but I'm wondering if there is a way to go around
> this limitation.
> Thanks again
> Cheers
> Astan

Hmmm.

For me, body < 1400 opens an outlook message form, body > 1400 opens IE7.

No time to look into this right now, but perhaps this is a windows thing.

Don't know why you get windowserror, perhaps permissions???

I'll try and look again later/tomorrow.

Cheers,

Kev

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How Do I...?

[Tim Chase]

Victor Subervi wrote:

How do I...?


Well, you start by reading a book on how to program.  You would 
then learn that what you want (in all likelihood) is a 
dictionary/map structure for dynamically created key/value pairs. 
Once you have progressed from your current apprenticeship and 
achieved the rank of third-degree journeyman programmer, the ways 
of dynamic variable creation will avail themselves.



i = 0
nameNos = []
nos = []
for option in ourOptions():
  nameNos.append('optionNo%d' % i)
  nos.append(i)
  i += 1

The idea is that through every iteration of option, I can create a new
variable such as 'optionNo0', 'optionNo1' etc and assign values such as '0',
'1' etc to them. Of course that code doesn't work. What would?


As stated above, you want a dictionary where your keys are

  'optionNo%d' % i

and your values are "i".  You can also use the more idiomatic

  for i, option in enumerate(ourOptions()):
...

and skip the manual initialization and incrementation of "i".  Or 
even more succinctly, you could pass the above as a generator to 
the dict() initialization.  But that's a level-2 apprentice bit 
of code.  Patience grasshopper.


And as additional weirdness, you don't actually make use of 
"option" in your for-loop...


-tkc



--
http://mail.python.org/mailman/listinfo/python-list

Re: How Do I...?

[Victor Subervi]

On Fri, Dec 18, 2009 at 3:46 PM, Rami Chowdhury wrote:

> On Fri, Dec 18, 2009 at 10:55, Victor Subervi 
> wrote:
> > Hi;
> > I have this code:
> >
> > i = 0
> > nameNos = []
> > nos = []
> > for option in ourOptions():
> >   nameNos.append('optionNo%d' % i)
> >   nos.append(i)
> >   i += 1
> >
> > The idea is that through every iteration of option, I can create a new
> > variable such as 'optionNo0', 'optionNo1' etc and assign values such as
> '0',
> > '1' etc to them.
>
> What are you expecting to do with those variables and values later?
>

:-} I discovered after I wrote this that all I had to do was use the length
of ourOptions. But it's an interesting academic question for future
reference ;/
V
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How Do I...?

[Rami Chowdhury]

On Fri, Dec 18, 2009 at 10:55, Victor Subervi  wrote:
> Hi;
> I have this code:
>
>     i = 0
>     nameNos = []
>     nos = []
>     for option in ourOptions():
>   nameNos.append('optionNo%d' % i)
>   nos.append(i)
>   i += 1
>
> The idea is that through every iteration of option, I can create a new
> variable such as 'optionNo0', 'optionNo1' etc and assign values such as '0',
> '1' etc to them.

What are you expecting to do with those variables and values later?



-- 
Rami Chowdhury
"Never assume malice when stupidity will suffice." -- Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help with invoking standard mail app in windows

[Astan Chee]

Kev Dwyer wrote:

Hello Astan,

Your code executes without error for me on Win98 (!) with Python 2.5 or 
XP with Python 2.6.  

It would help people to help you if you could provide the *exact* console 
output from when you try to execute the code, *including* the traceback.  
That way we can work out which line of code is hitting the exception.


Cheers,

Kev

  

Hi,
My mistake. The length of body is over 1400 characters. Here is my 
updated code and result:


import urllib, webbrowser, win32api
def mailto_url(to=None,subject=None,body=None,cc=None):
   """
   encodes the content as a mailto link as described on
   http://www.faqs.org/rfcs/rfc2368.html """
   url = "mailto: " + urllib.quote(to.strip(),"@,")
   sep = "?"
   if cc:
   url+= sep + "cc=" + urllib.quote(cc,"@,")
   sep = "&"
   if subject:
   url+= sep + "subject=" + urllib.quote(subject,"")
   sep = "&"
   if body:
   # Also note that line breaks in the body of a message MUST be
   # encoded with "%0D%0A". (RFC 2368)
   body="\r\n".join(body.splitlines())
   url+= sep + "body=" + urllib.quote(body,"")
   sep = "&"
   return url

txtTo = "t...@com.com"
txtSubject = "Test Subject"
body = "Test body"
for t in range(278):
   body+="test "
txtCC = "cc_t...@com.com"

url = mailto_url(txtTo,txtSubject,body,txtCC)
#win32api.ShellExecute(0,'open',url,None,None,0)
webbrowser.open(url,new=1)
# os.startfile(url)

result:

Traceback (most recent call last):
 File "C:/stanc_home/python/mail_test.py", line 32, in 
   webbrowser.open(url,new=1)
 File "C:\Python25\lib\webbrowser.py", line 61, in open
   if browser.open(url, new, autoraise):
 File "C:\Python25\lib\webbrowser.py", line 518, in open
   os.startfile(url)
WindowsError: [Error 5] Access is denied: 'mailto: 
t...@com.com?cc=cc_test@com.com&subject=Test%20Subject&body=Test%20bodytest%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20te

st%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test%20test
%20test%20test%20test%20test%20test%20'

Is there some sort of limitation here? If I shorten the string, it works 
fine. You're right, but I'm wondering if there is a way to go around 
this limitation.

Thanks again
Cheers
Astan

--
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Carl Banks]

On Dec 18, 11:08 am, "Alf P. Steinbach"  wrote:
> * Carl Banks:
>
>
>
> > On Dec 17, 10:00 pm, Brendan Miller  wrote:
> >> On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano
>
> >>  wrote:
> >>> On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote:
>  I was thinking it would be cool to make python more usable in
>  programming competitions by giving it its own port of the STL's
>  algorithm library, which needs something along the lines of C++'s more
>  powerful iterators.
> >>> For the benefit of those of us who aren't C++ programmers, what do its
> >>> iterators do that Python's don't?
> >> Python iterators basically only have one operation:
>
> >> next(), which returns the next element or throws StopIteration.
>
> >> In C++ terminology this is a Input iterator. It is good for writing
> >> "for each" loops or map reduce operations.
>
> > Hmm.  I guess the main thing that's bothering me about this whole
> > thread is that the true power of Python iterators is being overlooked
> > here, and I don't think you're being fair to call Python iterators
> > "weak" (as you did in another thread) or say that they are only good
> > for for-else type loops.
>
> > The fact is, Python iterators have a whole range of powers that C++
> > iterators do not.  C++ iterators, at least the ones that come in STL,
> > are limited to iterating over pre-existing data structures.  Python
> > iterators don't have this limation--the data being "iterated" over can
> > be virtual data like an infinite list, or data generated on the fly.
> > This can be very powerful.
>
> It's good that Python iterators can do things.
>
> However, it's not the case that C++ iterators can't do those things.
>
> C++ iterators very much routinely do such things.

STL Iterators?  No.  Maybe if you're talking about boost or homemade
iterators or something I could buy it, though I'd still bs suspicious
of "routinely".


> However, C++ iterators are flawed in a way that Python iterators are not.
>
> You might say, in an analogy with control structures, that this flaw gives C++
> iterators the power of "goto" but also with all the negative baggage...

That too.


> I'm too lazy to Google, but you might search for Alexandrescu and "ranges", 
> and
> possibly throw in "iterators" among the search terms.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Design question about pretree classifier

[Julian]

On 18 Dez., 18:59, Steve Holden  wrote:
> Julian wrote:
> > Hello,
>
> > I've got a design problem for a classifier. To make it short: it maps
> > strings on strings.
>
> > Some strings have exactly one classification, some none and some more
> > than one.
>
> > There's a method classify(self, word) wich classifies a word. For the
> > first case there's no problem:
>
> > - one classification: return the value (it's a string)
>
> > But:
>
> > - none classification: return an exception or None? I think None is
> > better, hence its not an exception that there is no classification but
> > a defined state. What do you think?
> > - many classifications: what to do? retun a sequence of strings? raise
> > an exception and implement another method wich returns than the
> > classifications? what should I do here?
>
> > thanks for your answers!
>
> Always return a list or tuple. For no classifications it should be
> empty, for one classification it should have one element, ... , for N
> classifications it should have N elements.
>

thanks, sounds simple and good!

> regards
>  Steve
> --
> Steve Holden           +1 571 484 6266   +1 800 494 3119
> Holden Web LLC                http://www.holdenweb.com/
> UPCOMING EVENTS:        http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Lie Ryan]

On 12/18/2009 7:07 AM, Brendan Miller wrote:

As for copying pointers not taking much time... that depends on how
long the list is. if you are working with small sets of data, you can
do almost anything and it will be efficient. However, if you have
megabytes or gigabytes of data (say you are working with images or
video), than the difference between an O(1) or an O(n) operation is a
big deal.


A 1-million member list takes ~130 msec, 10 million 1.3s. In many cases 
the algorithm would easily dwarf the copying itself.

--
http://mail.python.org/mailman/listinfo/python-list

Creating Classes

[seafoid]

Hey Guys,

I have started to read over classes as a brief respite from my parsing
problem.

When a class is defined, how does the class access the data upon which the
class should act?

Example:

class Seq:

def __init__(self, data, alphabet = Alphabet.generic_alphabet):
self.data = data 
self.alphabet = alphabet

def tostring(self):   
return self.data  

def tomutable(self):
return MutableSeq(self.data, self.alphabet)

def count(self, item):
return len([x for x in self.data if x == item])

I know what it should do, but have no idea how to feed it the data.

Methinks I need to invest in actual computing books as learning from
biologists is hazy!

Kind regards,
Seafoid.
  
-- 
View this message in context: 
http://old.nabble.com/Creating-Classes-tp26848375p26848375.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help with invoking standard mail app in windows

[Kev Dwyer]

On Sat, 19 Dec 2009 04:56:34 +1100, Astan Chee wrote:

> Hi,
> I don't know if my last mail made it or not but here it is again. I'm
> trying to launch standard mail app in windows and after looking around
> most look like this:
> 
> import urllib, webbrowser, win32api
> def mailto_url(to=None,subject=None,body=None,cc=None):
> """
> encodes the content as a mailto link as described on
> http://www.faqs.org/rfcs/rfc2368.html """
> url = "mailto: " + urllib.quote(to.strip(),"@,") sep = "?"
> if cc:
> url+= sep + "cc=" + urllib.quote(cc,"@,") sep = "&"
> if subject:
> url+= sep + "subject=" + urllib.quote(subject,"") sep = "&"
> if body:
> # Also note that line breaks in the body of a message MUST be #
> encoded with "%0D%0A". (RFC 2368)
> body="\r\n".join(body.splitlines())
> url+= sep + "body=" + urllib.quote(body,"") sep = "&"
> return url
> 
> url = mailto_url(txtTo,txtSubject,body,txtCC) #
> win32api.ShellExecute(0,'open',url,None,None,0)
> webbrowser.open(url,new=1)
> # os.startfile(url)
> 
> all of these are having "WindowsError : [Error 5] Access is denied"
> errors. I'm using windows xp and python 2.5. I have outlook 2007
> installed as a default mail client. Clicking on any mailto links in html
> brings up the normal write mail from the mail client. Any ideas why this
> is happening or how do I debug what access is being denied? Thanks for
> any help
> Astan

Hello Astan,

Your code executes without error for me on Win98 (!) with Python 2.5 or 
XP with Python 2.6.  

It would help people to help you if you could provide the *exact* console 
output from when you try to execute the code, *including* the traceback.  
That way we can work out which line of code is hitting the exception.

Cheers,

Kev

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Alf P. Steinbach]

* Carl Banks:

On Dec 17, 10:00 pm, Brendan Miller  wrote:

On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano

 wrote:

On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote:

I was thinking it would be cool to make python more usable in
programming competitions by giving it its own port of the STL's
algorithm library, which needs something along the lines of C++'s more
powerful iterators.

For the benefit of those of us who aren't C++ programmers, what do its
iterators do that Python's don't?

Python iterators basically only have one operation:

next(), which returns the next element or throws StopIteration.

In C++ terminology this is a Input iterator. It is good for writing
"for each" loops or map reduce operations.


Hmm.  I guess the main thing that's bothering me about this whole
thread is that the true power of Python iterators is being overlooked
here, and I don't think you're being fair to call Python iterators
"weak" (as you did in another thread) or say that they are only good
for for-else type loops.

The fact is, Python iterators have a whole range of powers that C++
iterators do not.  C++ iterators, at least the ones that come in STL,
are limited to iterating over pre-existing data structures.  Python
iterators don't have this limation--the data being "iterated" over can
be virtual data like an infinite list, or data generated on the fly.
This can be very powerful.


It's good that Python iterators can do things.

However, it's not the case that C++ iterators can't do those things.

C++ iterators very much routinely do such things.

However, C++ iterators are flawed in a way that Python iterators are not.

You might say, in an analogy with control structures, that this flaw gives C++ 
iterators the power of "goto" but also with all the negative baggage...


I'm too lazy to Google, but you might search for Alexandrescu and "ranges", and 
possibly throw in "iterators" among the search terms.



Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess.Popen and ordering writes to stdout and stderr

[Lie Ryan]

On 12/18/2009 8:15 AM, Chris Withers wrote:


the order of the writes isn't preserved.
How can I get this to be the case?



You'll need to flush the std{out|err} or set them unbuffered; or you can 
just forget about relying on std{out|err} being ordered per write-order.

--
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[sturlamolden]

On 17 Des, 18:37, Carlos Grohmann  wrote:

> Tenting the time spent by each approach (using time.clock()), with a
> file with about 100,000 entries, I get 0.03s for the loop and 0.05s
> for the listcomp.
>
> thoughts?

Let me ask a retoric question:

- How much do you really value 20 ms of CPU time?






-- 
http://mail.python.org/mailman/listinfo/python-list

How Do I...?

[Victor Subervi]

Hi;
I have this code:

i = 0
nameNos = []
nos = []
for option in ourOptions():
  nameNos.append('optionNo%d' % i)
  nos.append(i)
  i += 1

The idea is that through every iteration of option, I can create a new
variable such as 'optionNo0', 'optionNo1' etc and assign values such as '0',
'1' etc to them. Of course that code doesn't work. What would?
TIA,
Victor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[Carl Banks]

On Dec 17, 9:37 am, Carlos Grohmann  wrote:
> Tenting the time spent by each approach (using time.clock()), with a
> file with about 100,000 entries, I get 0.03s for the loop and 0.05s
> for the listcomp.
>
> thoughts?

You shouldn't trust your intuition in things like this.  Some features
were added to Python to make writing easier, not to make it run
faster.  This time your intuition was correct.  Next time, who knows?


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[sturlamolden]

On 17 Des, 18:42, "Alf P. Steinbach"  wrote:

> Have you tried this with
>
>    dip1 = [dp - 0.01 if dp == 90 else dp for dp in dipList]

And for comparison with map:

map(lambda dp: dp - 0.01 if dp == 90 else dp, dipList)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shouldn't list comprehension be faster than for loops?

[sturlamolden]

On 17 Des, 18:37, Carlos Grohmann  wrote:

> Tenting the time spent by each approach (using time.clock()), with a
> file with about 100,000 entries, I get 0.03s for the loop and 0.05s
> for the listcomp.
>
> thoughts?

Anything else being equal, list comprehensions will be the faster
becuase they incur fewer name and attribute lookups. It will be the
same as the difference between a for loop and a call to map. A list
comprehension is basically an enhancement of map.





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to create a docstring for a module?

[Albert van der Horst]

In article ,
alex23   wrote:
>"Phillip M. Feldman"  wrote:
>> It does seem as though IPython could be a bit more clever about this. =A0
>
>I disagree. I _like_ that IPython is only reporting on the current
>state of the interpreter and not trying to second guess what I meant.
>
>> If the user asks for documentation on xyz via "?xyz" and xyz is not
>> defined, then I'd like to see IPython check for a module named "xyz" and
>> if it exists, extract and display the docstring.
>
>How would you recommend IPython distinguish between which "xyz" you
>meant: the one in site-packages, the one in some package on the python
>path, or the one in the folder you're running IPython from?

Alternatively, it could state that "xyz" is not loaded, but could be
loaded from one of the places you summarize.
(Kind of what Ubuntu does: hack?, I have no "hack" but such command
could be installed from BSD classical games. )

Groetjes Albert.

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: iterators and views of lists

[Carl Banks]

On Dec 17, 10:00 pm, Brendan Miller  wrote:
> On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano
>
>  wrote:
> > On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote:
>
> >> I was thinking it would be cool to make python more usable in
> >> programming competitions by giving it its own port of the STL's
> >> algorithm library, which needs something along the lines of C++'s more
> >> powerful iterators.
>
> > For the benefit of those of us who aren't C++ programmers, what do its
> > iterators do that Python's don't?
>
> Python iterators basically only have one operation:
>
> next(), which returns the next element or throws StopIteration.
>
> In C++ terminology this is a Input iterator. It is good for writing
> "for each" loops or map reduce operations.

Hmm.  I guess the main thing that's bothering me about this whole
thread is that the true power of Python iterators is being overlooked
here, and I don't think you're being fair to call Python iterators
"weak" (as you did in another thread) or say that they are only good
for for-else type loops.

The fact is, Python iterators have a whole range of powers that C++
iterators do not.  C++ iterators, at least the ones that come in STL,
are limited to iterating over pre-existing data structures.  Python
iterators don't have this limation--the data being "iterated" over can
be virtual data like an infinite list, or data generated on the fly.
This can be very powerful.

Here's a cool slideshow on what can be done with iterators in Python
(generators specifically):

http://www.dabeaz.com/generators/

It is true that Python iterators can't be used to mutate the
underlying structure--if there is actual underlying data structure--
but it doesn't mean they are weak or limited.  Python and C++
iterators are similar in their most basic usage, but grow more
powerful in different directions.



Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[Rory Campbell-Lange]

On 18/12/09, seafoid (fitzp...@tcd.ie) wrote:
> Have you any suggestions how I may render this code undead or should I scrap
> it and create something new?

It might be easier for us to help you if you give us an example of your
input file and a clearer description of what you are trying to do with
the output from your programme.

-- 
Rory Campbell-Lange
r...@campbell-lange.net

Campbell-Lange Workshop
www.campbell-lange.net
0207 6311 555
3 Tottenham Street London W1T 2AF
Registered in England No. 04551928
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Lie Ryan]

On 12/19/2009 4:59 AM, Alan G Isaac wrote:

On 12/18/2009 12:17 PM, MRAB wrote:

In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.



Of course that "conversion" is needed in the replacement.
But e.g. Vim substitutions handle this fine without the
odd (to non perlers) handling of backslashes in replacement.

Alan Isaac


Short answer: Python is not Perl, Python's re.sub is not Vim's :s.

Slightly longer answer: Different environments have different need; 
vim-ers more often needs to escape with just a plain text. All in all, 
the decision for default behaviors are often made so that less backslash 
will be needed for the more common case in the particular environment.

--
http://mail.python.org/mailman/listinfo/python-list

Using PyImport_ExtendInittab with package

[Julien Danjou]

Hi,

I'm trying to embed Python and therefore use PyImport_ExtendInittab() to
register modules.
My current problem is that, if it works well with a simple module
"hello", naming a module "hello.foobar" in the inittab struct does not
seems to work.
imp.find_module("hello.foobar") returns correctly that the module is
found, but import hello.foobar fails badly.

Is . notation supported in inittab? Am I doing something wrong?

-- 
Julien Danjou
// ᐰhttp://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Don't give up.


signature.asc
Description: Digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[seafoid]

Hi Guys,

It has been point out that it is difficult for anyone to provide suggestions
if I do not outline more clearly my input file and an example of what I wish
to do with it (Thanks Rory!).

I mentioned it in this thread (Is creating different threads bad etiquette?
If so, lesson learned!):

http://old.nabble.com/Parsing-file-format-to-ensure-file-meets-criteria-to26837682.html

Hope you guys may have some suggestions as I am stumped!

Thanks,
Seafoid :-)

seafoid wrote:
> 
> Hi Guys,
> 
> When python reads in a file, can lines be referred to via an index?
> 
> Example:
> 
> for line in file:
>  if line[0] == '0':
>  a.write(line)
> 
> This works, however, I am unsure if line[0] refers only to the first line
> or the first character in all lines.
> 
> Is there an easy way to refer to a line with the first character being a
> single letter that you know?
> 
> Thanks in advance,
> Seafoid.
> 

-- 
View this message in context: 
http://old.nabble.com/Line-indexing-in-Python-tp26845253p26847598.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[Lie Ryan]

On 12/19/2009 4:33 AM, seafoid wrote:


Thanks for that Lie.

I had to have a think about what you meant when you referred to control
going to a.write(line).


and if-elif-elif-... chain is executed sequentially and when a match is 
found, the rest of the chain is skipped. Your code:


if line.startswith("0"):
# BLOCK 1 #
elif line.endswith("0"):
# BLOCK 2 #
elif line.startswith("0"):
# BLOCK 3 #

BLOCK 3 never gets executed, since if line.startswith("0") is true, your 
BLOCK 1 is executed and the rest of the if-elif chain is skipped.




Have you any suggestions how I may render this code undead or should I scrap
it and create something new?


I still don't get what you want to do with the code, but to make it not 
dead you can either:


for line in blah:
if line.startswith("0"):
a.write(line)
lists_b = line.strip().split()
print lists_b
elif line.endswith("0"):
lists_a = line.strip().split()
print lists_a

or this:

for line in blah:
if line.startswith("0"):
a.write(line)
if line.endswith("0"):
lists_a = line.strip().split()
print lists_a
elif line.startswith("0"):
lists_b = line.strip().split()
print lists_b

depending on which one seems more readable to you.


My confusion and ineptitude is perhaps explained by my being a biologist :-(

Thanks,
Seafoid.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Another MySQL Problem

[John Nagle]

MRAB wrote:

Victor Subervi wrote:

Hi;

mysql> truncate tem126072414516;
Query OK, 0 rows affected (0.00 sec)

Then I run a script:

  if whatDo == 'insert':
try:
  sql = 'insert into %s (ProdID, Quantity) values ("%s", "%s");' % 
(tmpTable, prodid, quantity)

  print sql
  cursor.execute(sql)


 Don't put values into an SQL statement using the "%" operator.  It doesn't
do SQL escapes and allows SQL injection attacks.

 Try something more like this (assuming that tmpTable does NOT come
from external input, which would be very risky).

cursor = db.cursor()## create cursor
sql = 'insert into ' + tmpTable + ' (ProdID, Quantity) values (%s,%s);'
values = (prodid, quantity) ## values to insert
print sql
cursor.execute(sql, values) ## let SQL do the substitution
db.commit() ## commit transaction



1. The table names look different.
2. Did you commit the changes?


That, too.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Alf P. Steinbach]

I finally finished (draft), I believe!, chapter 2...

Chapter 1 gets the reader up & running, i.e. it's "Hello, world!", basic tool 
usage, without discussing anything about programming really. One reaction to 
this chapter, based on the two example programs in it, was that it wasn't 
gradual and slow enough; hey, those examples are far too advanced, and 
unexplained! But that reader misunderstood: the progression is actually *slower* 
than one might expect. This chapter is only about tool usage. I.e., it's about 
getting those programs running, for the reader who can't rely on teachers or 
fellow students or, as Kernighan & Ritchie put it, "your local guru" (IIRC).


Chapter 2 is about Basic Concepts (of programming). It's the usual: variables, 
basic types and arrays, loops, decision, routines, classes, events, although not 
presented in that order. I make heavy use of complete, concrete examples, many 
of them graphical, and everything is in support of what's actually needed for 
such concrete examples. The intent is to enable the reader to experiment and try 
things out  --  since the only way to really learn is by doing! As best I could 
I've labored to apply this minimalism also to the Python language, using only a 
"minimal" subset (to the degree of not even introducing boolean ops :-) ).


Chapter 3 will, by my current plan, delve into the Python language and such 
things as how integers and floating point works on the inside, and that includes 
those in chapter 2 not even mentioned boolean operations. One important issue, 
introducing exceptions, and in support of that, type hierarchies. After chapter 
3 I have only much vaguer notions about what to introduce in what order, but a 
main issue, assuming that I go on with this writing, will be to apply and teach 
methodology all the way, integrated into the examples and text.


A table of contents + chapters 1 and 2 is available in PDF format at Google 
Docs, at

  http://tinyurl.com/programmingbookP3>

Comments are very welcome!

Re comments: there are two deviations from current Python practice in chapter 2. 
First, that I use spaces inside argument parentheses, which makes the code more 
readable when one gets used/trained to it because it gives the eye more direct 
information (with some training visual structure can be processed unconsciously 
& effortlessly, but purely logical structure has to be processed analytically). 
The second deviation is that since most names are constants, I do not follow PEP 
8's recommendation to use uppercase names of constants. In fact almost no Python 
code does, but then it seems that people are not aware of how many of their 
names are constants and think that they're uppercasing constants when in fact 
they're not. E.g. routine arguments and in particular routine names are usually 
constants, absolutely not meant to be modified, but it would be silly to UC...


So both these two deviations from Python practice are /intentional/, since this 
is a book about programming, not about Python the language & how to conform to 
idiosyncratic language-specific conventions.


But, if there are other deviations from Python practice I'd be very glad to hear 
of it! I'm very hopeful that any such convention deviations can be fixed. :-)



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] pylint 0.19 / astng 0.19.2

[David Robinow]

On Fri, Dec 18, 2009 at 12:49 PM, Jean-Michel Pichavant
 wrote:
> Jerry Hill wrote:
>>
>> On Fri, Dec 18, 2009 at 12:24 PM, Jean-Michel Pichavant >  File
>>> "/opt/tools/python/python2.3/site-packages/logilab_astng-0.19.2-py2.5.egg/logilab/astng/infutils.py",
>>> line 28, in 
>>>  from logilab.astng._nodes import Proxy_, List, Tuple, Function, If,
>>> TryExcept
>>> ImportError: No module named _nodes
>>>

It works for me (but I'm running cygwin)
You should have a file
/opt/tools/python/python2.3/site-packages/logilab_astng-0.19.2-py2.5.egg/logilab/astng/_nodes.py

Does it exist? If not, reinstall logilab_astng-0.19.2
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Design question about pretree classifier

[Steve Holden]

Julian wrote:
> Hello,
> 
> I've got a design problem for a classifier. To make it short: it maps
> strings on strings.
> 
> Some strings have exactly one classification, some none and some more
> than one.
> 
> There's a method classify(self, word) wich classifies a word. For the
> first case there's no problem:
> 
> - one classification: return the value (it's a string)
> 
> But:
> 
> - none classification: return an exception or None? I think None is
> better, hence its not an exception that there is no classification but
> a defined state. What do you think?
> - many classifications: what to do? retun a sequence of strings? raise
> an exception and implement another method wich returns than the
> classifications? what should I do here?
> 
> thanks for your answers!

Always return a list or tuple. For no classifications it should be
empty, for one classification it should have one element, ... , for N
classifications it should have N elements.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Alan G Isaac]

On 12/18/2009 12:17 PM, MRAB wrote:

In simple cases you might be replacing with the same string every time,
but other cases you might want the replacement to contain substrings
captured by the regex.



Of course that "conversion" is needed in the replacement.
But e.g. Vim substitutions handle this fine without the
odd (to non perlers) handling of backslashes in replacement.

Alan Isaac

--
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Alan G Isaac]

On 12/17/2009 7:59 PM, Rhodri James wrote:

"re.compile('a\\nc')" passes a sequence of four characters to
re.compile: 'a', '\', 'n' and 'c'.  re.compile() then does it's own
interpretation: 'a' passes through as is, '\' flags an escape which
combined with 'n' produces the newline character (0x0a), and 'c' passes
through as is.



I got that from MRAB's posts. (Thanks.)
What I'm not getting is why the replacement string
gets this particular interpretation.  What is the payoff?
(Contrast e.g. Vim's substitution syntax.)

Thanks,
Alan

--
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] pylint 0.19 / astng 0.19.2

[Sylvain Thénault]

On 18 décembre 18:24, Jean-Michel Pichavant wrote:
> Sylvain Thénault wrote:
> >Hi,
> >
> >I'm very pleased to announce the release of pylint 0.19 / astng 0.19.2 
> >release!
> >
> >More information / download  on http://www.logilab.org/project/pylint/0.19.0.
> >
> >This is a "community" release, including the work we've done during the 
> >pylint
> >bug day [1] and patches mostly from James Lingard and Vincent Ferotin.
> >
> >Many thanks to James Lingard which provided two long waited features:
> >
> >* check of function call arguments
> >* check string interpolation consistency
> >
> >
> >So, happy christmas, enjoy!
> >
> >[1] http://www.logilab.org/blogentry/19260
> I have troubles after updating pylint:
> 
> easy_install pylint -U --install-dir
> /opt/tools/python/python2.3/site-packages
> 
> > pylint
> 
>  File 
> "/opt/tools/python/python2.3/site-packages/logilab_astng-0.19.2-py2.5.egg/logilab/astng/infutils.py",
> line 28, in 
>from logilab.astng._nodes import Proxy_, List, Tuple, Function,
> If, TryExcept
> ImportError: No module named _nodes
> 
> There is no _nodes.py file within the egg. Has anyone experienced
> the same issue ?

yep someone else on the list have the same pb. I think I've identified it:

  python setup.py register sdist upload

*doesn't* regenerate MANIFEST if one is found... So packages uploaded to pypi 
had some missing files. Should be fixed now, sorry for this pb.
-- 
Sylvain Thénault   LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:   http://www.logilab.fr/services
CubicWeb, the semantic web framework:http://www.cubicweb.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Help with invoking standard mail app in windows

[Astan Chee]

Hi,
I don't know if my last mail made it or not but here it is again.
I'm trying to launch standard mail app in windows and after looking 
around most look like this:


import urllib, webbrowser, win32api
def mailto_url(to=None,subject=None,body=None,cc=None):
   """
   encodes the content as a mailto link as described on
   http://www.faqs.org/rfcs/rfc2368.html
   """
   url = "mailto: " + urllib.quote(to.strip(),"@,")
   sep = "?"
   if cc:
   url+= sep + "cc=" + urllib.quote(cc,"@,")
   sep = "&"
   if subject:
   url+= sep + "subject=" + urllib.quote(subject,"")
   sep = "&"
   if body:
   # Also note that line breaks in the body of a message MUST be
   # encoded with "%0D%0A". (RFC 2368)
   body="\r\n".join(body.splitlines())
   url+= sep + "body=" + urllib.quote(body,"")
   sep = "&"
   return url

url = mailto_url(txtTo,txtSubject,body,txtCC)
# win32api.ShellExecute(0,'open',url,None,None,0)
webbrowser.open(url,new=1)
# os.startfile(url)

all of these are having "WindowsError : [Error 5] Access is denied" 
errors. I'm using windows xp and python 2.5. I have outlook 2007 
installed as a default mail client. Clicking on any mailto links in html 
brings up the normal write mail from the mail client. Any ideas why this 
is happening or how do I debug what access is being denied?

Thanks for any help
Astan

--
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] pylint 0.19 / astng 0.19.2

[Jean-Michel Pichavant]

Jerry Hill wrote:

On Fri, Dec 18, 2009 at 12:24 PM, Jean-Michel Pichavant >  File
  

"/opt/tools/python/python2.3/site-packages/logilab_astng-0.19.2-py2.5.egg/logilab/astng/infutils.py",
line 28, in 
  from logilab.astng._nodes import Proxy_, List, Tuple, Function, If,
TryExcept
ImportError: No module named _nodes



You're installing the wrong version of logilab.  That's the python 2.5
version, judging by the name of the egg.  I'm not sure how
easy_install decides which version of python to install for, but it's
definitely picking the wrong one here.

  

well, according this mail title, astng 0.19.2 is the correct one.

I should have mentioned /opt/tools/python/python2.3/ is a network drive 
where we install 3rd party modules. It is still named python2.3 but this 
is in fact totally irrelevant (we're the kind of lazy guys).

Python 2.5 is the one installed on my system so easy_install guess is right.

Or maybe you suggested that pylint is no more compatible with python2.5 ?

JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: imports in __init__.py

[Peter Otten]

Phil wrote:

> I wrote my last message late last night. When I said "I am unable to
> import a module from the package without an import error.", I did mean
> the 'modulename' module.
> 
> However, I just set up a Debian VM with Python 2.5.2 and what I was
> trying to do works. So it is either something that changed with Python
> 3.1.1, or a problem with Windows.

In Python 3.x absolute import is on by default. Change

from application import *

to

from .application import *

to indicate that the application module is located within the current 
package.

Peter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Line indexing in Python

[seafoid]

Thanks for that Lie.

I had to have a think about what you meant when you referred to control
going to a.write(line).

Have you any suggestions how I may render this code undead or should I scrap
it and create something new?

My confusion and ineptitude is perhaps explained by my being a biologist :-(

Thanks,
Seafoid.
-- 
View this message in context: 
http://old.nabble.com/Line-indexing-in-Python-tp26845253p26846854.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] pylint 0.19 / astng 0.19.2

[Jerry Hill]

On Fri, Dec 18, 2009 at 12:24 PM, Jean-Michel Pichavant >  File
> "/opt/tools/python/python2.3/site-packages/logilab_astng-0.19.2-py2.5.egg/logilab/astng/infutils.py",
> line 28, in 
>   from logilab.astng._nodes import Proxy_, List, Tuple, Function, If,
> TryExcept
> ImportError: No module named _nodes

You're installing the wrong version of logilab.  That's the python 2.5
version, judging by the name of the egg.  I'm not sure how
easy_install decides which version of python to install for, but it's
definitely picking the wrong one here.

-- 
Jerry
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: share dictionary between processes

[Steve Holden]

blumenkraft wrote:
> Hi,
> 
> I want to share dictionary between two distinct processes.
> 
> 
> Something like this:
> 
> first.py
> import magic_share_module
> 
> def create_dictionary():
> return {"a": 1}
> 
> magic_share_module.share("shared_dictionary",
> creator.create_dictionary)
> while True:
>  pass
> 
> 
> second.py
> import magic_share_module
> d = magic_share_module.get_shared("shared_dictionary")
> print d["a"]
> 
> And then run in command line:
> python first.py &
> sleep 1
> python second.py
> 
> I have looked at POSH, but it requires master process that will fork
> childs. I want read-only sharing between completely unrelated
> processes.
> Is it possible?

Take a look at pyro, though it may be overkill for your needs.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list