Re: unittest for system testing

[Steven D'Aprano]

Sorry for breaking threading, but the original post has not come through 
to me.

> On 18/10/2012 01:22, Rita wrote:
> Hi,
>
> Currently, I use a shell script to test how my system behaves before I
> deploy an application. For instance, I check if fileA, fileB, and fileC
> exist and if they do I go and start up my application.

Do you run the shell script once, before installing the application, or 
every time the application launches?

Do you realise that this is vulnerable to race conditions? E.g:

Time = 10am exactly: shell script runs, fileA etc exist;

Time = 10am and 1 millisecond: another process deletes fileA etc;

Time = 10am and 2 milliseconds: application launches, cannot find 
   fileA etc and crashes.


Depending on what your application does, this could be a security hole.

Regardless of what the shell script reports, to be robust your Python 
application needs to protect against the case that fileA etc are missing. 
Even if all it does is report an error, save the user's work and exit.


> This works great BUT
>
> I would like to use python and in particular unittest module to test my
> system and then deploy my app. I understand unittest is for functional
> testing but I think this too would be a case for it. Any thoughts? I am
> not looking for code in particular but just some ideas on how to use
> python better in situations like this.

Well, you *could* use unittest, but frankly I think that's a case of 
using a hammer to nail in screws. Unittest is awesome for what it does. 
It's not so well suited for this.

Compare these two pieces of code (untested, so they probably won't work 
exactly as given):

# sample 1
import os
import sys
for name in ['fileA', 'fileB', 'fileC']:
if not os.path.exists(name):
print('missing essential file %s' % name)
sys.exit(1)

run_application()



# sample 2
import os
import sys
import unittest

class PreRunTest(unittest.TestCase):
list_of_files = ['fileA', 'fileB', 'fileC']
def testFilesExist(self):
for name in self.list_of_files:
assertTrue(os.path.exists(name)

total_tests, failed_tests = unittest.testmod()  # I think...

if failed_tests != 0:
sys.exit(1)

run_application()



I think the first sample is much to be preferred, and not just because it 
is a couple of lines shorter. There's less magic involved.


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

Re: A desperate lunge for on-topic-ness

[rusi]

On Oct 18, 11:06 am, Zero Piraeus  wrote:
> :
>
> Okay, so, first thing vaguely Python-related that comes to mind [so
> probably not even slightly original, but then that's not really the
> point]:
>
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

It really depends on whether one is programming for learning, as a
profession or publicly (as on this list).

The third is necessary to say because mailers are going to break long
lines.
As for the other two, there is a distinction because:
For example, a candidate C-programmer would be expected to show
prowess with pointers in an interview that would be frowned upon when
he professionally develops in C for production.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Paul Rubin]

Zero Piraeus  writes:
> 2. Say "screw it" and break the line using a backslash.

Often the line will break ok without a backslash, but I don't feel any
particular pain in using a backslash in the other cases.

I do pretty rigorously try to keep all lines shorter than 72 columns or
so, unless there's a long literal like a url.  Even such a literal would
probably only occur in throwaway code.  Any specific url in
longer-lasting code should probably be read from a configuration file
rather than being hard coded.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Zero Piraeus]

:

On 18 October 2012 02:19, rusi  wrote:
> I understood that your original post started after Etienne's outburst
> against Steven.

Ah, I see. It was intended as a general request for politeness, but
yes, IIRC that was the exchange that prompted it.

> IOW the robustness principle http://en.wikipedia.org/wiki/Robustness_principle
> is as good for human networking as for computers.

Never thought of it as applying to humans ... that's rather good. Not
universally applicable, but then neither is it for computers.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

python scripts for web

[chip9munk]

Hello all!

Please help me start learning about this thing. Sorry for my inexperience!

Here is what I need to do: on some webpage (done in php, or any other different 
technology), user inputs some data, that data and the request then goes to the 
server where python scripts calculate something and return the result to the 
users end. 

Now, how do I do that server part, listening to requests, and calling python 
scripts?

I googled about that but I do not understand if I should do that by CGI, Flask, 
mod_wsgi, or any other way... I know to little about that to understand what is 
the way to go. :/

Please could you give me some info so that i know where I should start looking 
for my solution.

Thanks in advance!



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

Re: Aggressive language on python-list

[rusi]

On Oct 18, 11:27 am, David Hutto  wrote:
> > [BTW This was enunciated 2000 years ago by a clever chap: Love your
> > enemies; drive them crazy
>
> That only works if they're not already insane.
> Otherwise you're just prodding a cornered beast.

Usually but not necessarily
http://en.wikipedia.org/wiki/Angulimala#Story
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[Zero Piraeus]

:

On 18 October 2012 03:18,   wrote:
> Here is what I need to do: on some webpage (done in php, or any other
> different technology), user inputs some data, that data and the
> request then goes to the server where python scripts calculate
> something and return the result to the users end.
>
> Now, how do I do that server part, listening to requests, and calling
> python scripts?

If I understand you correctly, what you're describing here is a
webserver - i.e. Apache, nginx etc. I'm not sure why you'd want to
write one of those if you're as inexperienced as you say.

> I googled about that but I do not understand if I should do that by
> CGI, Flask, mod_wsgi, or any other way... I know to little about that
> to understand what is the way to go. :/

These are all approaches to writing the software that the webserver
hands the request off to, which is a different thing. If that's what
you really meant to ask (how to write a script that processes a
request and returns a response), then plain CGI might be the best
place to start, if you're trying to get a handle on what's going on.

Once you're happy that you understand how to build a plain CGI script,
frameworks [like Flask] can be very useful ... and Flask is both
lightweight and has good documentation, so it's not a bad choice for
learning purposes.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[chip9munk]

To explain, I am basically doing different algorithms and would like to make 
them work and be accessible as I mentioned in the example... and to add them to 
the functionality of a specific page... so I have experience in programming, 
just no experience in web development etc.. 

On Thursday, October 18, 2012 9:57:58 AM UTC+2, Zero Piraeus wrote:
> 
> If I understand you correctly, what you're describing here is a
> webserver - i.e. Apache, nginx etc. I'm not sure why you'd want to
> write one of those if you're as inexperienced as you say.
> These are all approaches to writing the software that the webserver
> hands the request off to, which is a different thing. If that's what
> you really meant to ask (how to write a script that processes a
> request and returns a response), then plain CGI might be the best
> place to start, if you're trying to get a handle on what's going on.

I understand how the lack of knowledge on my part can cause the unclarity of my 
question.
I will give you an example. So let us say I create two simple python scripts, 
one does the sum of two numbers
the other one does the multiplication. SO now I want to put these scripts on 
the server. Now let us say there is a web page that would like to use these 
scripts (do this calculation). How do I do a "program" that will listen for the 
requests
from the web page and call the scripts on the request?  
 
> Once you're happy that you understand how to build a plain CGI script,
> frameworks [like Flask] can be very useful ... and Flask is both
> lightweight and has good documentation, so it's not a bad choice for
> learning purposes.

all the tutorials about flask are dealing wit creating the whole webpage in 
python. I do not need to do that, I just need a service on the servers end.. is 
flask still the way to go? Also flask does not support Python 3.x jet, would 
using cherryPy be a good idea?

Thank you for the answers! 

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

Re: Change computername

[Anatoli Hristov]

It does not work the result is "0"

And I don't find any documentation about it :(


On Thu, Oct 18, 2012 at 8:41 AM, Anatoli Hristov  wrote:
> Thank you,
>
> I will test this, will keep you posted.
>
> Anatoli
>
> On Wed, Oct 17, 2012 at 7:47 PM, Ian Kelly  wrote:
>> On Wed, Oct 17, 2012 at 8:07 AM, Anatoli Hristov  wrote:
>>> Hello,
>>>
>>> Can you please help me out how can I change the computername of
>>> windows XP with or without the "WIN32" module ?
>>
>> Untested:
>>
>> from ctypes import *
>>
>> ComputerNamePhysicalDnsHostname = 5
>>
>> computer_name = u'COMPUTER'
>>
>> success = windll.kernel32.SetComputerNameExW(ComputerNamePhysicalDnsHostname,
>>  computer_name)
>> if success:
>> print("Name changed")
>> else:
>> print("Failed")
>>
>> The process will need admin rights, and the computer will need to be
>> rebooted before the change will take effect.
>> --
>> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[Zero Piraeus]

:

On 18 October 2012 04:10,   wrote:
> I will give you an example. So let us say I create two simple python
> scripts, one does the sum of two numbers
> the other one does the multiplication. SO now I want to put these
> scripts on the server. Now let us say there is a web page that would
> like to use these scripts (do this calculation). How do I do a
> "program" that will listen for the requests
> from the web page and call the scripts on the request?

That is exactly what a webserver does. Is there some reason you don't
want to use e.g. Apache to handle the requests?

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Hans Mulder]

On 18/10/12 08:31:51, Steven D'Aprano wrote:
> On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:
>> 3. Say "well, at least it's not a backslash" and break the line using
>> > parentheses.
> I mostly do this. Since most lines include a bracket of some sort, I 
> rarely need to add outer parentheses just for the purpose of line 
> continuation.
> 
> some_variable = spam('x') + ham(
> some_longer_variables, here_and_here, 
> and_here_also)

I would spell that as:

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also,
)

> I know PEP 8 says I should drop the final round bracket to the next line, 
> but I don't normally like that.

I normally put the final bracket on the next line, where it is
very visible.  Compare:

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

vs.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here,
and_here_also,
):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

Which one would you say is more readable?


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

Re: A desperate lunge for on-topic-ness

[Mark Lawrence]

On 18/10/2012 07:06, Zero Piraeus wrote:

:

Okay, so, first thing vaguely Python-related that comes to mind [so
probably not even slightly original, but then that's not really the
point]:

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

1. Say "screw it" and go past 79, PEP8 be damned.

2. Say "screw it" and break the line using a backslash.

3. Say "well, at least it's not a backslash" and break the line using
parentheses.

4. Spend 45 minutes trying to think up shorter [but still sensible]
variable names to make it fit.

5. Perform an otherwise pointless assignment to a temp variable on the
previous line to make it fit.

6. Realise that if it's that long, it probably shouldn't have been a
list comprehension in the first place.

Any I've missed? Any preferences?

  -[]z.



I suggest re-reading PEP 8, particularly the section titled "A Foolish 
Consistency is the Hobgoblin of Little Minds" and specifically the first 
sentence of the third paragraph "But most importantly: know when to be 
inconsistent -- sometimes the style guide just doesn't apply."


--
Cheers.

Mark Lawrence.

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

Re: python scripts for web

[chip9munk]

On Thursday, October 18, 2012 10:42:56 AM UTC+2, Zero Piraeus wrote:
> That is exactly what a webserver does. Is there some reason you don't
> want to use e.g. Apache to handle the requests?

no reason at all. so i guess the solution is much easier then I have 
anticipated.
So i guess in that case i do not need cgi or anything?

Thank you for clearing that out!
-- 
http://mail.python.org/mailman/listinfo/python-list

Remove uncide notation

[Ashish Jain]

Hi,

I have a html string in an object, when I do repr() of that object, I get value 
as:

{'Id' : 1, 'Body': u' Hello '}

I don't wish to have 'u' as the character in my string representation. As this 
is not a valid json notation now.

Thanks for your help

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

Re: A desperate lunge for on-topic-ness

[wxjmfauth]

Le jeudi 18 octobre 2012 11:07:25 UTC+2, Hans Mulder a écrit :
> On 18/10/12 08:31:51, Steven D'Aprano wrote:
> 
> > On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:
> 
> >> 3. Say "well, at least it's not a backslash" and break the line using
> 
> >> > parentheses.
> 
> > I mostly do this. Since most lines include a bracket of some sort, I 
> 
> > rarely need to add outer parentheses just for the purpose of line 
> 
> > continuation.
> 
> > 
> 
> > some_variable = spam('x') + ham(
> 
> > some_longer_variables, here_and_here, 
> 
> > and_here_also)
> 
> 
> 
> I would spell that as:
> 
> 
> 
> some_variable = spam('x') + ham(
> 
> some_longer_variables,
> 
> here_and_here,
> 
> and_here_also,
> 
> )
> 
> 
> 
> > I know PEP 8 says I should drop the final round bracket to the next line, 
> 
> > but I don't normally like that.
> 
> 
> 
> I normally put the final bracket on the next line, where it is
> 
> very visible.  Compare:
> 
> 
> 
> if looks_like_it_might_be_spam(
> 
> some_longer_variables,
> 
> here_and_here, and_here_also):
> 
> logger.notice("might be spam")
> 
> move_to_spam_folder(some_longer_variables)
> 
> update_spam_statistics(here_and_here)
> 
> 
> 
> vs.
> 
> 
> 
> if looks_like_it_might_be_spam(
> 
> some_longer_variables,
> 
> here_and_here,
> 
> and_here_also,
> 
> ):
> 
> logger.notice("might be spam")
> 
> move_to_spam_folder(some_longer_variables)
> 
> update_spam_statistics(here_and_here)
> 
> 
> 
> Which one would you say is more readable?
> 
> 
> 
> 
> 
> -- HansM

