Re: Most Pythonic way to store (small) configuration
Dear Cecil, I subscribed to late to answer to your top-post in that thread. I had the same topic for myself in the last months and tried a lot of things. In your situation I would prefere the INI-file format, too. But doen't user 'configparser' for that. As other fellows described it's a bad solution because option order and comments are not preserved when writing back. It is a quite incomplete implementation of human-readable-config files. Use 'configobj'[1][2] which can be handled very easy, too. You can have comments and everything you want in there. [1] https://pypi.python.org/pypi/configobj [2] https://github.com/DiffSK/configobj -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFQIluABCACfPwAhRAwFD3NXgv5CtVUGSiqdfJGVViVBqaKd+14E0pASA0MU G0Ewj7O7cGy/ZIoiZ0+lIEZmzJKHfuGwYhXjR/PhnUDrQIHLBvh9WuD6JQuULXfH kXtVm/i9wm76QAcvr2pwYgNzhcJntUHl2GcgnInYbZDeVmg+p9yIPJjuq73/lRS3 0/McgNoFOBhKK/S6STQuFyjr9OyJyYd1shoM3hmy+kg0HYm6OgQBJNg92WV9jwGe GzlipvEp2jpLwVsTxYir2oOPhfd9D1fC9F/l/3gXbfjd5GIIVrZFq2haZmoVeJ33 LJxo3RA5Tf9LoUeels1b4s9kFz6h7+AHERUpABEBAAG0IUNocmlzdGlhbiBCdWh0 eiA8YnVodHpAcG9zdGVvLmRlPokBPgQTAQIAKAUCVAiW4AIbAwUJAeEzgAYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AACgkQZLsXsAdRqOxNUAf/V/hDA5zGDpySuCEj DhjiVRK74J9Wd8gfH0WAf1Co5HZ24wZH8rgOIVIgXw8rWkOw/VA6xfdfT+64xjTY Fhkpbrk199nDzp72F7Jc4NC+x8xac2e3rK5ifSWhZx7L5A32pGYE+d16m3EEqImK D4gcZl38x9zdUnD4hHyXkIPz1uCfuMuGgWEnaUk4Wbj41CBZr3O0ABue6regV15U jaes8r+B8iCcY+0yP2kse+3iaCaMqNv5FgQZ9+b2Cql8pFkZJVtBVUw4GW3DWZJi du0O/YrC9TgS+xY9ht/MD2qSHwjcK1sdImjqBO7xP8TIOwKeYyDvGKnSO3EJ/sSA UPGEPrkBDQRUCJbgAQgA0k/Qg67CCUJE2/zuxBEoK4wLJpDRJzh8CQPZpjWx8VP0 KL892jwfxymXn8KNhuy1SgCBFSeV9jg4VZNWDlUGJc2lo82ajr9PzIsrQwu4lf0B zrUWV5hWepKu/kb8uSjx58YYfx0SFz4+9akX3Wwu9TUHntzL5Gk3Q26nnsr1xEJ+ VEumvCH9AE0Tk0K7dQpJ2/JcLuO+uhrpd/lHFDYVN5NsG3P015uFOkDI6N/xNFCj v95XNR93QlfKpK3qWlFGescfG+o/7Ub6s67/i/JoNbw0XgPEHmQfXpD7IHO4cu+p +ETb11cz+1mmi96cy98ID+uTiToJ8G//yD9rmtyxoQARAQABiQElBBgBAgAPBQJU CJbgAhsMBQkB4TOAAAoJEGS7F7AHUajs6sQH/iKs6sPc0vkRJLfbwrijZeecwCWF blo/jzIQ8jPykAj9SLjV20Xwqg3XcJyko8ZU6/zuRJq9xjlv9pZr/oVudQAt6v+h 2Cf4rKEjmau483wjMV2xjTXQhZi9+ttDbia4fgdmGtKsOicn5ae2fFXcXNPu3RiW sZKifWdokA6xqMW6iIG9YjjI5ShxngHWp2xfPscBFMDRtFOMags/Yx+YvwoyEZ4A dURYMFHFqpwILEc8hIzhRg1gq40AHbOaEdczS1Rr3T7/gS6eBs4u6HuY5g2Bierm lLjpspFPjMXwJAa/XLOBjMF2vsHPrZNcouNKkumQ36yq/Pm6DFXAseQDxOk= =PGP9 -END PGP PUBLIC KEY BLOCK- -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
- Original Message - > From: "Cecil Westerhof" > To: python-list@python.org > Sent: Sunday, 2 August, 2015 12:11:28 PM > Subject: Most Pythonic way to store (small) configuration > > There are a lot of ways to store configuration information: > - conf file > - xml file > - database > - json file > - and possible a lot of other ways > > I want to write a Python program to display cleaned log files. I do > not think I need a lot of configuration to be stored: > - some things relating to the GUI > - default behaviour > - default directory > - log files to display, including some info > - At least until where it was displayed > > Because of this I think a human readable file would be best. > Personally I do not find XML very readable. So a conf or json file > looks the most promising to me. And I would have a slight preference > for a json file. > > Any comments, thoughts or tips? > > -- > Cecil Westerhof > Senior Software Engineer > LinkedIn: http://www.linkedin.com/in/cecilwesterhof > -- > https://mail.python.org/mailman/listinfo/python-list Did you consider using "serpent" ? It's a python serializer than can produce human readable text format. If your configuration is a dictionary for instance, there's possibly no work to do. see for yourself at : https://pypi.python.org/pypi/serpent Regards, JM -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Uninstall
How do I uninstall Python from a Mac? -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix Talks & Videos: Python Idioms Talk
ANNOUNCING eGenix Talks & Videos: Python Idioms Talk EuroPython 2015 This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/EuroPython-2015-Python-Idioms.html EuroPython 2015 in Bilbao, Basque Country, Spain Marc-André Lemburg, Python Core Developer, one of the EuroPython 2015 organizers and Senior Software Architect, held a talk at EuroPython focusing on programmers just starting with Python. We have now turned the talk into a video presentations for easy viewing and also released the presentation slides. Python Idioms to help you write good code Talk given at the EuroPython 2015 conference in Bilbao, Basque Country, Spain, presenting Python idioms which are especially useful for programmers new to Python. Talk video and slides: http://www.egenix.com/library/presentations/EuroPython-2015-Python-Idioms/ Python focuses a lot on writing readable code and also tries to make solutions obvious, but this doesn’t necessarily mean that you cannot write unreadable code or design your code in ways which makes it hard to extend or maintain. The talk shows some useful idioms to apply when writing Python code, how to structure your modules and also goes into details on which techniques to use and which to think about twice, based on 20 years of experience writing Python. -- Marc-André Lemburg More interesting eGenix presentations are available in the presentations and talks community section of our website. http://www.egenix.com/library/presentations/ PYTHON COACHING AND CONSULTING If you are interested in learning more about these advanced techniques, eGenix now offers Python project coaching and consulting services to give your project teams advice on how to design Python applications, successfully run projects, or find excellent Python programmers. Please contact our eGenix Sales Team for information. http://www.egenix.com/services/ INFORMATION About Python (http://www.python.org/): Python is an object-oriented Open Source programming language which runs on all modern platforms. By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for today's IT challenges. About eGenix (http://www.egenix.com/): eGenix is a software project, consulting and product company focusing on expert project services and professional quality products for companies, Python users and developers. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 04 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 May Become Relevant Now
On Aug 3, 2015 17:46, "Rick Johnson" wrote: > > On Sunday, August 2, 2015 at 9:45:51 PM UTC-5, Chris Angelico wrote: > > How do you know it was written today, if you didn't click it? > > Because i possess skills you can hardly fathom. There are always > loopholes; back doors; knot holes; key holes; cracks; crevices; > tells; Freudian slips; little white lies; and yes, even arthropods > creeping and crawling in dark corners fitted with multiple visual > sensors -- all one need do is discover them, and then *EXPLOIT* them! > -- That sounds like a lot more work than simply clicking a link. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
you can't fully uninstall python from OSX, linux, BSD as there are many python dependent system tools -- https://mail.python.org/mailman/listinfo/python-list
Re: __main__ vs official module name: distinct module instances
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.08.2015 05:53, Cameron Simpson wrote: > When invoked this way, the module cs.app.maildb that is being > executed is actually the module named "__main__". If some other > piece of code imports "cs.app.maildb" they get a _different_ > instance of the module. In the same program! And how did it cause > me trouble? I am monkey patching my module for debug purposes, and > that monkey patcher imports the module by name. So I was monkey > patching cs.app.maildb, and _not_ patching __main__. And thus not > seeing any effect from the patch. > So I guess you just explained my issues with Flask and trying to wrap an application up in __main__.py. Thank you. And also, +1 on your proposal, please bring it to -ideas. regards, jwi -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVwLMlAAoJEMBiAyWXYliKJSAP/i+UUJpQyVZVhTYAGax3ZPak MWhdvGpQhq5iJIDImBJCGtiLtt+8Qy/UuJC4sAbz080XRJs9V3goYWCdZABpynln VOCbd1vvTHadmOxTjX98D++bIg4ZFvaWFruk/TYcx35GtbQb52/LH6nq4b8EpMY+ 1wFdMQ8ccUixiMbvEeNtgRWw4g2fG5LGceiT1Hs9ThVlin5di0jjAz4MrZa49eNt tdTMQBaoap+yL1VXU10e+2vF8EiqtmfQwrRME2WLglJcYw8p2WMe+FLHvGVpKu9+ nVkZfWHBjOA9Ym4HdugCCiQPW12R/kuExrixjw6FYKeb7QXaF67yjWUXVOAW2XcP oaTIk4+U4WoeMReVyRzyWLPShKKaoR5djJbpKFW8GzD1XHulh/CWWuL/R1rt+LSF e5ME6HvKVZoh+4QT4CcL6K8Gv+w5RbgFXPidREuZzavXCQVo2IoCOs2JCClBu4Gy zy8tYk8gt5+8bub74Bkm6+FhdwMNQgKRCpXkgoqj5EgKEkeWiPl0d89geUq6PC0x boSKVDn1rg2OmQWSjqKs+rUHK6XSVt4C+P6pb/lW9zsAs87AfQcjdrG6xaC2+dKo /YeZVvq0Y1PCf6IIjPGp5DsKkN1bJtvUPGFH8ZFY+xZ/nHYI/UToKoo7cF5J2xf/ 0h2t4lfozMVs9fswpHlz =ITon -END PGP SIGNATURE- -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import a function from another module...
> Thank you, Steven. > I am a newbie with Python? so I really want to learn how to do it the easy > way. > Yes, could you tell me how to put the py.file that contains the function > in the Python search path??? > BIG SMILE... > Always, Dwight > www.3forliving.key.to (video playlist on YouTube) > www.couragebooks.key.to (all my books on Amazon) > On 8/4/15, 9:24 AM, "Steven D'Aprano" wrote: >> >On Tue, 4 Aug 2015 09:57 am, Dwight GoldWinde wrote: >> > >>> >> I am trying to import a function defined in another module. >> > >> >You can't use spaces in the name of importable Python modules: change the >> >name from "Simulate typing.py" to "simulate_python.py". You can use spaces >> >in file names if they are only used as a runnable script and not imported. >> > >> >Then use this: >> > >> >from simulate_python import humprint >> > >> >There's no need to use importlib. >> > >> >You may need to arrange for the simulate_python file to be placed >> >somewhere >> >in the Python search path. Do you need help with that? >> > >> >What you are trying to do with importlib is fight the language. Your life >> >will be much simpler if you work within the parameters of how the language >> >is designed to work. >> > >> > >> > >> >-- >> >Steven >> > >> >-- >> >https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: how to determine for using c extension or not ?
On 2015年08月04日 03:11, Terry Reedy wrote: Posting three times under two different names is not polite. Please to not repeat. sorry... You should not care. If you think there is an undocumented difference in behavior, ask here if it is a bug. I don't think a bug in this question. I expect that that test/test_bisect.py runs the same tests on both versions. We have a test helper function for such situations. I didn't know test/support.py and support.import_fresh_module() function. I will use this function if I write some C accelerator. thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to determine for using c extension or not ?
On 2015年08月04日 00:05, Oscar Benjamin wrote: On Mon, 3 Aug 2015 at 15:58 umedoblock mailto:umedobl...@gmail.com>> wrote: I use "bisect.bisect.__module__" sentence to determine for using c extension or not. Why do you want to know if it uses the C extension? It shouldn't really matter. I wrote some C accelerator. I sometimes want to know that python3.x in another machine use C accelerator or not. Because if python3.x doesn't use C acc, I shuold make C acc for another machine. Therefore I'd like to determine for using C acc or not. And I want to know that another machine use C acc or not to use a simple script. But I had felt not good idea about my way to use id(). So I ask this mailing list. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On 2015-08-04, milos zorica wrote: > you can't fully uninstall python from OSX, linux, BSD as there are many > python dependent system tools Well, technically you _can_ uninstall Python if you really want, but all sorts of things will stop working. In some cases, it's very hard to recover from that situation. Among the things that will stop working on some flavors of Linux are the system utilities you normally use to install things like Python. -- Grant Edwards grant.b.edwardsYow! World War III? at No thanks! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Sunday, August 2, 2015 at 12:14:51 PM UTC+2, Cecil Westerhof wrote:
> There are a lot of ways to store configuration information:
> - conf file
> - xml file
> - database
> - json file
> - and possible a lot of other ways
>
> I want to write a Python program to display cleaned log files. I do
> not think I need a lot of configuration to be stored:
> - some things relating to the GUI
> - default behaviour
> - default directory
> - log files to display, including some info
> - At least until where it was displayed
>
> Because of this I think a human readable file would be best.
> Personally I do not find XML very readable. So a conf or json file
> looks the most promising to me. And I would have a slight preference
> for a json file.
>
> Any comments, thoughts or tips?
>
> --
> Cecil Westerhof
> Senior Software Engineer
> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Why not use Python files itself as configuration files?
I have done so several times and I am very pleased with
it. I have tried both INI and JSON, but in the end always
settled on using Python itself. If I have to share the
configuration information with other languages (like C++
or Javascript) I use JSON as the
For those who are interested, I provide a short summary
below on how I handle configuration files.
The scenario I want to support is that there is a hierarchical
set of configuration files (as typically found in Unix like
systems) that can be stored in a system wide folder (like
/etc/app), in a user folder (like /home/user/.config/app) and
in a local folder.
Each configuration file has a fixed name, not necessarily ending
in ".py". So for example, the name of the configuration file
is "config.myapp".
Next I start looking for the existence of these files and once
I find them I start merging all the configuration settings into
one Python dictionary. The function that I use can be found below.
(you need proper import statements, but this is standard Python).
def load_config(config_file, checked=False):
'''Small utility function to load external configuration files.
'''
if checked is False:
if not isfile(config_file) or islink(config_file):
msg = 'Config file "%s" does not exist.'
LOGGER.warning(msg)
return {}
# Load the module object; we use the imp.load_source function because
# the module configuration typically has a non-standard file extension
# (by default the file is called "config.myapp")
module_name = 'm%s' % str(uuid.uuid1()).replace('-', '')
# Prevent bytecode generation for configuration files
sys.dont_write_bytecode = True
config_module = imp.load_source(module_name, config_file)
# Continue with bytecode generation for other normal modules
sys.dont_write_bytecode = False
if not hasattr(config_module, '__config__'):
msg = 'Missing "__config__" attribute in configuration file.'
LOGGER.warning(msg)
return {}
else:
return config_module.__config__
--
https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
that's my point -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import a function from another module...
On Tuesday, August 4, 2015 at 3:11:41 PM UTC+2, Dwight GoldWinde wrote:
> Thank you, Steven.
> I am a newbie with Python? so I really want to learn how to do it the easy
> way.
> Yes, could you tell me how to put the py.file that contains the function
> in the Python search path???
>
>
>
> BIG SMILE...
>
> Always, Dwight
>
>
> www.3forliving.key.to (video playlist on YouTube)
> www.couragebooks.key.to (all my books on Amazon)
>
>
>
>
>
>
>
>
> On 8/4/15, 9:24 AM, "Steven D'Aprano" wrote:
>
> >On Tue, 4 Aug 2015 09:57 am, Dwight GoldWinde wrote:
> >
> >> I am trying to import a function defined in another module.
> >
> >You can't use spaces in the name of importable Python modules: change the
> >name from "Simulate typing.py" to "simulate_python.py". You can use spaces
> >in file names if they are only used as a runnable script and not imported.
> >
> >Then use this:
> >
> >from simulate_python import humprint
> >
> >There's no need to use importlib.
> >
> >You may need to arrange for the simulate_python file to be placed
> >somewhere
> >in the Python search path. Do you need help with that?
> >
> >What you are trying to do with importlib is fight the language. Your life
> >will be much simpler if you work within the parameters of how the language
> >is designed to work.
> >
> >
> >
> >--
> >Steven
> >
> >--
> >https://mail.python.org/mailman/listinfo/python-list
Hi Dwight,
There are at least two ways to manipulate your search path, one from
within Python, one by setting/updating an environmental variable
in your operating system.
1. Dynamically add a search path in Python
First note that if you want to know which parts are currently
in the Python search path you can do the following (note that >>>
means type it in the Python shell and I am using Python 2 syntax)
>>> import sys
>>> for path in sys.path:
... print path
So, if you want to add a folder to your search path, in your
script add the following *before* you access attributes etc.
from the module your are trying to use:
sys.path.append("the_path_that_contains_the_py_file")
# Import stuff from the py file here
The downside of this approach is that you have to do this
in every script that accesses information from your ".py"
file. If you want to do this once and for all, use the
second method
2. Setting/updating the environment variable
You can use the environment variable PYTHONPATH to inform
Python on which search paths it should use (besides the
default ones).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On 4-8-2015 16:53, marco.naw...@colosso.nl wrote: > Why not use Python files itself as configuration files? It could create a security risk if the config files are user-editable. (it will make it easy to inject code into your application) Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Tuesday, August 4, 2015 at 7:06:33 PM UTC+2, Irmen de Jong wrote: > On 4-8-2015 16:53, marco.naw...@colosso.nl wrote: > > Why not use Python files itself as configuration files? > > It could create a security risk if the config files are user-editable. > (it will make it easy to inject code into your application) > > Irmen Yes, I am aware of the security risk, but right now I am not too worried about it. To be honest, JSON would be my preferred configuration file format, but as others already mentioned, there is no standard way of adding comments to a JSON file. Marco -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Tuesday, August 4, 2015 at 7:29:29 AM UTC-7, Grant Edwards wrote: > On 2015-08-04, milos zorica wrote: > > > you can't fully uninstall python from OSX, linux, BSD as there are many > > python dependent system tools > > Well, technically you _can_ uninstall Python if you really want, but > all sorts of things will stop working. In some cases, it's very hard > to recover from that situation. Among the things that will stop > working on some flavors of Linux are the system utilities you normally > use to install things like Python. > > -- > Grant Edwards grant.b.edwardsYow! World War III? > at No thanks! > gmail.com milos: "You can't uninstall Python because it will break things" Grant: "Actually, you CAN uninstall Python, but it will break things" I really fucking hate how pedantic some of the people on this mailing list are. milos wasn't wrong. You just chose to take his message too literally. I thought it was pretty clear that when milos said "can't", he really meant "shouldn't". -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
marco.naw...@colosso.nl writes: > Why not use Python files itself as configuration files? Because configuration data will be user-editable. (If it's not user-editable, that is itself a poor design choice.) If you allow executable code to be user-edited, that opens your program to arbitrary injection of executable code. Your program becomes wide open for security exploits, whether through malicious or accidental bugs, and simple human error can lead to arbitrary-scope damage to the user's system. On another dimension, configuration files specifying the behaviour of the system are much more useful if their format is easily parsed and re-worked by tools the user chooses. Your program should not be the only tool (and Python should not be the only language) that can read and/or write the configuration data with straightfoward data manipulation. So a complex full-blown programming language like Python is a poor choice for configuration data for that reason, too. Much better to choose a tightly-defined, limited-scope configuration data format that you can be confident any user cannot employ to run arbitrary code. -- \ “For myself, I am an optimist — it does not seem to be much use | `\ being anything else.” —Winston Churchill, 1954-11-09 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On 04/08/2015 19:31, sohcahto...@gmail.com wrote: On Tuesday, August 4, 2015 at 7:29:29 AM UTC-7, Grant Edwards wrote: On 2015-08-04, milos zorica wrote: you can't fully uninstall python from OSX, linux, BSD as there are many python dependent system tools Well, technically you _can_ uninstall Python if you really want, but all sorts of things will stop working. In some cases, it's very hard to recover from that situation. Among the things that will stop working on some flavors of Linux are the system utilities you normally use to install things like Python. -- Grant Edwards grant.b.edwardsYow! World War III? at No thanks! gmail.com milos: "You can't uninstall Python because it will break things" Grant: "Actually, you CAN uninstall Python, but it will break things" I really fucking hate how pedantic some of the people on this mailing list are. milos wasn't wrong. You just chose to take his message too literally. I thought it was pretty clear that when milos said "can't", he really meant "shouldn't". The simple solution is not to subscribe. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Linux script to get most expensive processes
Under Linux I like to get the most expensive processes. The two most
useful commands are:
ps -eo pid,user,pcpu,args --sort=-pcpu
and:
ps -eo pid,user,pcpu,args --sort=-vsize
In my case I am only interested in the seven most expensive processes.
For this I wrote the following script.
#!/usr/bin/env python3
import subprocess
import sys
def give_output(param):
output = subprocess.check_output(([
'ps',
'--columns={0}' .format(max_line_length),
'-eo',
'pid,user,start_time,{0},args'.format(param),
'--sort=-{0}' .format(param)
])).splitlines()
for line in output[:no_of_lines]:
print(line.decode('utf-8'))
accepted_params = {
'pcpu',
'rss',
'size',
'time',
'vsize',
}
current_platform= sys.platform
max_line_length = 200
needed_platform = 'linux'
no_of_lines = 8 # One extra for the heading
if current_platform != needed_platform:
raise Exception('Needs a {0} platform, got {1} platform'.
format(needed_platform, current_platform))
no_of_parameters = len(sys.argv) - 1
if no_of_parameters == 0:
to_check = 'pcpu'
elif no_of_parameters == 1:
to_check = sys.argv[1]
else:
raise Exception('Too many arguments')
if (to_check != 'all') and not(to_check in accepted_params):
raise Exception('Used illegal parameter: {0}'.format(to_check))
if to_check == 'all':
for param in sorted(accepted_params):
give_output(param)
print()
else:
give_output(to_check)
Is this a reasonable way to do this? Getting the parameter is done
quit simple, but I did not think fancy was necessary here.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On 8/4/2015 1:19 PM, Cecil Westerhof wrote: Under Linux I like to get the most expensive processes. The two most useful commands are: ps -eo pid,user,pcpu,args --sort=-pcpu and: ps -eo pid,user,pcpu,args --sort=-vsize In my case I am only interested in the seven most expensive processes. For this I wrote the following script. Is this a reasonable way to do this? Getting the parameter is done quit simple, but I did not think fancy was necessary here. My platform shows as linux2 and it worked fine for me when checking for that. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On Tuesday 4 Aug 2015 22:52 CEST, Emile van Sebille wrote:
> On 8/4/2015 1:19 PM, Cecil Westerhof wrote:
>> Under Linux I like to get the most expensive processes. The two
>> most useful commands are: ps -eo pid,user,pcpu,args --sort=-pcpu
>> and: ps -eo pid,user,pcpu,args --sort=-vsize
>>
>> In my case I am only interested in the seven most expensive
>> processes. For this I wrote the following script.
>
>> Is this a reasonable way to do this? Getting the parameter is done
>> quit simple, but I did not think fancy was necessary here.
>
>
> My platform shows as linux2 and it worked fine for me when checking
> for that.
I heard that that was possible also, but none of my systems gives
this. I should change it. I was also thinking about posix systems, but
the Linux ps does more as others, so I did not do that.
I amended the code to work with linux and linux2:
accepted_params = {
'pcpu',
'rss',
'size',
'time',
'vsize',
}
accepted_platforms = {
'linux',
'linux2',
}
current_platform= sys.platform
max_line_length = 200
no_of_lines = 8 # One extra for the heading
is_good_platform= False
for platform in accepted_platforms:
if platform == current_platform:
is_good_platform = True
break
if not is_good_platform:
raise Exception('Got an incompatiple platform: {0}'.
format(current_platform))
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On 2015-08-04 22:30, Cecil Westerhof wrote:
On Tuesday 4 Aug 2015 22:52 CEST, Emile van Sebille wrote:
On 8/4/2015 1:19 PM, Cecil Westerhof wrote:
Under Linux I like to get the most expensive processes. The two
most useful commands are: ps -eo pid,user,pcpu,args --sort=-pcpu
and: ps -eo pid,user,pcpu,args --sort=-vsize
In my case I am only interested in the seven most expensive
processes. For this I wrote the following script.
Is this a reasonable way to do this? Getting the parameter is done
quit simple, but I did not think fancy was necessary here.
My platform shows as linux2 and it worked fine for me when checking
for that.
I heard that that was possible also, but none of my systems gives
this. I should change it. I was also thinking about posix systems, but
the Linux ps does more as others, so I did not do that.
I amended the code to work with linux and linux2:
accepted_params = {
'pcpu',
'rss',
'size',
'time',
'vsize',
}
accepted_platforms = {
'linux',
'linux2',
}
current_platform= sys.platform
max_line_length = 200
no_of_lines = 8 # One extra for the heading
is_good_platform= False
for platform in accepted_platforms:
if platform == current_platform:
is_good_platform = True
break
if not is_good_platform:
raise Exception('Got an incompatiple platform: {0}'.
format(current_platform))
Doesn't that 'for' loop do the same as:
is_good_platform = current_platform in accepted_platforms
?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Tuesday, August 4, 2015 at 2:32:16 PM UTC-4, sohca...@gmail.com wrote: > milos: "You can't uninstall Python because it will break things" > Grant: "Actually, you CAN uninstall Python, but it will break things" > > I really fucking hate how pedantic some of the people on this mailing list > are. > > milos wasn't wrong. You just chose to take his message too literally. I > thought it was pretty clear that when milos said "can't", he really meant > "shouldn't". While I am often dismayed at the pedantry on this list (and many others), in this case, I think the clarification was warranted. When a beginner is about to attempt something dangerous, it is prudent to be sure the instructions are clear. "You can't uninstall, because things won't work" sounds a bit like, "you literally will not be able to uninstall things, because the operating system will prevent you because it protects itself." I wouldn't want the next message to be the original asker saying, "No, look, I was able to uninstall just fine!" without realizing they were damaging their system. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On 8/4/2015 2:30 PM, Cecil Westerhof wrote: On Tuesday 4 Aug 2015 22:52 CEST, Emile van Sebille wrote: My platform shows as linux2 and it worked fine for me when checking for that. I heard that that was possible also, but none of my systems gives this. I should change it. You could also use the platform module: >>> import platform >>> platform.system() 'Linux' >>> Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On Wednesday 5 Aug 2015 00:12 CEST, Emile van Sebille wrote: > On 8/4/2015 2:30 PM, Cecil Westerhof wrote: >> On Tuesday 4 Aug 2015 22:52 CEST, Emile van Sebille wrote: > >>> My platform shows as linux2 and it worked fine for me when >>> checking for that. >> >> I heard that that was possible also, but none of my systems gives >> this. I should change it. > > You could also use the platform module: > > import platform platform.system() > 'Linux' I already use sys, so I think sys.platform is a little better. ;-) -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux script to get most expensive processes
On Wednesday 5 Aug 2015 00:00 CEST, MRAB wrote:
>> I amended the code to work with linux and linux2:
>>
>> accepted_params = { 'pcpu', 'rss', 'size', 'time', 'vsize', }
>> accepted_platforms = { 'linux', 'linux2', } current_platform =
>> sys.platform max_line_length = 200 no_of_lines = 8 # One extra for
>> the heading
>>
>> is_good_platform = False for platform in accepted_platforms: if
>> platform == current_platform: is_good_platform = True break if not
>> is_good_platform: raise Exception('Got an incompatiple platform:
>> {0}'. format(current_platform))
>>
>>
> Doesn't that 'for' loop do the same as:
>
> is_good_platform = current_platform in accepted_platforms
You are right. Not very smart. Especially because I use the ‘in’ a
little later.
It now is:
if not current_platform in accepted_platforms:
raise Exception('Got an incompatiple platform: {0}'.
format(current_platform))
And I do not need is_good_platform anymore.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On 08/04/2015 01:59 PM, Ben Finney wrote: > marco.naw...@colosso.nl writes: > >> Why not use Python files itself as configuration files? > > Because configuration data will be user-editable. (If it's not > user-editable, that is itself a poor design choice.) > > If you allow executable code to be user-edited, that opens your program > to arbitrary injection of executable code. Your program becomes wide > open for security exploits, whether through malicious or accidental > bugs, and simple human error can lead to arbitrary-scope damage to the > user's system. We need to state the context here. The only context in which having a Python config file is dangerous is when the python program runs as a different user/privilege than the owner of the config file. If the user owns the python files as well as the config file then none of this matters. In most cases, I've never bought the argument you and others are making here about security and demanding yet another DSL. In fact I find the argument to be rather circular in that we're dealing with programs that aren't compiled but written in Python anyway. I can open and edit any python file in the project that I want and make arbitrary, possibly "malicious" changes to it! Oh no! The idea that a malicious user could inject python code in this instance and somehow deliberately harm the system is kind of silly if you think about it. It's me that's running the python code in the first place. I could open any file and change it. I'm already running arbitrary code. If I'm talking about a system service that is doing things for non-root users, then yeah I'll agree with your argument completely. But not for most other situations. Even a system service, if the config file is owned by root, I'm okay with using python as configuration. Because if root's compromised, all bets are off anyway and all the python scripts could be modified. In fact python as configuration works very well for my purposes, and it works well for Django, and there are many other projects that also do this. I don't think you'd want to use any other mechanism for configuring Django, frankly. I'm a bit surprised no one has mentioned Django in this discussion yet. In many of my projects I put basic config variables in a file like config.py and import that in each module that needs it. The config module doubles as a global namespace for sharing between modules as well. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Tue, Aug 4, 2015 at 9:01 PM, Mark Lawrence wrote: > On 04/08/2015 19:31, sohcahto...@gmail.com wrote: > >> On Tuesday, August 4, 2015 at 7:29:29 AM UTC-7, Grant Edwards wrote: >> >>> On 2015-08-04, milos zorica wrote: >>> >>> you can't fully uninstall python from OSX, linux, BSD as there are many python dependent system tools >>> >>> Well, technically you _can_ uninstall Python if you really want, but >>> all sorts of things will stop working. In some cases, it's very hard >>> to recover from that situation. Among the things that will stop >>> working on some flavors of Linux are the system utilities you normally >>> use to install things like Python. >>> >>> -- >>> Grant Edwards grant.b.edwardsYow! World War III? >>>at No thanks! >>>gmail.com >>> >> >> milos: "You can't uninstall Python because it will break things" >> Grant: "Actually, you CAN uninstall Python, but it will break things" >> >> I really fucking hate how pedantic some of the people on this mailing >> list are. >> >> milos wasn't wrong. You just chose to take his message too literally. I >> thought it was pretty clear that when milos said "can't", he really meant >> "shouldn't". >> >> > The simple solution is not to subscribe. > > Or even better, tell you to fuck off. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Tuesday, August 4, 2015 at 9:51:27 PM UTC-4, Mario Figueiredo wrote: > On Tue, Aug 4, 2015 at 9:01 PM, Mark Lawrence wrote: >> >> The simple solution is not to subscribe. > > > Or even better, tell you to fuck off. Can we please try to stay civil? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Tue, Aug 4, 2015 at 11:06 PM, Ned Batchelder wrote: > > On Tuesday, August 4, 2015 at 2:32:16 PM UTC-4, sohca...@gmail.com wrote: > > milos: "You can't uninstall Python because it will break things" > > Grant: "Actually, you CAN uninstall Python, but it will break things" > > > > I really fucking hate how pedantic some of the people on this mailing list are. > > > > milos wasn't wrong. You just chose to take his message too literally. I thought it was pretty clear that when milos said "can't", he really meant "shouldn't". > > While I am often dismayed at the pedantry on this list (and many others), > in this case, I think the clarification was warranted. When a beginner > is about to attempt something dangerous, it is prudent to be sure the > instructions are clear. > > "You can't uninstall, because things won't work" sounds a bit like, > "you literally will not be able to uninstall things, because the operating > system will prevent you because it protects itself." > > I wouldn't want the next message to be the original asker saying, "No, > look, I was able to uninstall just fine!" without realizing they were > damaging their system. > Pedantry sort of comes with the territory. It's in the job description, so to speak. DJ Wiza should know that. There's that used joke of the programmer's wife that asks him to bring 3 loaves of bread and if there are any eggs to bring a dozen, and the programmer brings her wife a dozen loaves of bread. But being an asshole does not. That is something one chooses to become. Your answer squarely puts you in the group of people that chose to be in life to be a pain to others and actually gain the respect of even those that don't even know them. Unlike some other people in here. But Mark is right in a way... People like him is a reason I rarely frequent this place anymore. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Wed, Aug 5, 2015 at 3:08 AM, Mario Figueiredo wrote: > > But being an asshole does not. That is something one chooses to become. Your answer squarely puts you in the group of people that chose to be in life to be a pain to others [...] An ugly mistyping there completely changed the meaning of what I intended to say. For clarification, I mean to say: "Your answer squarely puts you in the group of people that DIDN'T chose to be in life to be a pain to others" -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On 04Aug2015 19:32, Michael Torrie wrote: On 08/04/2015 01:59 PM, Ben Finney wrote: marco.naw...@colosso.nl writes: Why not use Python files itself as configuration files? Because configuration data will be user-editable. (If it's not user-editable, that is itself a poor design choice.) If you allow executable code to be user-edited, that opens your program to arbitrary injection of executable code. [...] We need to state the context here. The only context in which having a Python config file is dangerous is when the python program runs as a different user/privilege than the owner of the config file. If the user owns the python files as well as the config file then none of this matters. [...] If I'm talking about a system service that is doing things for non-root users, then yeah I'll agree with your argument completely. But not for most other situations. Even a system service, if the config file is owned by root, I'm okay with using python as configuration. [...] In fact python as configuration works very well for my purposes, and it works well for Django, and there are many other projects that also do this. I don't think you'd want to use any other mechanism for configuring Django, frankly. I'm a bit surprised no one has mentioned Django in this discussion yet. [...] Django crossed my mind as well, but my take is very different. I'm of two minds on Django's use of Python files for config. On the one hand it is very flexible, it can express comoplicated/subtle(/fragile?) setups as needs and, if you are writing the Django app instead of just using it, it is in the same language as the app. On the other hand, if you want to consult that config from _outside_ the app with another tool not necessarily written in Python you're screwed. Many things can read a .ini file. Very few things can read arbitrary Python code, and any that can _must_ expose themselves to whatever that code may do. If the consulting code is in a different security context (system config monitors, admin scripts, etc) then we're back in the risk zone. So on the whole I am against python code as the config file format. Really, who needs a Turing complete configuration file? Go with something simple, both in syntax and semantics. It is easier to read, easier to write/modify, and easier to access from multiple tools. Cheers, Cameron Simpson A protocol is complete when there is nothing left to remove. - Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Tue, Aug 4, 2015, at 21:32, Michael Torrie wrote: > In many of my projects I put basic config variables in a file like > config.py and import that in each module that needs it. The config > module doubles as a global namespace for sharing between modules as well. What about JSONP? That is, a file consisting exactly of "config_data = [JSON object]" That would get you some of the benefits of having your config file exist as a python module, but still allow it to be examined by other tools, written out, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
On Wednesday, August 5, 2015 at 7:49:10 AM UTC+5:30, Mario Figueiredo wrote: > On Wed, Aug 5, 2015 at 3:08 AM, Mario Figueiredo wrote: > > > > But being an asshole does not. That is something one chooses to become. > > Your answer squarely puts you in the group of people that chose to be in > > life to be a pain to others [...] > > > An ugly mistyping there completely changed the meaning of what I intended to > say. For clarification, I mean to say: "Your answer squarely puts you in the > group of people that DIDN'T chose to be in life to be a pain to others" And nobody's yet asked whether the python on the mac the OP wants to uninstall is the system python or something he added later -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On 08/04/2015 08:44 PM, random...@fastmail.us wrote: > On Tue, Aug 4, 2015, at 21:32, Michael Torrie wrote: >> In many of my projects I put basic config variables in a file like >> config.py and import that in each module that needs it. The config >> module doubles as a global namespace for sharing between modules as well. > > What about JSONP? That is, a file consisting exactly of "config_data = > [JSON object]" That would get you some of the benefits of having your > config file exist as a python module, but still allow it to be examined > by other tools, written out, etc. But I don't need it to be examined by other tools. So the added complication of yet another layer isn't worth it or needed. Python's syntax is simple enough that a person with a text editor can certainly do it. Again, context is everything. My programs are written for mostly my own use. If I was writing a system that was like, say, Apache, I would certainly do a DSL with a robust error checking and reporting system that could clearly help people with syntax errors, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On 08/04/2015 08:19 PM, Cameron Simpson wrote: > So on the whole I am against python code as the config file format. Really, > who > needs a Turing complete configuration file? In Django's case, since you're intimately referring to certain classes and methods, particularly in the url mapping section, I think using straight Python is the way to go. It's the most flexibility for the least amount of work. And someone working with Django already has familiarity with both Django and Python. I'm sure everything could be put in a DSL, but then you'd be inventing a subset of Python anyway. And like I say, since the same person editing the config file is also editing the other Django project files, the issue of code injection is moot; he's already doing that! So for the OP's case, if his needs are simple like mine are, then a simple python file he imports could be just fine. I'm hard pressed to make a case for something different if the needs are simple like that. > Go with something simple, both in syntax and semantics. It is easier to read, > easier to write/modify, and easier to access from multiple tools. Python as configuration is simpler for my purposes, in both ways. And multiple tools for me == text editors. I have no need of machine-generated config files. Maybe Cecil doesn't either. Such tools are of limited use anyway in my experience. For example webadmin never cut it for me. Neither did the old web-based Samba configurater. -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Wednesday, August 5, 2015 at 10:19:11 AM UTC+5:30, Michael Torrie wrote: > On 08/04/2015 08:44 PM, wrote: > > On Tue, Aug 4, 2015, at 21:32, Michael Torrie wrote: > >> In many of my projects I put basic config variables in a file like > >> config.py and import that in each module that needs it. The config > >> module doubles as a global namespace for sharing between modules as well. > > > > What about JSONP? That is, a file consisting exactly of "config_data = > > [JSON object]" That would get you some of the benefits of having your > > config file exist as a python module, but still allow it to be examined > > by other tools, written out, etc. > > But I don't need it to be examined by other tools. So the added > complication of yet another layer isn't worth it or needed. Python's > syntax is simple enough that a person with a text editor can certainly > do it. Again, context is everything. My programs are written for > mostly my own use. If I was writing a system that was like, say, > Apache, I would certainly do a DSL with a robust error checking and > reporting system that could clearly help people with syntax errors, etc. I think the main point is Cameron's > So on the whole I am against python code as the config file format. Really, > who needs a Turing complete configuration file? stated more strongly: I sure dont want to use something Turing complete from something that is inherently more trivial. And if the cost is of matching the trivial format to the trivial-izing reader (say json) it seems like a small price to pay. In the past Ive always recommended yaml even though the cost is higher -- a separate install [yeah Ive had clients tell me that yaml's out because of that] [Does yaml have comments?] -- https://mail.python.org/mailman/listinfo/python-list
Re: Uninstall
Right. Try "which python" in the terminal and report back! Cheers Paul -- https://mail.python.org/mailman/listinfo/python-list
GOTCHA with list comprehension
Hi, I recently found interesting GOTCHA while doing list comprehension in python 2.6: >>> values = ( True, False, 1, 2, 3, None ) >>> [ value for value in values if value if not None ] [True, 1, 2, 3] I was wondering why this list comprehension returns incorrect results and finally found a typo in the condition. The typo wasn't visible at the first look. My intention was: if value is not None But I wrote: if value if not None Is that a language feature of list comprehension that it accepts conditions like: if A if B if C if D ...? -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
Rustom Mody writes: > Does yaml have comments? Yes, the same syntax as Python's. ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
