ANN: v0.3 of pipe_controller released; supports swapping pipe components at run time
I've released v0.3 of pipe_controller (*), my experimental tool to simulate pipes in Python: https://bitbucket.org/vasudevram/pipe_controller (*) I had earlier been calling it PipeController, but that is the name of the main class in the package. From now on I'm referring to it as pipe_controller (the Python module name). Changes in v0.3: - you can now swap components of a pipe_controller pipe at run time, and it can separately save the results of running the pipe, before and after a component swap, to separate output files; the test program test_pipe_controller_04.py in the download package shows how to do this. That is, you can do something like this (using UNIX syntax, though pipe_controller is in Python and works differently): foo | bar | baz # with output going to file 1 then swap the positions of foo and baz, then run the pipe again: baz | bar | foo # with output going to file 2 and so on - any number of times, all in the same program run. This feature lets you experiment with, and validate, your pipeline logic, to make sure that it does what you intended, e.g. you can check the output both before and after swapping components of the pipe, to decide which order you really need - or which order is optimal - see next paragraph. The feature can also be used to time the execution of two or more different versions of the pipeline (with vs. without swapping of components), to see which runs faster, for cases where changing the order of those components makes no difference to the output, e.g. if those two components are commutative, in the mathematical sense (like a + b = b + a). Blog post about swapping pipe components at run time with pipe_controller: http://jugad2.blogspot.in/2012/10/swapping-pipe-components-at-runtime.html pipe_controller v0.3 can be downloaded here: https://bitbucket.org/vasudevram/pipe_controller/downloads (Click on the Branches tab on that page) - Vasudev Ram www.dancingbison.com jugad2.blogspot.com twitter.com/vasudevram -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
pyNVML - GPU Monitoring and Management
I'm pleased to announce the release of pyNVML 3.304: Python Bindings for the NVIDIA Management Library. pyNVML provides programmatic access to static information and monitoring data for NVIDIA GPUs, as well as management capabilities. It exposes the functionality of the NVML library. See http://developer.nvidia.com/nvidia-management-library-nvml for more information about NVML. The pyNVML download package and its documentation can be found at: http://pypi.python.org/pypi/nvidia-ml-py/ http://packages.python.org/nvidia-ml-py/ pyNVML is currently used to report GPU information in Ganglia. Check it out at http://developer.nvidia.com/ganglia-monitoring-system Requires Python 2.5, or an earlier version with the ctypes module. Released under the BSD license. Download the latest supported driver at http://developer.nvidia.com/cuda/cuda-downloads Robert Alexander NVIDIA Tesla Software Engineer --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
A desperate lunge for on-topic-ness
: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On Thu, Oct 18, 2012 at 5:06 PM, Zero Piraeus sche...@gmail.com 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: 1. Say screw it and go past 79, PEP8 be damned. 6. Realise that if it's that long, it probably shouldn't have been a list comprehension in the first place. Depending on how far past, I'd be most inclined to one of these. I don't consider the eightieth character position to be sacrosanct, but on the other hand, I'm not going to go thousands of characters to the right. Most of my development screens will happily go to ~200 characters, definitely above 100, so I tend to write a bit wider than PEP 8 demands. Generally I'd not look at splitting a line until it goes over 100-120 characters. (And even then, I won't automatically split it. I've been known to write some rather long lines of code.) When I do split, it's usually by dividing the line into multiple logical actions; if the split looks like type #5, I'll not split it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Aggressive language on python-list
On Oct 18, 10:18 am, Zero Piraeus sche...@gmail.com wrote: : On 18 October 2012 00:36, rusi rustompm...@gmail.com wrote: Unfortunately, I feel this whole discussion/thread has got derailed: Zero you started this thread about aggressive behavior. It does not seem to me that this was the case you were talking of, was it? Sorry, but I'm having trouble parsing that sentence. Could you rephrase it? I understood that your original post started after Etienne's outburst against Steven. David's outbursts are relatively harmless. I tried to talk gently to him http://mail.python.org/pipermail/python-list/2012-September/631949.html And then gave up http://mail.python.org/pipermail/python-list/2012-September/631950.html Not that I mind: People much wiser than we have expressed that war is the most horrible thing in the universe and David is by his own admission a war-damaged individual. If Steven chooses to engage him thats his call If Alex chooses to fight with him thats his I am betting that in the end, rurpy's suggestion -- Ignoring is the best policy -- or Ben's -- Respond carefully, minimally and with caution -- is what everyone will have to come to. This does not mean I dont wish him well, just that I realize that the sphere of my action and influence are intrinsically limited. And all this misses the point that you started this thread (I think) with Etienne-Steven in mind not David-RestOfTheWorld. (Assuming this conjecture) I would like to say: Etienne is not a 'dick' or a 'troll' just a human being with the same buggy wetware that we all have whose logic goes: If you call me an asshole (when justified) I'll call you can asshole (even if not). Likewise Alex calling David racist may be justified but is not helpful. IOW the robustness principle http://en.wikipedia.org/wiki/Robustness_principle is as good for human networking as for computers. [BTW This was enunciated 2000 years ago by a clever chap: Love your enemies; drive them crazy] -- http://mail.python.org/mailman/listinfo/python-list
Re: Aggressive language on python-list
On Thu, Oct 18, 2012 at 2:19 AM, rusi rustompm...@gmail.com wrote: On Oct 18, 10:18 am, Zero Piraeus sche...@gmail.com wrote: : On 18 October 2012 00:36, rusi rustompm...@gmail.com wrote: Unfortunately, I feel this whole discussion/thread has got derailed: Zero you started this thread about aggressive behavior. It does not seem to me that this was the case you were talking of, was it? Sorry, but I'm having trouble parsing that sentence. Could you rephrase it? I understood that your original post started after Etienne's outburst against Steven. David's outbursts are relatively harmless. I tried to talk gently to him http://mail.python.org/pipermail/python-list/2012-September/631949.html And then gave up http://mail.python.org/pipermail/python-list/2012-September/631950.html Not that I mind: People much wiser than we have expressed that war is the most horrible thing in the universe and David is by his own admission a war-damaged individual. If Steven chooses to engage him thats his call If Alex chooses to fight with him thats his I am betting that in the end, rurpy's suggestion -- Ignoring is the best policy -- or Ben's -- Respond carefully, minimally and with caution -- is what everyone will have to come to. This does not mean I dont wish him well, just that I realize that the sphere of my action and influence are intrinsically limited. And all this misses the point that you started this thread (I think) with Etienne-Steven in mind not David-RestOfTheWorld. (Assuming this conjecture) I would like to say: Etienne is not a 'dick' or a 'troll' just a human being with the same buggy wetware that we all have whose logic goes: If you call me an asshole (when justified) I'll call you can asshole (even if not). Likewise Alex calling David racist may be justified but is not helpful. IOW the robustness principle http://en.wikipedia.org/wiki/Robustness_principle is as good for human networking as for computers. [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. ] -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On Thu, 18 Oct 2012 02:06:19 -0400, 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:
1. Say screw it and go past 79, PEP8 be damned.
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.
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.
2. Say screw it and break the line using a backslash.
Low on my preference list, but occasionally.
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 know PEP 8 says I should drop the final round bracket to the next line,
but I don't normally like that.
4. Spend 45 minutes trying to think up shorter [but still sensible]
variable names to make it fit.
Ha! Since most of my variable names are already relatively short, that's
not often much help.
5. Perform an otherwise pointless assignment to a temp variable on the
previous line to make it fit.
Hardly ever.
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.
6. Realise that if it's that long, it probably shouldn't have been a
list comprehension in the first place.
What if it wasn't a list comp in the first place? :)
Refactoring code makes most long lines go away on their own.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Change computername
Thank you, I will test this, will keep you posted. Anatoli On Wed, Oct 17, 2012 at 7:47 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Oct 17, 2012 at 8:07 AM, Anatoli Hristov toli...@gmail.com 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: A desperate lunge for on-topic-ness
3. Say well, at least it's not a backslash and break the line using parentheses. This. More times than not, there's a function call in that line, which makes sense to me when reading it if the args are on the next line. 4. Spend 45 minutes trying to think up shorter [but still sensible] variable names to make it fit. I generally can't shorten my variable names without breaking the minimum length PEP8 rule ;) Now having said that, it kind of depends on the code base I'm working with. If it's my own project, I never go past 79 characters (vim tw=79). However, if it's a code base that I didn't start and it seems to consistently go past 79 characters, I'll usually follow suit (with my feet dragging of course). Nothing worse than inconsistency, even if it's a standard I don't necessarily agree with :P -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest for system testing
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
On Oct 18, 11:06 am, Zero Piraeus sche...@gmail.com 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
Zero Piraeus sche...@gmail.com 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
: On 18 October 2012 02:19, rusi rustompm...@gmail.com 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
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
On Oct 18, 11:27 am, David Hutto dwightdhu...@gmail.com 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
: On 18 October 2012 03:18, chip9m...@gmail.com 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
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
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 toli...@gmail.com wrote: Thank you, I will test this, will keep you posted. Anatoli On Wed, Oct 17, 2012 at 7:47 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Oct 17, 2012 at 8:07 AM, Anatoli Hristov toli...@gmail.com 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
: On 18 October 2012 04:10, chip9m...@gmail.com 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
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
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
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
Hi,
I have a html string in an object, when I do repr() of that object, I get value
as:
{'Id' : 1, 'Body': u'p Hello /p'}
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
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
On Thu, Oct 18, 2012 at 2:27 AM, Ashish Jain ashishjain@gmail.com 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'p Hello /p'}
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
On 10/18/2012 02:19 AM, rusi wrote: snip 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
On Thu, Oct 18, 2012 at 8:07 PM, Hans Mulder han...@xs4all.nl 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
: On 18 October 2012 05:22, chip9m...@gmail.com 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 comp.lang.pyt...@googlegroups.com and python-list@python.org, 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
On 10/18/12 6:43 AM, David Hutto wrote: On Thu, Oct 18, 2012 at 1:29 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Thu, Oct 18, 2012 at 8:22 PM, chip9m...@gmail.com 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
On Thu, Oct 18, 2012 at 7:22 PM, Anatoli Hristov toli...@gmail.com 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
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'p Hello /p'}
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
:
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
steve+comp.lang.pyt...@pearwood.info 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, 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'
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
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()
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 module
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()
On Thu, Oct 18, 2012 at 10:41 PM, lars van gemerden
l...@rational-it.com 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
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
On 2012-10-18, Zero Piraeus sche...@gmail.com 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
On 2012-10-18, andrea crotti andrea.crott...@gmail.com 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
2012/10/18 Grant Edwards invalid@invalid.invalid: On 2012-10-18, andrea crotti andrea.crott...@gmail.com 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
On 18 October 2012 14:44, andrea crotti andrea.crott...@gmail.com wrote: 2012/10/18 Grant Edwards invalid@invalid.invalid: On 2012-10-18, andrea crotti andrea.crott...@gmail.com 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
On 2012-10-18, andrea crotti andrea.crott...@gmail.com wrote: 2012/10/18 Grant Edwards invalid@invalid.invalid: On 2012-10-18, andrea crotti andrea.crott...@gmail.com 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
- Original Message - On 2012-10-18, Zero Piraeus sche...@gmail.com 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()
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
l...@rational-it.com 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()
On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden l...@rational-it.com 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
On 18 October 2012 15:10, Jeff Jeffries jeff.jeffries@gmail.com 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
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()
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 l...@rational-it.com 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
On 18 October 2012 15:49, andrea crotti andrea.crott...@gmail.com wrote:
2012/10/18 Grant Edwards invalid@invalid.invalid:
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
2012/10/18 Oscar Benjamin oscar.j.benja...@gmail.com: 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
On Thu, Oct 18, 2012 at 10:51 AM, Dave Angel d...@davea.name 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
On 10/18/2012 04:02 AM, Zero Piraeus wrote: On 18 October 2012 05:22, chip9m...@gmail.com 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 comp.lang.pyt...@googlegroups.com and python-list@python.org, 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 (python-list@python.org) 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()
On Fri, Oct 19, 2012 at 2:00 AM, lars van gemerden l...@rational-it.com 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
On 18 October 2012 16:08, andrea crotti andrea.crott...@gmail.com wrote: 2012/10/18 Oscar Benjamin oscar.j.benja...@gmail.com: 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
On Wed, Oct 17, 2012 at 11:06 PM, Zero Piraeus sche...@gmail.com 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
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
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
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
On 2012-10-17, Dwight Hutto dwightdhu...@gmail.com 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
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
On 2012-10-18, Den patents...@gmail.com 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
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
On Fri, Oct 19, 2012 at 2:49 AM, Dan Stromberg drsali...@gmail.com 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
On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti ne...@norwich.edu 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
On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll drisc...@cs.wisc.edu 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
On 10/18/2012 12:26 PM, Chris Angelico wrote: On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll drisc...@cs.wisc.edu 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
On Thu, Oct 18, 2012 at 9:47 AM, Dave Angel d...@davea.name wrote: On 10/18/2012 12:26 PM, Chris Angelico wrote: On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll drisc...@cs.wisc.edu 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
On 10/18/2012 12:58 PM, Chris Kaynor wrote: On Thu, Oct 18, 2012 at 9:47 AM, Dave Angel d...@davea.name wrote: SNIP 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
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
On 2012-10-18, Den patents...@gmail.com 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
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
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
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
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
On 18 October 2012 12:05, Tim Chase python.l...@tim.thechases.com 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
Chris Angelico wrote: On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti ne...@norwich.edu 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
David Hutto wrote: On Wed, Oct 17, 2012 at 7:12 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
David Hutto wrote: On Wed, Oct 17, 2012 at 12:38 PM, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: David Hutto wrote: On Wed, Oct 17, 2012 at 2:06 AM, Demian Brecht demianbre...@gmail.com 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
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
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
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
On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit ramit.pra...@jpmorgan.com 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
On Thu, Oct 18, 2012 at 8:42 PM, Demian Brecht demianbre...@gmail.com 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
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 ramit.pra...@jpmorgan.com 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
On Thu, Oct 18, 2012 at 10:47 AM, Dave Angel d...@davea.name 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
: On 18 October 2012 12:03, chip9m...@gmail.com 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
: On 18 October 2012 11:55, Den patents...@gmail.com 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)
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)
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
On Thu, Oct 18, 2012 at 12:43 PM, Daniel Urban urban.d...@gmail.com 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)
In article 53b38fa2-ea8b-4225-bdf3-b9bcbde31...@o5g2000yqi.googlegroups.com, Peng Yu pengyu...@gmail.com 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)
In article 5b80dd153d7d744689f57f4fb69af4741671d...@scacmx008.exchad.jpmchase.net , Prasad, Ramit ramit.pra...@jpmorgan.com 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
On Thursday 18 October 2012 18:40:52 Grant Edwards did opine: On 2012-10-18, Den patents...@gmail.com 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: http://coyoteden.dyndns-free.com:85/gene 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?
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
Hi there, I am parsing some huge xml files (1.8 Gb) that look like this:
scan num='1'
peakssome data/peaks
scan num='2'
peakssome data/peaks
/scan
scan num='3'
peakssome data/peaks
/scan
/scan
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
Zero Piraeus sche...@gmail.com 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
Hans Mulder han...@xs4all.nl 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
Jean-Michel Pichavant jeanmic...@sequans.com 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
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 stdin, 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 stdin, 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