I use a "double indentation".

>>> if 'asdf' and 'asdf' and 'asdf' \
... 'asdf' and 'asdf' and \
... 'asdf' and 'asdf':
... print('do if')
... s = 'asdf'
... ss = 'asdf'
... 
do if
>>> if looks_like_it_might_be_spam(
... some_longer_variables,
... here_and_here, and_here_also):
... logger.notice("might be spam")
... move_to_spam_folder(some_longer_variables)
... update_spam_statistics(here_and_here)
... 
Traceback (most recent call last):

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

Re: Remove uncide notation

[Chris Rebert]

On Thu, Oct 18, 2012 at 2:27 AM, Ashish Jain  wrote:
> Hi,
>
> I have a html string in an object, when I do repr() of that object, I get 
> value as:
>
> {'Id' : 1, 'Body': u' Hello '}
>
> I don't wish to have 'u' as the character in my string representation. As 
> this is not a valid json notation now.

If you want JSON, then *use the freakin' `json` std lib module*!
http://docs.python.org/library/json.html

repr(...) != JSON
[It's similar only coincidentally, and only to a degree.]

Regards,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Dave Angel]

On 10/18/2012 02:19 AM, rusi wrote:
> 
>
> IOW the robustness principle http://en.wikipedia.org/wiki/Robustness_principle
> is as good for human networking as for computers.
>
>

The catch to that is that the software that is liberally accepting
anything is quite vulnerable to attacks.  Windows has a checksum in the
exe header that's been there since the MSDOS days, and to the best of my
knowledge has never been checked by the loader.  So even accidental file
corruption goes unnoticed.

Likewise IP and other protocol accept all sorts of retries and
fragments, and since different OS's overlay those pieces with differing
rules, it's quite common for different OS's to see different versions of
the packets after reconstruction.  So Intrusion detection software (sort
of like anti-virus) can be fooled.

Goals have changed over the years, and what was a good idea 20 years ago
is pretty painful now.

I suppose the human analogy might be the trusting people who believe any
scammer that comes along.  As for me, I'd rather be sometimes fooled
than never to trust anyone.  So, although I can argue against it, I
pretty much agree with the robustness principle.

-- 

DaveA

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

Re: A desperate lunge for on-topic-ness

[Chris Angelico]

On Thu, Oct 18, 2012 at 8:07 PM, Hans Mulder  wrote:
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here, and_here_also):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
>

This wants different indentation levels for the condition and the
code. That'd make it readable enough.

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

Re: python scripts for web

[Zero Piraeus]

:

On 18 October 2012 05:22,   wrote:
> So i guess in that case i do not need cgi or anything?

Assuming your scripts accept the request as sent and return an
appropriate response, they are CGI scripts (unless there's some
wrinkle in the precise definition of CGI that escapes me right now).

> Thank you for clearing that out!

No bother :-)

By the way: are you using Google Groups? It's just that I'm led to
understand that it's recently started to misbehave [more than it used
to], and your replies are addressed to both
 and ,
which is redundant.

Or perhaps it always did that, and I've never noticed before ...

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Robert Kern]

On 10/18/12 6:43 AM, David Hutto wrote:

On Thu, Oct 18, 2012 at 1:29 AM, Steven D'Aprano
 wrote:

David,

While I acknowledge and appreciate your efforts to be less aggressive on
this list, I think you have crossed a line by forwarding the contents of
an obviously personal email containing CLEARLY PRIVATE MATTERS to a
public list without permission, without even anonymising it.


I get that it was a in a thread, and we;'re always told to respond
all, unless otherwise asked, and they didn't directly ask, so I
responded back to the list like the etiquette dictates.


I know that you have apologized for this later in the email, and I appreciate 
that, but I would like to explicitly state some of the expectations of etiquette 
for this list. I don't mean to chastise excessively.


I'm afraid that you were either misinformed, or you misinterpreted what you were 
told. When someone sends you an email that is *only addressed to you*, you 
should not forward that to the list without getting explicit permission. It is 
possible that someone just forgot to include the list, but it's also quite 
likely that they meant it only for you, particularly when it is of a more 
personal nature. Etiquette dictates that you should not assume that they meant 
to include the list. If you are in doubt, you must ask. This rule trumps others 
if you think there is a conflict in interpretation.


If you do make a private response, it is always a good idea to explicitly state 
so, but the lack of such a statement is not an excuse for the recipient to make 
the email public. The default assumption must be that they meant to send it to 
exactly those people they actually sent it to.


Thank you for listening.

--
Robert Kern

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

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

Re: python scripts for web

[Chris Angelico]

On Thu, Oct 18, 2012 at 8:22 PM,   wrote:
> On Thursday, October 18, 2012 10:42:56 AM UTC+2, Zero Piraeus wrote:
>> That is exactly what a webserver does. Is there some reason you don't
>> want to use e.g. Apache to handle the requests?
>
> no reason at all. so i guess the solution is much easier then I have 
> anticipated.
> So i guess in that case i do not need cgi or anything?
>
> Thank you for clearing that out!

CGI is a protocol between Apache and your script. What you want to do
is set up Apache to call your CGI scripts.

BTW, you don't need to send to both comp.lang.python and python-list -
they mirror each other.

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

Re: Change computername

[Chris Angelico]

On Thu, Oct 18, 2012 at 7:22 PM, Anatoli Hristov  wrote:
> It does not work the result is "0"
>
> And I don't find any documentation about it :(

Microsoft's official documentation can usually be found at the other
end of a web search. In this case:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724931(v=vs.85).aspx

You may need to call GetLastError to find out the actual problem.

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

Re: Remove uncide notation

[Ashish Jain]

On Thursday, 18 October 2012 15:10:33 UTC+5:30, Chris Rebert  wrote:
> On Thu, Oct 18, 2012 at 2:27 AM, Ashish Jain wrote:
> 
> > Hi,
> 
> >
> 
> > I have a html string in an object, when I do repr() of that object, I get 
> > value as:
> 
> >
> 
> > {'Id' : 1, 'Body': u' Hello '}
> 
> >
> 
> > I don't wish to have 'u' as the character in my string representation. As 
> > this is not a valid json notation now.
> 
> 
> 
> If you want JSON, then *use the freakin' `json` std lib module*!
> 
> http://docs.python.org/library/json.html
> 
> 
> 
> repr(...) != JSON
> 
> [It's similar only coincidentally, and only to a degree.]
> 
> 
> 
> Regards,
> 
> Chris

Thanks a lot!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Zero Piraeus]

:

There seems to be a consensus [to the extent there ever is, anyway]
around using parentheses etc., then ...

On 18 October 2012 02:31, Steven D'Aprano
 wrote:
> I've been burnt enough by word-wrapping in editors that don't handle word-
> wrapping that well that it makes me really uncomfortable to go over 78-79
> characters, even by only 1 extra. So I don't like doing this.

I have to admit, I try quite hard not to exceed 78. I don't know why
[never been bitten by badly behaved editors], but something about 79
characters in an 80-char window makes me uncomfortable.

> Just about the only time I go over is if I have a comment that includes a
> URL with more than 78 characters. I hate breaking URLs more than I hate
> breaking the 79 character limit.

Agreed.

> You missed one:
>
> 5a. Perform an assignment to a temp variable that you really should have
> done anyway, but reducing the number of characters in the line was the
> impetus that finally made you act.

Ah. Yes :-)

On 18 October 2012 05:33,   wrote:
> I use a "double indentation".
>
 if 'asdf' and 'asdf' and 'asdf' \
> ... 'asdf' and 'asdf' and \
> ... 'asdf' and 'asdf':
> ... print('do if')
> ... s = 'asdf'
> ... ss = 'asdf'

Actually, I had a follow-up question about indentation planned. I used
to double-indent, but am now more likely to go with e.g.

>>> if check_something(
... arg1,
... arg2,
... arg3
... ):
... do_something()

as others have suggested. An alternative would be something like

>>> if check_something(arg1,
...arg2,
...arg3):
... do_something()

which I like much less. I have to admit, though, that all the original
options make me feel a little dirty except (#4) "shorter variable
names" [which just makes me feel that I am being overly precious] and
(#6 generalised) "this needs refactoring" [which I would say includes
Steven's #5a].

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Tim Chase]

On 10/18/12 04:33, wxjmfa...@gmail.com wrote:
> I use a "double indentation".
> 
 if 'asdf' and 'asdf' and 'asdf' \
> ... 'asdf' and 'asdf' and \
> ... 'asdf' and 'asdf':
> ... print('do if')
> ... s = 'asdf'
> ... ss = 'asdf'
> ... 
> do if
 if looks_like_it_might_be_spam(
> ... some_longer_variables,
> ... here_and_here, and_here_also):
> ... logger.notice("might be spam")
> ... move_to_spam_folder(some_longer_variables)
> ... update_spam_statistics(here_and_here)

I lean towards double-indent as well, though I favor parens/brackets
vs. trailing backslashes.  My conditions usually go one-per-line,
too.  I also tend to put my closing paren+colon on a stand-alone line:

if (
something
or something_else
or yet_other_stuff
):
do_thing1()
do_thing2()

It's not quite as nice with pure parens, working better with
function-calls.  However, it makes my git/svn diffs easier to read
when conditions get added/removed because only that line (usually)
changes, rather than having the noise of the paren moving around.

In 2.5 and later, I like to write that as

if any([
something,
something_else,
yet_other_stuff,
]):
do_thing1()
do_thing2()

where each item is uniform (one trailing comma, rather than one item
being special without a comma/or/and) so I don't have the diff noise
for "or"/"and" bouncing around either.

Making my diffs easy to read is pretty important to me.

-tkc

PS: and in such cases, yes, I often alphabetize my conditions too as
long as the order doesn't matter.  Just a little CDO.  That's OCD,
but in alphabetical order the way the letters should be :-)






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

use of exec()

[lars van gemerden]

I am trying to implement a way to let users give a limited possibility to 
define functions in text, that wille be stored and executed at a later time. I 
use exec() to transform the text to a function. The code is as follows:

class code(str):
def __call__(self, *args):
try:
return self._func_(*args)
except AttributeError:
self._func_ = self._creat_func_()
return self._func_(*args)
def __getstate__(self):
return {}

class _lambdacode(code):
def _creat_func_(self):
return eval("lambda %s: %s" % (", ".join(type(self).args), self),{},{})

class _functioncode(code):
def _creat_func_(self):
exec("def function(%s):\n\t%s" % (", ".join(type(self).args), 
  "\n\t".join(self.split('\n'
return function

def lambdatype(*argnames):
return type('lambdacode', (_lambdacode,),{'args': argnames}) 

def functiontype(*argnames):
return type('functioncode', (_functioncode,),{'args': argnames})

if __name__ == '__main__':
f = lambdatype('a', 'b')('a ** b')
print f
print f(3, 4)
print f(4, 3)

g = functiontype('a', 'b')('a, b = a/b, a*b\nreturn a ** b')
print g
print g(3.0, 4.0) 
print g(4.0, 3.0)

This code works. But if I replace _functioncode with:

class _functioncode(code):
def _creat_func_(self):
exec("def function(%s):\n\t%s" % (", ".join(type(self).args), 
  "\n\t".join(self.split('\n'))),{})
return function

or

class _functioncode(code):
def _creat_func_(self):
exec("def function(%s):\n\t%s" % (", ".join(type(self).args), 
  "\n\t".join(self.split('\n'))),{},{})
return function

to restrict access to global variables, similar to the lambda version, i get 
the error:

Traceback (most recent call last):
  File 
"D:\Documents\Code\Eclipse\workspace\FlowWare_1\toolshed\tests\mini_test.py", 
line 41, in 
print g(3.0, 4.0)
  File 
"D:\Documents\Code\Eclipse\workspace\FlowWare_1\toolshed\tests\mini_test.py", 
line 13, in __call__
self._func_ = self._creat_func_()
  File 
"D:\Documents\Code\Eclipse\workspace\FlowWare_1\toolshed\tests\mini_test.py", 
line 25, in _creat_func_
return function
NameError: name 'function' is not defined

which seems an odd error, but i think some global variable is necessary for 
this to work (if i put in globals() instead of {}, it works).

My question is which variable or if that is not the problem, what is and how 
can i restrict access the user code has.

Cheers, Lars
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: use of exec()

[Chris Angelico]

On Thu, Oct 18, 2012 at 10:41 PM, lars van gemerden
 wrote:
> NameError: name 'function' is not defined
>
> which seems an odd error, but i think some global variable is necessary for 
> this to work (if i put in globals() instead of {}, it works).

The def statement simply adds a name to the current namespace. This
should work (untested):

class _functioncode(code):
def _creat_func_(self):
ns={}
exec("def function(%s):\n\t%s" % (", ".join(type(self).args),
  "\n\t".join(self.split('\n'))),ns,ns)
return ns.function

But it's going to be eternally plagued by security issues. You may
want, instead, to look at literal_eval from the ast module; but that
won't work if you need anything other than, as the name suggests,
literals.

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

[ANN] PyPyODBC 0.8.7 released

[江文]

PyPyODBC - A Pure Python ctypes ODBC module

Features
-Pure Python, compatible with IronPython and PyPy (tested on Win32)
-Almost totally same usage as pyodbc
-Simple and small - the whole module is implemented in a less
than 2000 lines python script

You can simply try pypyodbc in your existing pyodbc powered script
with the following changes:

#import pyodbc <-- The original pyodbc importing line
import pypyodbc as pyodbc
pyodbc.connect(...)  # pypyodbc is now doing pyodbc's job



Homepage:http://code.google.com/p/pypyodbc/

History

Version 0.8.7 Oct 18 2012
Added output converter function;
Fix result description;
Cursor iteration protocol;
Accept connection string in parameters format;

Version 0.8.6 Sep 23 2012
Added ODBC pooling feature
Bit, GUID type support
Other fixes and improvements

Version 0.8.5 Sep 16 2012
Numeric type fix
Long and integer differentiate
Other pyodbc compatibility improvements;

Version 0.8.4 Sep 9 2012 Improved compatibility with pyodbc; Many
underlying bug fixes;

Version 0.8.3 Sep 1 2012 sql_longvarchar handling fix; performance optimization;

Version 0.8.2 Aug 27 2012 Differentiate sql_varchar and
sql_longvarchar; Initial support for SQLAlchemy;

Version 0.8.1 Aug 26 2012 Fixed the long type parameter issue; Added
support for IronPython;

Version 0.8 Aug 25 2012 Added getinfo method;

Version 0.7 Jul 28 2012 Fixed nchar/ntext/nvarchar string truncat problem ;

Version 0.6 Jul 4 2012 Added Cursor.commit() and Cursor.rollback();
Added readonly keyword to connect;

Version 0.5 Jun 23 2012 Initial release;
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Web Frameworks PEP8 Consistency

[Andriy Kornatskyy]

The code is read much more often than it is written. The PEP8 guidelines are 
intended to improve the readability of code. We will take a look at web 
frameworks source code readability 
(bottle, cherrypy, circuits, django, flask, pyramid, tornado, web.py, web2py 
and wheezy.web):

http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html

The ratio between a web framework total python source lines to PEP8 errors 
found represents PEP8 error rate in respectful framework.

Readability counts, no doubt, but readability consistency is important, it is 
equally important to know when to be inconsistent. The report makes excuse for 
the following:

E501 line too long (> 79 characters)
E231 missing whitespace after ',:'
W291 trailing whitespace
W293 blank line contains whitespace

Comments or suggestions are welcome.

Thanks.

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

Re: A desperate lunge for on-topic-ness

[Grant Edwards]

On 2012-10-18, Zero Piraeus  wrote:

> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

I try to do what's easiest to read and understand.  Sometimes that
means using a line thats 120 characters long, sometimes that means
breaking up the line.

-- 
Grant Edwards   grant.b.edwardsYow! Am I in GRADUATE
  at   SCHOOL yet?
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: locking files on Linux

[Grant Edwards]

On 2012-10-18, andrea crotti  wrote:

> I'm trying to understand how I can lock a file while writing on it,
> because I might have multiple processes working on it at the same time.
>
> I found the fcntl.lockf function but if I do this:
>
> In [109]: locked = open('locked.txt', 'w')
>
> In [110]: fcntl.lockf(locked, fcntl.LOCK_EX)
>
> I can happily open the file with vim from somewhere and write on it, so
> it doesn't seem to be very useful, or am I missing something?

File locks under Unix have historically been "advisory".  That means
that programs have to _choose_ to pay attention to them.  Most
programs do not.

Linux does support mandatory locking, but it's rarely used and must be
manually enabled at the filesystem level. It's probably worth noting
that in the Linux kernel docs, the document on mandatory file locking
begins with a section titled "Why you should avoid mandatory locking".

http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems
http://kernel.org/doc/Documentation/filesystems/locks.txt
http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
http://www.thegeekstuff.com/2012/04/linux-file-locking-types/
http://www.hackinglinuxexposed.com/articles/20030623.html

-- 
Grant Edwards   grant.b.edwardsYow! Your CHEEKS sit like
  at   twin NECTARINES above
  gmail.coma MOUTH that knows no
   BOUNDS --
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: locking files on Linux

[andrea crotti]

2012/10/18 Grant Edwards :
> On 2012-10-18, andrea crotti  wrote:
>
>
> File locks under Unix have historically been "advisory".  That means
> that programs have to _choose_ to pay attention to them.  Most
> programs do not.
>
> Linux does support mandatory locking, but it's rarely used and must be
> manually enabled at the filesystem level. It's probably worth noting
> that in the Linux kernel docs, the document on mandatory file locking
> begins with a section titled "Why you should avoid mandatory locking".
>
> http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems
> http://kernel.org/doc/Documentation/filesystems/locks.txt
> http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
> http://www.thegeekstuff.com/2012/04/linux-file-locking-types/
> http://www.hackinglinuxexposed.com/articles/20030623.html
>
> --
> Grant Edwards   grant.b.edwardsYow! Your CHEEKS sit like
>   at   twin NECTARINES above
>   gmail.coma MOUTH that knows no
>BOUNDS --
> --
> http://mail.python.org/mailman/listinfo/python-list


Uhh I see thanks, I guess I'll use the good-old .lock file (even if it
might have some problems too).

Anyway I'm only afraid that my same application could modify the
files, so maybe I can instruct it to check if the file is locked.

Or maybe using sqlite would work even if writing from different
processes?

I would prefer to keep something human readable as INI-format though,
rather then a sqlite file..

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

Re: locking files on Linux

[Oscar Benjamin]

On 18 October 2012 14:44, andrea crotti  wrote:
> 2012/10/18 Grant Edwards :
>> On 2012-10-18, andrea crotti  wrote:
>>
>>
>> File locks under Unix have historically been "advisory".  That means
>> that programs have to _choose_ to pay attention to them.  Most
>> programs do not.
>>
>> Linux does support mandatory locking, but it's rarely used and must be
>> manually enabled at the filesystem level. It's probably worth noting
>> that in the Linux kernel docs, the document on mandatory file locking
>> begins with a section titled "Why you should avoid mandatory locking".
>>
>> http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems
>> http://kernel.org/doc/Documentation/filesystems/locks.txt
>> http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
>> http://www.thegeekstuff.com/2012/04/linux-file-locking-types/
>> http://www.hackinglinuxexposed.com/articles/20030623.html
>>
>> --
>> Grant Edwards   grant.b.edwardsYow! Your CHEEKS sit like
>>   at   twin NECTARINES above
>>   gmail.coma MOUTH that knows no
>>BOUNDS --
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
> Uhh I see thanks, I guess I'll use the good-old .lock file (even if it
> might have some problems too).

I think you've misunderstood what Grant meant.

>
> Anyway I'm only afraid that my same application could modify the
> files, so maybe I can instruct it to check if the file is locked.

In that case fcntl will work for you. The point is that fcntl only
locks the file if all of the applications accessing the file use
fcntl. Any other application such as vim can simply ignore the fcntl
lock. Have a read of the links that Grant posted.

Did you try writing twice from the same application that uses fcntl?

> Or maybe using sqlite would work even if writing from different
> processes?

That would also work.


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

Re: locking files on Linux

[Grant Edwards]

On 2012-10-18, andrea crotti  wrote:
> 2012/10/18 Grant Edwards :
>> On 2012-10-18, andrea crotti  wrote:
>>
>> File locks under Unix have historically been "advisory".  That means
>> that programs have to _choose_ to pay attention to them.  Most
>> programs do not.
>>
>> Linux does support mandatory locking, but it's rarely used and must be
>> manually enabled at the filesystem level. It's probably worth noting
>> that in the Linux kernel docs, the document on mandatory file locking
>> begins with a section titled "Why you should avoid mandatory locking".
>
> Uhh I see thanks, I guess I'll use the good-old .lock file (even if
> it might have some problems too).
>
> Anyway I'm only afraid that my same application could modify the
> files, so maybe I can instruct it to check if the file is locked.

If what you're guarding against is multiple instances of your
application modifying the file, then either of the advisory file
locking schemes or the separate lock file should work fine.

-- 
Grant Edwards   grant.b.edwardsYow! All this time I've
  at   been VIEWING a RUSSIAN
  gmail.comMIDGET SODOMIZE a HOUSECAT!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Jean-Michel Pichavant]

- Original Message -
> On 2012-10-18, Zero Piraeus  wrote:
> 
> > What are people's preferred strategies for dealing with lines that
> > go
> > over 79 characters? A few I can think of off the bat:
> 
> I try to do what's easiest to read and understand.  Sometimes that
> means using a line thats 120 characters long, sometimes that means
> breaking up the line.
>

Imo, def. a good approach to the problem. Mark's also pointed the fact that the 
guidelines themselves state that rules are made to be broken when they need to 
be.
The 79 char limit purpose is to allow someone to read the code on a 80 char 
terminal (and allow old printers to print the code). If following this rules 
breaks readability for all other terminals, meaning 99,99% of them, you know 
what to do.

JM

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

Re: use of exec()

[lars van gemerden]

On Thursday, October 18, 2012 1:49:35 PM UTC+2, Chris Angelico wrote:
> On Thu, Oct 18, 2012 at 10:41 PM, lars van gemerden
> 
>  wrote:
> 
> > NameError: name 'function' is not defined
> 
> >
> 
> > which seems an odd error, but i think some global variable is necessary for 
> > this to work (if i put in globals() instead of {}, it works).
> 
> 
> 
> The def statement simply adds a name to the current namespace. This
> 
> should work (untested):
> 
> 
> 
> class _functioncode(code):
> 
> def _creat_func_(self):
> 
> ns={}
> 
> exec("def function(%s):\n\t%s" % (", ".join(type(self).args),
> 
>   
> "\n\t".join(self.split('\n'))),ns,ns)
> 
> return ns.function
> 
> 
> 
> But it's going to be eternally plagued by security issues. You may
> 
> want, instead, to look at literal_eval from the ast module; but that
> 
> won't work if you need anything other than, as the name suggests,
> 
> literals.
> 
> 
> 
> ChrisA

Thanks, Chris,

That works like a charm (after replacig "return ns.function" with "return 
ns['function']" ;-) ).

About the security, i noticed you can still import and use modules within the 
exec'ed code. Is there a way to prevent this or otherwise make this approach 
more secure.

I should say that the users that will be able to make custom functions, are not 
end-users, but authenticated designers, however i would like to close a 
backdoor to the whole framework.

Cheers, Lars 



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

Re: use of exec()

[Chris Angelico]

On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden  wrote:
> Thanks, Chris,
>
> That works like a charm (after replacig "return ns.function" with "return 
> ns['function']" ;-) ).

Err, yes, I forget sometimes that Python doesn't do that. JavaScript
and Pike both let you (though Pike uses -> instead of . for that
operator). Yes, Python has real methods on dictionary objects :)

> About the security, i noticed you can still import and use modules within the 
> exec'ed code. Is there a way to prevent this or otherwise make this approach 
> more secure.

Basically no, there's no real way to make it secure. Without
eliminating exec/eval, destroying insecurity is the hopeless work of a
wasted life, as the oracle said to Alice.

> I should say that the users that will be able to make custom functions, are 
> not end-users, but authenticated designers, however i would like to close a 
> backdoor to the whole framework.

You have to decide one thing: Will you permit them to execute
untrusted code on your system? If so, go ahead (and just warn them
that things like import shouldn't be done, as they can cause other
messes). I run a server that I build with the help of another guy (I
do the code, he does the bulk of the content - descriptions and
stuff), and I'm happy to trust him to not be malicious, so the purpose
of "embedded code in loci" is to make it easier to write tiny bits of
code, without any security requirement. But if you need security,
don't use eval. AT ALL.

There may be a brand new service coming along, though. The ast module
I think is getting a new evaluator that allows a little more
functionality than literal_eval, while still not permitting most
things. But you then have the question of performance, since you
effectively interpret the code at a high level.

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

Re: Inheritance Question

[Oscar Benjamin]

On 18 October 2012 15:10, Jeff Jeffries  wrote:
> Hello everybody
>
> When I set "AttributeChanges" in my example, it sets the same value for all
> other subclasses. Can someone help me with what the name of this behavior is
> (mutable class global?) ?  I don't know any keywords... having trouble
> googling it
>
> Thanks in advance,

The code you attached is not so big that it can't just go in the
email. Here it is:

"""
class ABMixin:
AttributeChanges = [1]
AttributeDontChangeImmutable = 1
def __init__(self):
self.AttributeDontChange = [1]

class A(object,ABMixin):
def __init__(self):
ABMixin.__init__(self)

class B(object,ABMixin):
def __init__(self):
ABMixin.__init__(self)

a = A()
b = B()

print a.AttributeChanges,a.AttributeDontChange,a.AttributeDontChangeImmutable
print b.AttributeChanges,b.AttributeDontChange,b.AttributeDontChangeImmutable

a.AttributeChanges[0] = 2
a.AttributeDontChange[0] = 2
a.AttributeDontChangeImmutable = 2

print a.AttributeChanges,a.AttributeDontChange,a.AttributeDontChangeImmutable
print b.AttributeChanges,b.AttributeDontChange,b.AttributeDontChangeImmutable
"""

AttributeChanges is a "class attribute". This is the Python equivalent
of what would be a "static class member" in some other languages.


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

Re: Inheritance Question

[Dave Angel]

On 10/18/2012 10:10 AM, Jeff Jeffries wrote:
> Hello everybody
>
> When I set "AttributeChanges" in my example, it sets the same value for all
> other subclasses. Can someone help me with what the name of this behavior
> is (mutable class global?) ?  I don't know any keywords... having
> trouble googling it
>

I can't understand your code or what you're trying to do with it, but
maybe i can help anyway.  Incidentally, putting code in an attachment
will hide it from many users of this mailing list.  Just paste it inline
in your message, and make sure your message is composed as text, not html.


Attributes can be attached to the class or to the instance.  Those
attached to the class are shared among all instances that don't hide
them by having instance attributes of the same name.

Any attribute bound in an instance method is specific to that instance. 
Attributes bound in the class itself belong to the class.

class MyClass:
classAttr1 = 42   #this is a class attribute
classAttr2 = "will be masked"   #also this
def __init__(self):
self.instance_attr = "each instance gets its own"
self.classAttr2 = "this makes an instance attribute of the same
name"

def test(self):
print self.classAttr1#prints 42
print self.classAttr2   #printsthis makes an ...
print MyClass.classAttr2  #printswill be masked

a = MyClass()
a.test()




-- 

DaveA

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

Re: use of exec()

[lars van gemerden]

On Thursday, October 18, 2012 4:29:45 PM UTC+2, Chris Angelico wrote:
> On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden  
> wrote:
> 
> > Thanks, Chris,
> 
> >
> 
> > That works like a charm (after replacig "return ns.function" with "return 
> > ns['function']" ;-) ).
> 
> 
> 
> Err, yes, I forget sometimes that Python doesn't do that. JavaScript
> 
> and Pike both let you (though Pike uses -> instead of . for that
> 
> operator). Yes, Python has real methods on dictionary objects :)
> 
> 
> 
> > About the security, i noticed you can still import and use modules within 
> > the exec'ed code. Is there a way to prevent this or otherwise make this 
> > approach more secure.
> 
> 
> 
> Basically no, there's no real way to make it secure. Without
> 
> eliminating exec/eval, destroying insecurity is the hopeless work of a
> 
> wasted life, as the oracle said to Alice.
> 
> 
> 
> > I should say that the users that will be able to make custom functions, are 
> > not end-users, but authenticated designers, however i would like to close a 
> > backdoor to the whole framework.
> 
> 
> 
> You have to decide one thing: Will you permit them to execute
> 
> untrusted code on your system? If so, go ahead (and just warn them
> 
> that things like import shouldn't be done, as they can cause other
> 
> messes). I run a server that I build with the help of another guy (I
> 
> do the code, he does the bulk of the content - descriptions and
> 
> stuff), and I'm happy to trust him to not be malicious, so the purpose
> 
> of "embedded code in loci" is to make it easier to write tiny bits of
> 
> code, without any security requirement. But if you need security,
> 
> don't use eval. AT ALL.
> 
> 
> 
> There may be a brand new service coming along, though. The ast module
> 
> I think is getting a new evaluator that allows a little more
> 
> functionality than literal_eval, while still not permitting most
> 
> things. But you then have the question of performance, since you
> 
> effectively interpret the code at a high level.
> 
> 
> 
> ChrisA

I get your point, since in this case having the custom code option makes the 
system a whole lot less complex and flexible, i will leave the option in. The 
future customer will be informed that they should handle the security around 
the designers as if they were programmers. Aditionally i will probably add some 
screening for unwanted keywords (like 'import') and securely log any 
new/changed custom code including the designer account (must do that for other 
actions anyway).

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

Re: locking files on Linux

[Oscar Benjamin]

On 18 October 2012 15:49, andrea crotti  wrote:
> 2012/10/18 Grant Edwards :
>>
>> If what you're guarding against is multiple instances of your
>> application modifying the file, then either of the advisory file
>> locking schemes or the separate lock file should work fine.
>
> Ok so I tried a small example to see if I can make it fail, but this
> below just works perfectly fine.
>
> Maybe it's too fast and it release the file in time, but I would
> expect it to take some time and fail instead..

Why not come up with a test that actually shows you if it works? Here
are two suggestions:

1) Use time.sleep() so that you know how long the lock is held for.
2) Write different data into the file from each process and see what
you end up with.

>
> import fcntl
>
> from multiprocessing import Process
>
> FILENAME = 'file.txt'
>
>
> def long_text():
> return ('some text' * (100 * 100))
>
>
> class Locked:
> def __init__(self, fileobj):
> self.fileobj = fileobj
>
> def __enter__(self):
> # any problems here?
> fcntl.lockf(self.fileobj, fcntl.LOCK_EX)
> return self.fileobj
>
> def __exit__(self, type, value, traceback):
> fcntl.lockf(self.fileobj, fcntl.LOCK_UN)
>
>
> def write_to_file():
> with open(FILENAME, 'w') as to_lock:

I don't think it will work if you truncate the file like this. This
will empty the file *before* checking for the lock. Try opening the
file for reading and writing (without truncating).

> with Locked(to_lock):
> to_lock.write(long_text())
>
>
> if __name__ == '__main__':
> Process(target=write_to_file).start()
> Process(target=write_to_file).start()


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

Re: locking files on Linux

[andrea crotti]

2012/10/18 Oscar Benjamin :
>
> Why not come up with a test that actually shows you if it works? Here
> are two suggestions:
>
> 1) Use time.sleep() so that you know how long the lock is held for.
> 2) Write different data into the file from each process and see what
> you end up with.
>


Ok thanks I will try, but I thought that what I did was the worst
possible case, because I'm opening and writing on the same file from
two different processes, locking the file with LOCK_EX.

It should not open it at all as far as I understood...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inheritance Question

[Jeff Jeffries]

On Thu, Oct 18, 2012 at 10:51 AM, Dave Angel  wrote:

> On 10/18/2012 10:10 AM, Jeff Jeffries wrote:
> > Hello everybody
> >
> > When I set "AttributeChanges" in my example, it sets the same value for
> all
> > other subclasses. Can someone help me with what the name of this behavior
> > is (mutable class global?) ?  I don't know any keywords... having
> > trouble googling it
> >
>
> I can't understand your code or what you're trying to do with it, but
> maybe i can help anyway.  Incidentally, putting code in an attachment
> will hide it from many users of this mailing list.  Just paste it inline
> in your message, and make sure your message is composed as text, not html.
>
>
Eureka! This was useful too:
http://stackoverflow.com/questions/2923579/python-class-attribute

-- 
Cheers,
Jeff Jeffries III
CEO: www.willyoubemyfriend.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[rurpy]

On 10/18/2012 04:02 AM, Zero Piraeus wrote:> On 18 October 2012 05:22,  
 wrote:
>>[...]
> By the way: are you using Google Groups? It's just that I'm led to
> understand that it's recently started to misbehave [more than it used
> to], and your replies are addressed to both
>  and ,
> which is redundant.

When you post from Google Groups you will sometimes
see a checkbox above the edit window that is a cc to
the python mailing list () 
which is checked by default.  

If you uncheck that, you'll stop the double posting.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: use of exec()

[Chris Angelico]

On Fri, Oct 19, 2012 at 2:00 AM, lars van gemerden  wrote:
> I get your point, since in this case having the custom code option makes the 
> system a whole lot less complex and flexible, i will leave the option in. The 
> future customer will be informed that they should handle the security around 
> the designers as if they were programmers. Aditionally i will probably add 
> some screening for unwanted keywords (like 'import') and securely log any 
> new/changed custom code including the designer account (must do that for 
> other actions anyway).

That sounds like a reasonable implementation of Layer Eight security.
As long as everyone understands that this code can do ANYTHING, you'll
be fine.

You may want to add some other programmatic checks, though; for
instance, a watchdog timer in case the code gets stuck in an infinite
loop, or a memory usage limit, or somesuch. Since you're no longer
worrying about security, this sort of thing will be fairly easy, and
will be just to help catch common errors.

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

Re: locking files on Linux

[Oscar Benjamin]

On 18 October 2012 16:08, andrea crotti  wrote:
> 2012/10/18 Oscar Benjamin :
>>
>> Why not come up with a test that actually shows you if it works? Here
>> are two suggestions:
>>
>> 1) Use time.sleep() so that you know how long the lock is held for.
>> 2) Write different data into the file from each process and see what
>> you end up with.
>>
>
>
> Ok thanks I will try, but I thought that what I did was the worst
> possible case, because I'm opening and writing on the same file from
> two different processes, locking the file with LOCK_EX.
>
> It should not open it at all as far as I understood...

I don't think you have understood. Read the link that Grant posted:
http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems

And my other comment:

>> def write_to_file():
>> with open(FILENAME, 'w') as to_lock:
>
> I don't think it will work if you truncate the file like this. This
> will empty the file *before* checking for the lock. Try opening the
> file for reading and writing (without truncating).

The lock is cooperative. It does not prevent the file from being
opened or overwritten. It only prevents any other process from
obtaining the lock. Here you open the file with mode 'w' which
truncates the file instantly (without checking for the lock).


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

Re: A desperate lunge for on-topic-ness

[Dan Stromberg]

On Wed, Oct 17, 2012 at 11:06 PM, Zero Piraeus  wrote:

> :
>
> Okay, so, first thing vaguely Python-related that comes to mind [so
> probably not even slightly original, but then that's not really the
> point]:
>
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:
>
> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.
>
I tend to favor this one, #5.

In fact, I tend to do lots of "otherwise pointless" variables, because I
want to be able to quickly and easily insert print statements/functions
without having to  split up large commands, during debugging.

IOW, I don't like big, long one-liners. They tend to be less clear than
using lots of intermediate variables, and when you go to debug them you
often end up splitting  them up anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Den]

On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> :
> 
> 
> What are people's preferred strategies for dealing with lines that go
> 
> over 79 characters? A few I can think of off the bat:
> 

I personally just keep typing until my statement is finished.  This is my 
program, not PEP's.

But I have to say I'm amused by the whole question, and others related to PEP8. 
 A quick aside, the width of our roads all go back to the width of a two horse 
rig.  The suggested maximum of 80 characters goes back to teletype machines, 
and IBM cards, and character based terminals

Should that really be the basis for a suggested style now?

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

Re: python scripts for web

[chip9munk]

thank you for the answer!

On Thursday, October 18, 2012 12:03:02 PM UTC+2, Chris Angelico wrote:
> CGI is a protocol between Apache and your script. What you want to do
> is set up Apache to call your CGI scripts.



yes, but as I have just answered to Zero, is using mod_wsgi a better strategy?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[chip9munk]

On Thursday, October 18, 2012 12:02:40 PM UTC+2, Zero Piraeus wrote:

> Assuming your scripts accept the request as sent and return an
> appropriate response, they are CGI scripts (unless there's some
> wrinkle in the precise definition of CGI that escapes me right now).

yes, they are, but, I came under the impression that it is not the most 
elegant/fast way to do it... shouldn't the mod_wsgi be a better strategy?
or am i mixing these therms?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Aggressive language on python-list

[Curt]

On 2012-10-17, Dwight Hutto  wrote:
>> Instead of "diabetic", try inserting the word "black" or "female".
>> There's no shame in those either, yet I think that the offensiveness
>> of either of those words used in that context should be obvious.
>
> To take it a little further, what if I said I got gypped. I think it
> goes to gypsy's. Was it racist?

I told a girl friend once that my laptop had been purloined, and she
thought I was maligning her cat.

Maybe not the same thing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[chip9munk]

thank you guys for pointing the double posting issue out, I am having some 
issues with the news server i am using, so I am doing this via google.groups at 
the time! :)

i think i managed to fix it
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Neil Cerutti]

On 2012-10-18, Den  wrote:
> But I have to say I'm amused by the whole question, and others
> related to PEP8.  A quick aside, the width of our roads all go
> back to the width of a two horse rig.  The suggested maximum of
> 80 characters goes back to teletype machines, and IBM cards,
> and character based terminals
>
> Should that really be the basis for a suggested style now?

I had to use vim's reformatting powers to fix your first
paragraph. ;)

http://www.codinghorror.com/blog/2006/06/text-columns-how-long-is-too-long.html

Code is limited to one column, is left-justified, and
comprehension is much more important than reading speed. There
are lots of studies, but they are all about blocks of text, not
code.

Though technology has moved along swiftly, keeping your code
accessible to the guy using a crummy old console xterm might
still be worthwhile, and it makes printouts easy to create.

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

Re: A desperate lunge for on-topic-ness

[Evan Driscoll]

Ooo, a good religious war. How could I resist? :-) Bear in mind that
what I say is relative to layout issues, which in the grand scheme of
things. So even if I say I really disklike something, it's still not so
bad in practice. Except for backslash continuations. :-)


On 10/18/2012 01:06 AM, Zero Piraeus wrote:
> What are people's preferred strategies for dealing with lines that go
> over 79 characters?

My general rules are:

1. I dislike 80 character limits, and basically don't make a
   particularly strong attempt adhere to them for, well, basically
   any code I write, Python or not. I'll explain a little bit of why
   later. (I'd begrudgingly go along if I were working on a different
   code base that did of course, but in the meantime I don't have to
   deal with corporate style standards or anything like that so can
   bend the rules a bit.) 100 about where I start getting
   uncomfortable, and my semi-hard limit is 110-120. No doubt that's
   because that's about the line length I get with half of my monitor's
   width. :-)

   Python isn't as bad as C++ though (my main other language), where
   80 characters can go by *very* quickly.

2. Backslash continuations are *terrible*. I hate them with a firery
   passion. :-) A line could be 1000 characters long and it would be
   better than a 120-character line backslash-continued.

3. Using parentheses for continuations is sunshine and rainbows.

4. Extra variables are also great; I suspect I tend to use a
   more-than-average amount of extra variables anyway. (Though
   probably less so compared with the Python coder community than with
   the C++ coder community.)


Hans Mulder said:
>  Steven D'Aprano said:
>> some_variable = spam('x') + ham(
>> some_longer_variables, here_and_here,
>> and_here_also)
>
> I would spell that as:
>
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )

Ugh, I hate both. :-) I really dislike the arguments to a function
appearing to the left of the function. I'm fine with either

   some_function(foo,
 bar,
 baz)

or

   some_function(
   foo,
   bar,
   baz)

but the two quoted suggestion makes me cringe a bit. (Of my two options,
I think I actually prefer the latter, but tend to use the former because
I'm too lazy to figure out how to make Emacs do the second one.)

So with the above rule I might format that as:

   some_variable = spam('x') + ham(some_longer_variables,
   here_and_here,
   and_here_also)

except that runs afoul of another of my implict formatting "rules",
which is that if I have a multi-argument construct (e.g. an operator
or function call) and one of the arguments is multiple lines, I'd prefer
to see all of the arguments on their own lines. So I'd format
that as:

   some_variable = (spam('x')
+ ham(a, b, c))

as my first choice (long var names truncated here, but in real code with
no indent that's only 76 characters with the full ones in so it's fine
-- I'd do it that way even with a couple levels of indent)  and

   some_variable = (spam('x')
+ ham(some_longer_variables,
  here_and_here,
  and_here_also))

as my second, even though they require an extra set of parentheses and
even though there is plenty of room on the first line for "foo +
foo(".


The reason I say I dislike the quoted suggestions -- and ultimately why
I really dislike the 80 character limit -- is the following. If you ask
proponents of the 80 character limit, they'll tell you about how there's
only so much horizontal space and stuff like that. But I think that
ignores the benefits you get from intelligently using *vertical* space,
and I think the quoted suggestions do too.

I've taken each of the suggested formattings of the above and turned
them into a graphic, which you can see at
http://pages.cs.wisc.edu/~driscoll/temp/indent.png

I've drawn the boundary of every valid subexpression (except for the RHS
of each assignment) in each of the versions. In my suggestions, the
"ham()" subexpression is always contained within a rectangle -- in
the quoted suggestions, it is not, and is a more complicated shape. It
seems to me that the relationship between the vertical and horizontal
layout in those examples is somewhat haphazard. I can't even come up
with a "rule" for how the quoted examples arose; for mine, I'd say I'm
trying to keep subexpressions together in space (both horizontal and
vertical). I'm not sure that "drawing boxes" is exactly the right thing
to say what I'm doing, but I think it at least serves to illustrate my
point in this case.

Evan



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

Re: A desperate lunge for on-topic-ness

[Chris Angelico]

On Fri, Oct 19, 2012 at 2:49 AM, Dan Stromberg  wrote:
> In fact, I tend to do lots of "otherwise pointless" variables, because I
> want to be able to quickly and easily insert print statements/functions
> without having to  split up large commands, during debugging.

When will we next have a language with something like the REXX 'trace
i' command?

[C:\Desktop]rexxtry trace i; say 1+2*3 "equals" words(linein(word(source,3)))
95 *-* Say 1 + 2 * 3 'equals'
words(linein(word(source, 3)));
   >L>   "1"
   >L>   "2"
   >L>   "3"
   >O>   "6"
   >O>   "7"
   >L>   "equals"
   >O>   "7 equals"
   >V>   "OS/2 COMMAND C:\OS2\REXXTRY.CMD"
   >L>   "3"
   >F>   "C:\OS2\REXXTRY.CMD"
   >F>   "/* SAA-portable REXXTRY procedure
11/08/91  version 1.05"
   >F>   "7"
   >O>   "7 equals 7"
   >>>   "7 equals 7"
96 *-*   Trace 'Off';

Intermediate expression/statement evaluation, full details. Takes some
knowledge to comprehend (>L> means literal, >V> variable, >F> function
return value, etc), but extremely handy. Unfortunately REXX is an
aging language, as evidenced by such features as DBCS support (but no
Unicode), and functions as first-class objects support (nonexistent).
But this is a feature that I'd love to see implemented somewhere else.

Which probably means I'm going to have to write it somewhere else...

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

Re: A desperate lunge for on-topic-ness

[Chris Angelico]

On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti  wrote:
> Though technology has moved along swiftly, keeping your code
> accessible to the guy using a crummy old console xterm might
> still be worthwhile, and it makes printouts easy to create.

And keeping your interface accessible to someone who can't use the
Home and End keys allows it to be used by someone who's using PuTTY on
Windows to SSH to a gateway and then SSH from there to a firewalled
computer that's running your application. And yes, I do exactly that,
and yes, for some reason Home/End don't always work. One day I'll
probably figure out what the issue is, but for now, I'm just glad
there are baseline text editors that don't need such keys...

Technology moves on, but not everywhere.

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

Re: A desperate lunge for on-topic-ness

[Chris Angelico]

On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll  wrote:
>Python isn't as bad as C++ though (my main other language), where
>80 characters can go by *very* quickly.
>
> 2. Backslash continuations are *terrible*. I hate them with a firery
>passion. :-) A line could be 1000 characters long and it would be
>better than a 120-character line backslash-continued.

I have one mid-sized C++ project at work that's pretty much
exclusively under my control. There is precisely ONE place where
backslash continuations crop up, and that's long strings that want to
be formatted on multiple lines (eg huge SQL statements) - in Python,
they'd be trip-quoted. We don't have *any* backslash continuations in
Python code.

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

Re: A desperate lunge for on-topic-ness

[Dave Angel]

On 10/18/2012 12:26 PM, Chris Angelico wrote:
> On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll  wrote:
>>Python isn't as bad as C++ though (my main other language), where
>>80 characters can go by *very* quickly.
>>
>> 2. Backslash continuations are *terrible*. I hate them with a firery
>>passion. :-) A line could be 1000 characters long and it would be
>>better than a 120-character line backslash-continued.
> I have one mid-sized C++ project at work that's pretty much
> exclusively under my control. There is precisely ONE place where
> backslash continuations crop up, and that's long strings that want to
> be formatted on multiple lines (eg huge SQL statements) - in Python,
> they'd be trip-quoted. We don't have *any* backslash continuations in
> Python code.
>
>

But both C++ and Python have automatic concatenation of adjacent
strings.  So you can just start and end each line with a quote, and
leave off the backslash.

Similarly, if you need a newline at the end of each line, you can use
the \n just before the trailing quote.  Naturally I agree with you that
this case is better handled in Python with triple-quote.

I never use the backslash at end-of-line to continue a statement to the
next.  Not only is it a readability problem, but if your editor doesn't
have visible spaces, you can accidentally have whitespace after the
backslash, and wonder what went wrong.

-- 

DaveA

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

Re: A desperate lunge for on-topic-ness

[Chris Kaynor]

On Thu, Oct 18, 2012 at 9:47 AM, Dave Angel  wrote:

> On 10/18/2012 12:26 PM, Chris Angelico wrote:
> > On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll 
> wrote:
> >>Python isn't as bad as C++ though (my main other language), where
> >>80 characters can go by *very* quickly.
> >>
> >> 2. Backslash continuations are *terrible*. I hate them with a firery
> >>passion. :-) A line could be 1000 characters long and it would be
> >>better than a 120-character line backslash-continued.
> > I have one mid-sized C++ project at work that's pretty much
> > exclusively under my control. There is precisely ONE place where
> > backslash continuations crop up, and that's long strings that want to
> > be formatted on multiple lines (eg huge SQL statements) - in Python,
> > they'd be trip-quoted. We don't have *any* backslash continuations in
> > Python code.
> >
> >
>
> But both C++ and Python have automatic concatenation of adjacent
> strings.  So you can just start and end each line with a quote, and
> leave off the backslash.
>

That will work in C++ as the statements won't terminate on new-line (only
on semi-colon), however in Python that won't work as the statement
will terminate at the end of the line. You can get around this by wrapping
the multiple strings inside of parentheses.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Dave Angel]

On 10/18/2012 12:58 PM, Chris Kaynor wrote:
> On Thu, Oct 18, 2012 at 9:47 AM, Dave Angel  wrote:
>
>> 
>> But both C++ and Python have automatic concatenation of adjacent
>> strings.  So you can just start and end each line with a quote, and
>> leave off the backslash.
>>
> That will work in C++ as the statements won't terminate on new-line (only
> on semi-colon), however in Python that won't work as the statement
> will terminate at the end of the line. You can get around this by wrapping
> the multiple strings inside of parentheses.
>
>

You're right of course.  As it happens, i tested my "remembery" with a
function call (print, in Python 3) , so I already had the parens.

-- 

DaveA

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

len() on mutables vs. immutables

[Demian Brecht]

I'm curious as to the implementation (I'd be happy to dig through the 
source, just don't have the time right now). I've seen various 
implementations across interpreters in the past (some which have been 
rather shocking) and I'd like to get some insight into Python (well, 
CPython at this point anyway).


When len() is called passing an immutable built-in type (such as a 
string), I'd assume that the overhead in doing so is simply a function 
call and there are no on-call calculations done. Is that correct?


I'd also assume that mutable built-in types (such as a bytearray) would 
cache their size internally as a side effect of mutation operations. Is 
that correct? If so, is it safe to assume that at least all built-in 
types observe this behavior, or are there some that incur an O(n) cost 
on every len() call?


Obviously this can't be controlled with custom types that implement 
their own __len__, I'm only asking about Python's built-ins.


Thanks,
Demian
@demianbrecht
http://demianbrecht.github.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Grant Edwards]

On 2012-10-18, Den  wrote:
> On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
>
>> What are people's preferred strategies for dealing with lines that go
>> 
>> over 79 characters? A few I can think of off the bat:
>
> I personally just keep typing until my statement is finished.  This
> is my program, not PEP's.
>
> But I have to say I'm amused by the whole question, and others
> related to PEP8.  A quick aside, the width of our roads all go back
> to the width of a two horse rig.  The suggested maximum of 80
> characters goes back to teletype machines, and IBM cards, and
> character based terminals
>
> Should that really be the basis for a suggested style now?

You don't expect me to through my Heathkit H19 terminal in the trash,
do you?  :)

-- 
Grant Edwards   grant.b.edwardsYow! This is a NO-FRILLS
  at   flight -- hold th' CANADIAN
  gmail.comBACON!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() on mutables vs. immutables

[Terry Reedy]

On 10/18/2012 1:23 PM, Demian Brecht wrote:


When len() is called passing an immutable built-in type (such as a
string), I'd assume that the overhead in doing so is simply a function
call and there are no on-call calculations done. Is that correct?


See below.


I'd also assume that mutable built-in types (such as a bytearray) would
cache their size internally as a side effect of mutation operations. Is


Or the length could be the difference of two pointers -- address of the 
first empty slot minus address of first item.



that correct? If so, is it safe to assume that at least all built-in
types observe this behavior,


str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and 
ranges should all return len in O(1) time. That includes the possibility 
of a subtraction as indicated above.


--
Terry Jan Reedy

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

Re: len() on mutables vs. immutables

[Demian Brecht]

On 10/18/2012 11:28 AM, Nick Cash wrote:

It appears that list has len() complexity of O(1)
source: http://wiki.python.org/moin/TimeComplexity
It may be worth mentioning that lists in Python are implemented using arrays 
instead of linked lists.

It's reasonable to assume that other built-in collection types would be 
similar, though I don't see anything explicitly saying so for bytearray.

-Nick Cash


Thanks for the link, I don't believe I had seen that one before.


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

Re: len() on mutables vs. immutables

[Demian Brecht]

On 10/18/2012 11:29 AM, Terry Reedy wrote:> Or the length could be the 
difference of two pointers -- address of the

> first empty slot minus address of first item.

That would assume contiguous blocks of memory, which I would find to be 
rather dangerous (of an assumption that is) in most dynamic cases 
(obviously totally depends on implementation details).


> str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and
> ranges should all return len in O(1) time. That includes the possibility
> of a subtraction as indicated above.

Awesome. Pretty much what I figured. Of course, I'll have to dig around 
the source just to confirm this with my own eyes (more just curiosity 
than anything), so if you know whereabouts to look, it would be most 
helpful :)

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

RE: A desperate lunge for on-topic-ness

[Prasad, Ramit]

Den wrote:
> On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> > :
> >
> >
> > What are people's preferred strategies for dealing with lines that go
> >
> > over 79 characters? A few I can think of off the bat:
> >
> 
> I personally just keep typing until my statement is finished.  This is my 
> program, not PEP's.
> 
> But I have to say I'm amused by the whole question, and others related to 
> PEP8.  A quick aside, the width of our
> roads all go back to the width of a two horse rig.  The suggested maximum of 
> 80 characters goes back to teletype
> machines, and IBM cards, and character based terminals
> 
> Should that really be the basis for a suggested style now?
> 
> Den

Unlike IBM cards and the teletype, character based terminals are still
widely used (at least in the developer communities). They often default to
80 characters, but handle various sizes. So that comparison is not quite
fair. 

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Joshua Landau]

On 18 October 2012 12:05, Tim Chase  wrote:

> On 10/18/12 04:33, wxjmfa...@gmail.com wrote:
> > I use a "double indentation".
> >
>  if 'asdf' and 'asdf' and 'asdf' \
> > ... 'asdf' and 'asdf' and \
> > ... 'asdf' and 'asdf':
> > ... print('do if')
> > ... s = 'asdf'
> > ... ss = 'asdf'
> > ...
> > do if
>  if looks_like_it_might_be_spam(
> > ... some_longer_variables,
> > ... here_and_here, and_here_also):
> > ... logger.notice("might be spam")
> > ... move_to_spam_folder(some_longer_variables)
> > ... update_spam_statistics(here_and_here)
>
> I lean towards double-indent as well, though I favor parens/brackets
> vs. trailing backslashes.  My conditions usually go one-per-line,
> too.  I also tend to put my closing paren+colon on a stand-alone line:
>
> if (
> something
> or something_else
> or yet_other_stuff
> ):
> do_thing1()
> do_thing2()
>
> It's not quite as nice with pure parens, working better with
> function-calls.  However, it makes my git/svn diffs easier to read
> when conditions get added/removed because only that line (usually)
> changes, rather than having the noise of the paren moving around.
>
> In 2.5 and later, I like to write that as
>
> if any([
> something,
> something_else,
> yet_other_stuff,
> ]):
> do_thing1()
> do_thing2()
>
> where each item is uniform (one trailing comma, rather than one item
> being special without a comma/or/and) so I don't have the diff noise
> for "or"/"and" bouncing around either.
>
> Making my diffs easy to read is pretty important to me.
>

I'm of the opinion that:

cheese_cake = bake(

 self_raising_flour(),

 sour_lemons(),

 milky_cheese(),

 )


is the nicest format for normal overflow, but I'm really irked at the sight
of *any* overflow in an "if x:" statement or anything that starts more
indentation. All indentation *and* outdentation should be meaningful:
"group" or "end group" respectively. If you indent and then outdent *to a
new indentation*, it's confusing and obfuscating. The outdent is not "end
group", as before, but something else.

The neat thing about:

> foobars = inversed_word_order(

 barfoo(),

 raboof(

 inverse_mode="letters",

  hidden_lettuce=GGE_RETSAE

 ),

 not foobar()

 )

is that it is consistent with this world-view.

My lines often go past 120 characters without splitting*, so I rarely have
this problem, but when I do the solution is *invariably*:

all_can_be_baked = all(

 can_be_baked(ingredient)

 for ingredient in [

 self_raising_flour(),

 sour_lemons(),

 milky_cheese(),

 ]

)



if all_can_be_baked:


There is not a situation in the world where a suitable intermediate name
can not be found: you are doing something for a reason, after all.

* I use 8-space tabs, so it's not that hard ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: A desperate lunge for on-topic-ness

[Prasad, Ramit]

Chris Angelico wrote: 
> On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti  wrote:
> > Though technology has moved along swiftly, keeping your code
> > accessible to the guy using a crummy old console xterm might
> > still be worthwhile, and it makes printouts easy to create.
> 
> And keeping your interface accessible to someone who can't use the
> Home and End keys allows it to be used by someone who's using PuTTY on
> Windows to SSH to a gateway and then SSH from there to a firewalled
> computer that's running your application. And yes, I do exactly that,
> and yes, for some reason Home/End don't always work. One day I'll
> probably figure out what the issue is, but for now, I'm just glad
> there are baseline text editors that don't need such keys...
> 
> Technology moves on, but not everywhere.
> 
> ChrisA
> --

Home and end do not bother me much as I can usually use ctrl+a/ctrl+e
for the same purpose. I do wish I found a better way to page up/down.


Ramit Prasad
 
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: OT Questions

[Prasad, Ramit]

David Hutto wrote:
> On Wed, Oct 17, 2012 at 7:12 PM, Steven D'Aprano
>  wrote:
> > On Wed, 17 Oct 2012 18:05:12 -0400, Dwight Hutto wrote:
> >
> >> this was just a confidence statement that I'm
> >> intelligent as well, so don't get uppity with me.
> >
> > Please tone down the aggression.
> >
> >
> It's email, things get misinterpreted sometimes.
> 

True, which is why we should all take a little extra care
in what we write to avoid misinterpretation, especially
in terms of offensiveness. 

Besides, what you write here is public and can be seen by anyone 
with access to the Internet and a search engine. That includes prospective 
clients/employers! I know there is an increasing trend for employers 
to search the Internet to learn about potential employees. I do the 
same before I hire a company for many things (e.g. house/car repair,
translator, etc).


Ramit Prasad


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: OT Questions

[Prasad, Ramit]

David Hutto wrote: 
> On Wed, Oct 17, 2012 at 12:38 PM, Prasad, Ramit
>  wrote:
> > David Hutto wrote:
> >> On Wed, Oct 17, 2012 at 2:06 AM, Demian Brecht  
> >> wrote:
[snip]
> 
> > The question is whose opinion matters. Yours? Mine? Others? Personally,
> > I heartily second the recommendation to get professional advice on site
> > design. Your site reminds me of something I would create in the '90s
> > with FrontPage (do people even use that anymore?) as an amateur or
> > hobbyist; not something I would create as a professional attempting
> > to market my services.
> >
> I'm moving toward the smaller devices, but I'm a desktop guy, and so
> are a lot of others. And what site doesn't have a frontpage?

Just to clarify Microsoft FrontPage was a late 90s/early-2000's application
for creating web pages with a WYSIWYG front end. The precursor to Adobe's
Dreamweaver and sort of the web design equivalent of Microsoft Word.

[snip]

Out of curiosity, is there a reason you did not pick Python (seeing
as this is a Python mailing list) for this task? Or conversely, is
there a reason you picked PHP?


Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: len() on mutables vs. immutables

[Nick Cash]

> I'm curious as to the implementation (I'd be happy to dig through the
> source, just don't have the time right now). I've seen various
> implementations across interpreters in the past (some which have been
> rather shocking) and I'd like to get some insight into Python (well,
> CPython at this point anyway).
> 
> When len() is called passing an immutable built-in type (such as a
> string), I'd assume that the overhead in doing so is simply a function
> call and there are no on-call calculations done. Is that correct?
> 
> I'd also assume that mutable built-in types (such as a bytearray) would
> cache their size internally as a side effect of mutation operations. Is
> that correct? If so, is it safe to assume that at least all built-in
> types observe this behavior, or are there some that incur an O(n) cost
> on every len() call?

It appears that list has len() complexity of O(1)
source: http://wiki.python.org/moin/TimeComplexity
It may be worth mentioning that lists in Python are implemented using arrays 
instead of linked lists.

It's reasonable to assume that other built-in collection types would be 
similar, though I don't see anything explicitly saying so for bytearray.

-Nick Cash

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

RE: A desperate lunge for on-topic-ness

[Prasad, Ramit]

Hans Mulder wrote:
> On 18/10/12 08:31:51, Steven D'Aprano wrote:
> > On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:
> >> 3. Say "well, at least it's not a backslash" and break the line using
> >> > parentheses.
> > I mostly do this. Since most lines include a bracket of some sort, I
> > rarely need to add outer parentheses just for the purpose of line
> > continuation.
> >
> > some_variable = spam('x') + ham(
> > some_longer_variables, here_and_here,
> > and_here_also)
> 
> I would spell that as:
> 
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )
> 
> > I know PEP 8 says I should drop the final round bracket to the next line,
> > but I don't normally like that.
> 
> I normally put the final bracket on the next line, where it is
> very visible.  Compare:
> 
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here, and_here_also):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
> 
> vs.
> 
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here,
> and_here_also,
> ):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
> 
> Which one would you say is more readable?
> 

For the first example, I would probably indent the arguments more 
to differentiate a continuing line. That way the "):" does not
look like it was un-indented to be part of a different block.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)


Ramit Prasad



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: len() on mutables vs. immutables

[Prasad, Ramit]

Terry Reedy wrote:
> On 10/18/2012 1:23 PM, Demian Brecht wrote:
> 
> > When len() is called passing an immutable built-in type (such as a
> > string), I'd assume that the overhead in doing so is simply a function
> > call and there are no on-call calculations done. Is that correct?
> 
> See below.
> 
> > I'd also assume that mutable built-in types (such as a bytearray) would
> > cache their size internally as a side effect of mutation operations. Is
> 
> Or the length could be the difference of two pointers -- address of the
> first empty slot minus address of first item.
> 
> > that correct? If so, is it safe to assume that at least all built-in
> > types observe this behavior,
> 
> str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and
> ranges should all return len in O(1) time. That includes the possibility
> of a subtraction as indicated above.
> 

Why does pointer arithmetic work for dicts? I would think the position
of a value would be based on the hash of the key and thus "random" for
the context of this conversation.

Ramit Prasad


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() on mutables vs. immutables

[Ian Kelly]

On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit
 wrote:
> Why does pointer arithmetic work for dicts? I would think the position
> of a value would be based on the hash of the key and thus "random" for
> the context of this conversation.

It doesn't.  len() on CPython dicts is O(1) because the dict keeps
track of how many items it contains.  It needs to do this anyway so
that it can determine when to grow the internal hash table.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() on mutables vs. immutables

[Daniel Urban]

On Thu, Oct 18, 2012 at 8:42 PM, Demian Brecht  wrote:
>> str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and
>> ranges should all return len in O(1) time. That includes the possibility
>> of a subtraction as indicated above.
>
> Awesome. Pretty much what I figured. Of course, I'll have to dig around the
> source just to confirm this with my own eyes (more just curiosity than
> anything), so if you know whereabouts to look, it would be most helpful :)

The source is usually in Objects/*object.c (e.g., the source for list
is in Objects/listobject.c, dict is in dictobject.c and so on). The
implementation of __len__ is usually in a method called
whatever_length (e.g., dict.__len__ is called dict_length). To be
sure, you can check the PyTypeObject declaration for the type.
Probably the tp_as_sequence or tp_as_mapping field contains the
pointer to __len__ (sq_length or mp_length respectively). (You can
also search for "lenfunc", which is the type of such functions.)
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: len() on mutables vs. immutables

[Prasad, Ramit]

Ian Kelly wrote:
> Sent: Thursday, October 18, 2012 2:39 PM
> To: Python
> Subject: Re: len() on mutables vs. immutables
> 
> On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit
>  wrote:
> > Why does pointer arithmetic work for dicts? I would think the position
> > of a value would be based on the hash of the key and thus "random" for
> > the context of this conversation.
> 
> It doesn't.  len() on CPython dicts is O(1) because the dict keeps
> track of how many items it contains.  It needs to do this anyway so
> that it can determine when to grow the internal hash table.

That is what I was thinking "should" happen. Thanks for the 
clarification Ian.


Ramit Prasad


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Ian Kelly]

On Thu, Oct 18, 2012 at 10:47 AM, Dave Angel  wrote:
> I never use the backslash at end-of-line to continue a statement to the
> next.  Not only is it a readability problem, but if your editor doesn't
> have visible spaces, you can accidentally have whitespace after the
> backslash, and wonder what went wrong.

Note the actual error message that you get in this case is:

"SyntaxError: unexpected character after line continuation character"

Seems pretty transparent to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python scripts for web

[Zero Piraeus]

:

On 18 October 2012 12:03,   wrote:
> yes, but as I have just answered to Zero, is using mod_wsgi a better strategy?

WSGI would enable you to write a persistent application that sits
around waiting for requests and returns responses for them as and
when, as opposed to a simple CGI script that gets started each time a
request comes in, and terminates once it's returned the response.

So it's really about startup time - if your scripts are just doing
something simple and quick, WSGI is likely overkill.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A desperate lunge for on-topic-ness

[Zero Piraeus]

:

On 18 October 2012 11:55, Den  wrote:
> [...] I'm amused by the whole question, and others related
> to PEP8.  A quick aside, the width of our roads all go back to the
> width of a two horse rig.  The suggested maximum of 80 characters goes
> back to teletype machines, and IBM cards, and character based
> terminals [...]

... and the decisions made back in the day about line length on
teletypes etc. were informed [perhaps unconsciously] by the rules of
printed literature - and *those* rules have a *lot* of accumulated
wisdom behind them.

Robert Bringhurst's Elements of Typographical Style is very good on
that stuff; one thing he points out is that, at root, what's
comfortable is defined by the size of the human hand, the distance we
hold a book from our eye, etc. ... and while we still live in a world
composed of physical objects, a lot of that gut feeling about what's
comfortable carries across into the digital world.

The accepted rule in print is that lines of prose should be between 45
and 90 characters, with 66 being ideal for readability. Code is not
prose, and the combination of fixed-width and much more variable line
length aids readability, but however it came about, ~80 does seem to
more or less work as a limit.

I'm pretty slavish about adhering to PEP 8 these days. Programmers are
an opinionated bunch, and we all, given the opportunity, will come up
with our own set of obviously [goddammit] correct rules. Having a
broadly sensible, authoritative set of guidelines that we grudgingly
agree to follow makes working with other coders easier IMO.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

pip fails to install packages on moutain loin (Mac OS 10.8.2)

[Peng Yu]

Hi,

I installed Python using python-2.7.3-macosx10.6.dmg on my Mac OS
10.8.2.

When try to use pip to install packages, I get the following message.
Then the installation fails.

gcc-4.2 not found, using clang instead


I then create a link from /usr/bin/gcc to gcc-4.2. Then I run pip
again, I get the following error message.

Does anybody have a solution to install python on Mac OS 10.8.2 so
that packages can be installed with pip?

/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/exception:
42:28: error: bits/c++config.h: No such file or directory
In file included from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
+/4.2.1/bits/stl_algobase.h:70,
 from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
+/4.2.1/bits/char_traits.h:46,
 from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
+/4.2.1/string:47,
 from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
+/4.2.1/stdexcept:44,

Regards,
Peng
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: pip fails to install packages on moutain loin (Mac OS 10.8.2)

[Prasad, Ramit]

Peng Yu wrote
> Hi,
> 
> I installed Python using python-2.7.3-macosx10.6.dmg on my Mac OS
> 10.8.2.
> 
> When try to use pip to install packages, I get the following message.
> Then the installation fails.
> 
> gcc-4.2 not found, using clang instead
> 
> 
> I then create a link from /usr/bin/gcc to gcc-4.2. Then I run pip
> again, I get the following error message.
> 
> Does anybody have a solution to install python on Mac OS 10.8.2 so
> that packages can be installed with pip?
> 
> /Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/exception:
> 42:28: error: bits/c++config.h: No such file or directory
> In file included from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/bits/stl_algobase.h:70,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/bits/char_traits.h:46,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/string:47,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/stdexcept:44,
> 
> Regards,
> Peng

I would install python+virtualenv+pip from MacPorts to keep
it separate from the OS X system Python. MacPorts will take 
care of everything for you as long as you have Xcode installed. 

`sudo ports install py27-pip`


Ramit Prasad


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() on mutables vs. immutables

[Demian Brecht]

On Thu, Oct 18, 2012 at 12:43 PM, Daniel Urban  wrote:
> The source is usually in Objects/*object.c (e.g., the source for list
> is in Objects/listobject.c, dict is in dictobject.c and so on). The
> implementation of __len__ is usually in a method called
> whatever_length (e.g., dict.__len__ is called dict_length). To be
> sure, you can check the PyTypeObject declaration for the type.
> Probably the tp_as_sequence or tp_as_mapping field contains the
> pointer to __len__ (sq_length or mp_length respectively). (You can
> also search for "lenfunc", which is the type of such functions.)

Many thanks for the details.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pip fails to install packages on moutain loin (Mac OS 10.8.2)

[Ned Deily]

In article 
<53b38fa2-ea8b-4225-bdf3-b9bcbde31...@o5g2000yqi.googlegroups.com>,
 Peng Yu  wrote:

> Hi,
> 
> I installed Python using python-2.7.3-macosx10.6.dmg on my Mac OS
> 10.8.2.
> 
> When try to use pip to install packages, I get the following message.
> Then the installation fails.
> 
> gcc-4.2 not found, using clang instead
> 
> 
> I then create a link from /usr/bin/gcc to gcc-4.2. Then I run pip
> again, I get the following error message.
> 
> Does anybody have a solution to install python on Mac OS 10.8.2 so
> that packages can be installed with pip?
> 
> /Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/exception:
> 42:28: error: bits/c++config.h: No such file or directory
> In file included from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/bits/stl_algobase.h:70,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/bits/char_traits.h:46,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/string:47,
>  from /Developer/SDKs/MacOSX10.6.sdk/usr/include/c+
> +/4.2.1/stdexcept:44,

One issue is that you are mixing compilers and SDKs.  Python 2.7.3 was 
released about the time Apple released Xcode 4.3 which fundamentally 
changed where SDKs are located.  Xcode 4 no longer uses /Developer at 
all, so what is there is likely left behind from 10.7 or earlier 
versions of Xcode.  Further, Xcode 4.5 which is the currently supported 
version on 10.8 does not include an SDK for 10.6.   2.7.3 does have 
support for using clang instead of the Xcode 3.2 gcc-4.2 it was built 
with.  This is untested but the simplest workaround if you are using 
Xcode 4.4 or 4.5.* may be to just remove (or at least rename) /Developer

sudo mv /Developer /Developer-old

and make sure you have installed the Command Line Tools component of 
Xcode 4.* (Xcode -> Preferences).  If there is no directory at the 
original SDK path (/Developer/SDKs/MacoOSX10.6.sdk), I believe distutils 
will try to build without using an SDK, which may work. Also, you may 
need to define env variable CXX if you are building c++:

export CXX=/usr/bin/g++
or export CXX=/usr/bin/clang++

The plan is for the next maintenance release of Python 2.7 to work 
better with current Xocde 4.x on 10.7 and 10.7, as the newly released 
Python 3.3.0 does.

-- 
 Ned Deily,
 n...@acm.org

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

Re: pip fails to install packages on moutain loin (Mac OS 10.8.2)

[Ned Deily]

In article 
<5b80dd153d7d744689f57f4fb69af4741671d...@scacmx008.exchad.jpmchase.net>
,
 "Prasad, Ramit"  wrote:
> I would install python+virtualenv+pip from MacPorts to keep
> it separate from the OS X system Python. MacPorts will take 
> care of everything for you as long as you have Xcode installed.   
> 
> `sudo ports install py27-pip`

Yes, that should be another viable option as all of the components 
should be built with the same version of the Xcode tool chain.  Also, 
some or all of the third-party packages may already be available as 
MacPorts ports.

-- 
 Ned Deily,
 n...@acm.org

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

Re: A desperate lunge for on-topic-ness

[Gene Heskett]

On Thursday 18 October 2012 18:40:52 Grant Edwards did opine:

> On 2012-10-18, Den  wrote:
> > On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> >> What are people's preferred strategies for dealing with lines that go
> > 
> >> over 79 characters? A few I can think of off the bat:
> > I personally just keep typing until my statement is finished.  This
> > is my program, not PEP's.
> > 
> > But I have to say I'm amused by the whole question, and others
> > related to PEP8.  A quick aside, the width of our roads all go back
> > to the width of a two horse rig.  The suggested maximum of 80
> > characters goes back to teletype machines, and IBM cards, and
> > character based terminals
> > 
> > Should that really be the basis for a suggested style now?
> 
> You don't expect me to through my Heathkit H19 terminal in the trash,
> do you?  :)

Or me to delete the vt-220 I wrote to run on a TRS-80 Color Computer 
running OS-9 for an OS, 20 years ago when the Dec made one ate its H.O.T. & 
Dec would not sell me a H.O.T. since it was over 5 years old and wanted 
$2995 for brand new vt-550 (with no guarantee it would be compatible)?

That, and their field service engineers inability to fix a crashing hourly 
or more PDP-11/723a amply explains why DEC is no longer with us.

That single obstinate computer made the CBS tv network design a new system 
and distribute it gratis to every network affiliate they had, somewhere 
around 125 stations, at a cost of at least 10G's a station.

Screw that.  I had better things to than throw more good money after bad.
So did CBS at the time.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
How sharper than a hound's tooth it is to have a thankless serpent.
-- 
http://mail.python.org/mailman/listinfo/python-list

Add if...else... switch to doctest?

[David]

Hello, how to add if...else... switch to doctest?
E.g. function outputs different value when global_var change.

"""
if (global_var == True):
>>> function()
[1,2]
else:
>>> function()
[1,2,3]
"""

Thank you very much.
-- 
http://mail.python.org/mailman/listinfo/python-list

When to clear elements using cElementTree

[Ben Temperton]

Hi there, I am parsing some huge xml files (1.8 Gb) that look like this:

some data

some data


some data



What I am trying to do is build up a dictionary of lists where the key is the 
parent scan num and the members of the list are the child scan nums.

I have created an iterator:

for event, elem in cElementTree.iterparse(filename):
if elem.tag == self.XML_SPACE + "scan":
parentId = int(elem.get('num'))
for child in elem.findall(self.XML_SPACE +'scan'):
try:
indexes = scans[parentId]
except KeyError:
 indexes = []
 scans[parentId] = indexes
 childId = int(child.get('num'))
 indexes.append(childId)
# choice 1 - child.clear()
   #choice 2 - elem.clear()
#choice 3 - elem.clear()

If I don't use any of the clear functions, the method works fine, but is very 
slow (presumably because nothing is getting cleared from memory. But, if I 
implement any of the clear functions shown, then 

childId = int(child.get('num'))

fails because child.get('num') returns a NoneType. If you dump the child 
element using cElementTree.dump(child), all of the attributes on the child 
scans are missing, even though the clear() calls are made after the assignment 
of the childId.

What I don't understand is why, given the calls are made after assignment, that 
the assignment then fails, but succeeds when clear() is not called.

When should I be calling clear() in this case to maximize speed?

Many thanks,

Ben



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

Re: A desperate lunge for on-topic-ness

[Ben Finney]

Zero Piraeus  writes:

> :
>

(Why is this colon appearing at the top of your messages? Can you remove
it if it's not germane?)

> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

> 1. Say "screw it" and go past 79, PEP8 be damned.

There are many people who are irritated by Python code that has lines
longer than 80 characters. In my experience, though, it's much easier to
read code which is written using a strict maximum length of 80
characters per line, and code which tends to exceed that length is
strongly correlated with code which is difficult to read for other
reasons too.

> 2. Say "screw it" and break the line using a backslash.

Never this. A backslash is almost never a good choice (it leaves the
code in a state that an invisible difference – trailing whitespace – can
cause it to break), especially because there are so many other better
options.

> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.

Long lines frequently have some kind of bracketing syntax (parentheses,
brackets, braces, triple-quotes, etc.) which make it easy to break the
line properly. That's a natural place to break the line, and the
continuations should all be indented 8 characters (recommended in PEP 8
also).

> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.

If the names are so long that they make it difficult to fit the line
within 80 characters, one of the following is probably true:

* The line is indented too far. Re-factor the chunk of code to a smaller
  function.

* The line is too complex. Break it into several smaller statements.

* The names are too long. Make them descriptive, but not huge. In a
  simple function (which all of them should ideally be) there should be
  few enough names involved that they can all be short. Corollary: if
  the names are too long, the function is probably too dependent on a
  large context.

> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.

Using assignments for intermediate steps is not pointless. One
significant benefit is that it makes the code more obvious to the
reader.

> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.

List comprehensions are already within bracketing syntax, so are
trivially easy to break across multiple lines.

> Any I've missed? Any preferences?

I prefer continuation lines to look like this::

def prepare_smorgasbord(
smorgasbord_class, poultry, food_preparation_handbook):
""" Prepare the smorgasbord with poultry.

The `food_preparation_handbook` is used to cite a warning if
a gizzard is past its expiration date.

"""
smorgasbord = smorgasbord_class()
for item in [
foo for foo in
poultry.giblets.iteritems()
if foo.type = 'gizzard']:
smorgasbord.add(
prepare_gizzard_for_consumption(item))
if item.expiry < datetime.datetime.now():
smorgasbord.flag(
food_preparation_handbook.warning("Only for the brave"))

return smorgasbord

Every statement should stay beyond the starting level of indentation;
returning to the same level of indentation or earlier should only happen
when a new statement occurs.

The 8-column indentation makes it clear that this is not a new code
block, making it obvious to the eye where a code block (indented at 4
columns) actually starts.

That's a contrived example, obviously, and for some of those things I'd
probably be tempted to re-factor self-contained parts to separate
functions in order to make the code at this location simpler. But it
illustrates the line continuation style I advocate.

-- 
 \“Program testing can be a very effective way to show the |
  `\presence of bugs, but is hopelessly inadequate for showing |
_o__)  their absence.” —Edsger W. Dijkstra |
Ben Finney

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

Re: A desperate lunge for on-topic-ness

[Ben Finney]

Hans Mulder  writes:

> On 18/10/12 08:31:51, Steven D'Aprano wrote:
> > some_variable = spam('x') + ham(
> > some_longer_variables, here_and_here, 
> > and_here_also)

The indentation level for continuation lines shouldn't be dependent on
the content of the first line of the statement. That leads to either
pointless fiddling with the continuation lines when one line changes; or
to a large indentation which is also pointless because it no longer
matches the first line.

> I would spell that as:
>
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )

I dislike the indentation of the final line, because it pops out like
the start of a new statement. Either::

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also)
do_next_thing()

Or::

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also,
)
do_next_thing()

depending on whether I deem it likely that new items will later be added
within the parentheses.

> > I know PEP 8 says I should drop the final round bracket to the next
> > line, but I don't normally like that.
>
> I normally put the final bracket on the next line, where it is
> very visible.  Compare:
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here, and_here_also):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)

To avoid this problem, I advocate 8-column indentation for continuation lines
to contrast with the 4-column indentation for a code block::

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

>
> vs.
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here,
> and_here_also,
> ):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
>
> Which one would you say is more readable?

Mine :-)

-- 
 \   “When I get new information, I change my position. What, sir, |
  `\ do you do with new information?” —John Maynard Keynes |
_o__)  |
Ben Finney

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

Re: A desperate lunge for on-topic-ness

[Ben Finney]

Jean-Michel Pichavant  writes:

> The 79 char limit purpose is to allow someone to read the code on a 80
> char terminal (and allow old printers to print the code).

There is a very good reason for a strict line width limit regardless of
terminal size: scanning long lines is cognitively more difficult than
scanning shorter lines.

This doesn't mean we should keep reducing the length of our lines, of
course; obviously there needs to be enough room on a line to be
expressive. But it does mean that lines which are too long are not kind
to the reader.

Another good reason: Even if you have a large terminal, you will often
need to compare distinct sections of code. Knowing that code won't
exceed 80 columns means that you can lay several windows of code
side-by-side, for a three-way merge, for example.

-- 
 \  “Anyone who believes exponential growth can go on forever in a |
  `\finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney

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

Re: A desperate lunge for on-topic-ness

[Steven D'Aprano]

On Thu, 18 Oct 2012 12:47:48 -0400, Dave Angel wrote:

> I never use the backslash at end-of-line to continue a statement to the
> next.  Not only is it a readability problem, but if your editor doesn't
> have visible spaces, you can accidentally have whitespace after the
> backslash, and wonder what went wrong.

What, you don't read the SyntaxError that you will invariably get?


# Python 2.7 and 3.3:

py> x = 42 + \
  File "", line 1
x = 42 + \
  ^
SyntaxError: unexpected character after line continuation character



Even if you go back to truly ancient Python 1.5:

[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> x = 42 + \
  File "", line 1
x = 42 + \
  ^
SyntaxError: invalid token


Honestly, it's not that hard to diagnose line continuation errors. It's 
probably easier to diagnose them than to diagnose missing parentheses.

The more I hear people dissing line continuation backslashes, the more I 
want to use them everywhere.


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

Re: len() on mutables vs. immutables

[Terry Reedy]

On 10/18/2012 3:18 PM, Prasad, Ramit wrote:

Terry Reedy wrote:

On 10/18/2012 1:23 PM, Demian Brecht wrote:


When len() is called passing an immutable built-in type (such as a
string), I'd assume that the overhead in doing so is simply a function
call and there are no on-call calculations done. Is that correct?


See below.


I'd also assume that mutable built-in types (such as a bytearray) would
cache their size internally as a side effect of mutation operations. Is


Or the length could be the difference of two pointers -- address of the
first empty slot minus address of first item.


that correct? If so, is it safe to assume that at least all built-in
types observe this behavior,


str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and
ranges should all return len in O(1) time. That includes the possibility
of a subtraction as indicated above.



Why does pointer arithmetic work for dicts?


It would only possibly be for lists, bytearrays, and, array module 
arrays.They are all over-allocated and need pointer to beginning, and 
either len or pointers to current end and allocated end. The current 
authoritative answer is in the current code itself.


--
Terry Jan Reedy

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

Re: len() on mutables vs. immutables

[Terry Reedy]

On 10/18/2012 2:42 PM, Demian Brecht wrote:


Awesome. Pretty much what I figured. Of course, I'll have to dig around
the source just to confirm this with my own eyes (more just curiosity
than anything),


If you do, please followup with a report.

--
Terry Jan Reedy

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

Re: Add if...else... switch to doctest?

[Ben Finney]

David  writes:

> Hello, how to add if...else... switch to doctest?
> E.g. function outputs different value when global_var change.
>
> """
> if (global_var == True):
> >>> function()
> [1,2]
> else:
> >>> function()
> [1,2,3]
> """
>
> Thank you very much.

You write the code in a doctest as it would appear at a standard Python
interactive prompt.

>>> if global_thing:
... foo()
[1, 2]

But you need it to be deterministic, so that the output *always*
matches what your docstring declares.

So if you want the result to depend on some state, you need to ensure
that state in your test.

>>> global_thing = True
>>> foo()
[1, 2]
>>> global_thing = False
>>> foo()
[1, 2, 3]

Because this is gnarly, it's yet another reason not to depend so much on
globals. Instead, change the function so its state is passed in
explicitly::

>>> foo(bar=True)
[1, 2]
>>> foo(bar=False)
[1, 2, 3]

Once your functions and tests get complex, you should be using a more
sophisticated testing framework. Don't put complex tests in your
documentation. Instead, put *examples* for readers in the documentation,
and use doctest to test your documentation.

Doctest is for testing explanatory code examples. For more thorough
testing, don't use doctests. Use unit tests with ‘unittests’, feature
tests with Behave http://pypi.python.org/pypi/behave> or something
similar.

-- 
 \  “I tell you the truth: this generation will certainly not pass |
  `\   away until all these things [the end of the world] have |
_o__)   happened.” —Jesus Christ, c. 30 CE, as quoted in Matthew 24:34 |
Ben Finney

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

Re: Add if...else... switch to doctest?

[Terry Reedy]

On 10/18/2012 8:08 PM, David wrote:

Hello, how to add if...else... switch to doctest?
E.g. function outputs different value when global_var change.

"""
if (global_var == True):

function()

[1,2]
else:

function()

[1,2,3]
"""


doctests should/must be self contained. IE, you would have to set the 
'global_var' in the doctext code itself.


>>> def function():
...   if global_var: return [1,2]
...   else: return [1,2,3]
>>> global_var = True
>>>function()
[1,2]
>>> global_var = False
>>> function()
[1,2,3]

--
Terry Jan Reedy

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

Re: A desperate lunge for on-topic-ness

[Steven D'Aprano]

On Thu, 18 Oct 2012 15:59:18 +0200, Jean-Michel Pichavant wrote:

> - Original Message -
>> On 2012-10-18, Zero Piraeus  wrote:
>> 
>> > What are people's preferred strategies for dealing with lines that go
>> > over 79 characters? A few I can think of off the bat:
>> 
>> I try to do what's easiest to read and understand.  Sometimes that
>> means using a line thats 120 characters long, sometimes that means
>> breaking up the line.
>>
>>
> Imo, def. a good approach to the problem. Mark's also pointed the fact
> that the guidelines themselves state that rules are made to be broken
> when they need to be. The 79 char limit purpose is to allow someone to
> read the code on a 80 char terminal (and allow old printers to print the
> code). 

And people who like to have multiple windows open side-by-side.

And people who may have some need to email or post code inline rather 
than as attached files (say, on this list).

And people who may need to run external tools over their code (e.g. grep, 
diff) and view the output in a terminal with, say, 120 character width. 
This allows ~80 characters for the source and ~40 characters for whatever 
extraneous information the tool displays on the same line.

And, quite frankly, people who care more about the readability of their 
code than about squeezing in as much processing into a single line of 
text as possible.

In my not-in-the-slightest-bit-humble opinion, if someone is consistently 
needing more than 79 characters per line, they're probably doing one or 
more of the following coding sins:

- using one-liners for the sake of one liners;
- code that is too deeply nested (if you need more than 3 or 4 indents
  for a block, you're probably doing something wrong);
- doing too much in one line, e.g. overly busy list comps;
- excessively long variable or function names;
- badly designed functions or classes that take too many arguments;
- misuse of Hungarian Notation; and
- violations of the Law of Demeter.

Or possibly they're just unlucky to require a library with excessively 
long names and can't do much about it.

I'm not saying that every line that exceeds 79 characters is crap, but I 
am saying that if you have trouble keeping *at least* 90% of your code 
under 79 characters, you may very well be suffering from poor design, 
lousy code, or both.

Flame away :)



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

Re: A desperate lunge for on-topic-ness

[Steven D'Aprano]

On Thu, 18 Oct 2012 17:36:57 -0400, Zero Piraeus wrote:

> The accepted rule in print is that lines of prose should be between 45
> and 90 characters, with 66 being ideal for readability. Code is not
> prose, and the combination of fixed-width and much more variable line
> length aids readability, but however it came about, ~80 does seem to
> more or less work as a limit.

On the other hand, code is typically *much* harder to understand than 
normal prose.

On the third hand, the "chunks" of semantic meaning in code is 
significantly greater -- you can often ignore 99% of the code and just 
skim past it, and so not even notice long line lengths until you get to 
the specific few lines you care about. But once you reach the lines you 
care about, or *might* care about, horizontal space is costly and 
vertical space is cheap.

So reading code often has two distinct phases: skim and inspect. When 
skimming, vertical space is at a premium, and you want to fit as much 
code as possible in as few lines as possible. When inspecting code 
closely, you want to fit as little code as practical in each line. So 
there's a trade-off.

But for anything but the most horribly obfuscated code, it is much easier 
to identify bits of code that are irrelevant to your problem than to 
identify which bit of code is specifically causing the bug. So skimming 
is inherently easier than close study (well duh). Consequently it is wise 
to optimise your code layout for the hard parts, not the easy parts, and 
so you should treat vertical space is cheaper than horizontal space, and 
try to keep your line length down.

And note that, even when writing, most of your time is problem spent in 
writing what is already there. Coding is rarely like typing out dictation.


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

Re: Add if...else... switch to doctest?

[Steven D'Aprano]

On Thu, 18 Oct 2012 17:08:37 -0700, David wrote:

> Hello, how to add if...else... switch to doctest? 

Step 1): 

Write your doctest with the switch. Don't forget to test both branches:


>>> global_var = True
>>> if global_var:
... function()
... else:
... function()
[1, 2]

>>> global_var = False
>>> if global_var:
... function()
... else:
... function()
[1, 2, 3]


Step 2): realise that this is a stupid thing to do, and re-write the 
doctest without the if test:

>>> global_var = True
>>> function()
[1, 2]
>>> global_var = False
>>> function()
[1, 2, 3]


Step 3): realise that this is a stupid design for a function, you're not 
writing BASIC in 1976, and global variables are harmful. Redesign the 
function to take an argument and re-write the doctest:

>>> function(True)
[1, 2]
>>> function(False)
[1, 2, 3]


And now you have good code and a good doctest.




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

Re: A desperate lunge for on-topic-ness

[Dave Angel]

On 10/18/2012 09:20 PM, Steven D'Aprano wrote:
> On Thu, 18 Oct 2012 12:47:48 -0400, Dave Angel wrote:
>
>> I never use the backslash at end-of-line to continue a statement to the
>> next.  Not only is it a readability problem, but if your editor doesn't
>> have visible spaces, you can accidentally have whitespace after the
>> backslash, and wonder what went wrong.
> What, you don't read the SyntaxError that you will invariably get?
>
>
> # Python 2.7 and 3.3:
>
> py> x = 42 + \
>   File "", line 1
> x = 42 + \
>   ^
> SyntaxError: unexpected character after line continuation character
>
>
>
> Even if you go back to truly ancient Python 1.5:
>
> [steve@ando ~]$ python1.5
> Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 
> 4.1.2-52)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
 x = 42 + \
>   File "", line 1
> x = 42 + \
>   ^
> SyntaxError: invalid token
>
>
> Honestly, it's not that hard to diagnose line continuation errors. It's 
> probably easier to diagnose them than to diagnose missing parentheses.
>
> The more I hear people dissing line continuation backslashes, the more I 
> want to use them everywhere.

The context was both C++ and python, and I got into the habit of
avoiding the continuation characters in C++, where the compiler usually
has a totally stupid error, if any.

it's been so long since I've used them, it's quite possible I never
tried it in python.


-- 

DaveA

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

How to access the document for __call__ from command line?

[Peng Yu]

Hi,

reference.pdf from python document has the following description. It
is not accessible from help() in the command line. Is there an
alternative so that I can quickly access these class attributes or
method names from the command line?

object.__call__(self [, args... ])
Called when the instance is “called” as a function; if this method is
defined, x(arg1, arg2, ...) is a
shorthand for x.__call__(arg1, arg2, ...).

-- 
Regards,
Peng
-- 
http://mail.python.org/mailman/listinfo/python-list