ANN: eGenix PyRun - One file Python Runtime 1.1.0
ANNOUNCING eGenix PyRun - One file Python Runtime Version 1.1.0 An easy-to-use single file relocatable Python run-time - available for Windows, Mac OS X and Unix platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-PyRun-1.1.0.html INTRODUCTION Our new eGenix PyRun combines a Python interpreter with an almost complete Python standard library into a single easy-to-use executable, that does not require a system wide installation and is fully relocatable. eGenix PyRun's executable only needs 11MB, but still supports most Python application and scripts - and it can be further compressed to 3-4MB using gzexe or upx. Compared to a regular Python installation of typically 100MB on disk, this makes eGenix PyRun ideal for applications and scripts that need to be distributed to many target machines, client installations or customers. It makes "installing" Python on a Unix based system as simple as copying a single file. We have been using the product internally in our mxODBC Connect Server since 2008 with great success and have now extracted it into a stand-alone open-source product. We provide both the source archive to build your own eGenix PyRun, as well as pre-compiled binaries for Linux, FreeBSD and Mac OS X, as 32- and 64-bit versions. Please see the product page for more details: http://www.egenix.com/products/python/PyRun/ NEWS This is a new minor release of eGenix PyRun, which contains a few important fixes and enhancement based on the user feedback we received. Simplified Installation --- The new release includes a new script called install-pyrun, which greatly simplifies installation of eGenix PyRun, which works much like the virtualenv shell script used for creating new virtual environments (except that there's nothing virtual about PyRun environments :-)). Using the script, the eGenix PyRun installation is as simple as running: install-pyrun targetdir New Features * Added new simple end-to-end test for the PyRun build process: make test-distribution. * Added support to import top-level frozen modules via -m. For packages this still fails due to bugs in Python itself. * Added a new easy to use pyrun installation shell script: install-pyrun. * install-pyrun will now default to eGenix PyRun 1.1.0. * install-pyrun now has a new --pyrun-distribution option to manually direct the script to a distribution file. This comes in handy when testing your own eGenix PyRun distributions. Enhanced Integration * Optional readline module included in our binary builds now links against readline version 6 instead of 5. This should resolve readline issues on modern Linux installations. * Resolved an issue related to sys.argv[0] that prevented installation of e.g. numpy and lxml with pyrun. We've tested PyRun installation with numpy, lxml, Cython, Django, Trac and several other popular packages. They should all install fine now. * PyRun now reads scripts from stdin when used as filter or when providing '-' as script name. Other Changes - * Documented that setuptools/distribute and pip are not designed to be relocatable - unlike PyRun itself. * Most references to the pyrun build directory are now replaced with "". This reduces the pyrun binary size and also avoids confusion when looking at tracebacks. * Backported a patch to have Python 2.5 compile on systems that have a more recent version of svnversion installed. * Overall, we've managed to push the size down from 12MB in 1.0.0 to 11MB in this new release. Thanks go to Pavlos Christoforou for providing lots of good feedback, which triggered many of the above enhancements. Presentation at PyCon UK 2012 - Marc-André, CEO of eGenix, will be giving a presentation about eGenix PyRun at PyCon UK 2012 in Coventry, UK on Saturday, Sept 29th in the Room Python/CC1.8. He will also be available during the conference to answer questions. DOWNLOADS The download archives and instructions for installing the product can be found at: http://www.egenix.com/products/python/PyRun/ ___ SUPPORT Commercial support for these packages is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. MORE INFORMATION For more information about eGenix PyRun, licensing a
Re: Memory usage per top 10x usage per heapy
MrsEntity wrote: > Based on heapy, a db based solution would be serious overkill. I've embraced overkill and my life is better for it. Don't confuse overkill with cost. Overkill is your friend. The facts of the case: You need to save some derived strings for each of 2M input lines. Even half the input runs over the 2GB RAM in your (virtual) machine. You're using Ubuntu 12.04 in Virtualbox on Win7/64, Python 2.7/64. That screams "sqlite3". It's overkill, in a good way. It's already there for the importing. Other approaches? You could try to keep everything in RAM, but use less. Tim Chase pointed out the memory-efficiency of named tuples. You could save some more by switching to Win7/32, Python 2.7/32; VirtualBox makes trying such alternatives quick and easy. Or you could add memory. Compared to good old 32-bit, 64-bit operation consumes significantly more memory and supports vastly more memory. There's a bit of a mis-match in a 64-bit system with just 2GB of RAM. I know, sounds weird, "just" two billion bytes of RAM. I'll rephrase: just ten dollars worth of RAM. Less if you buy it where I do. I don't know why the memory profiling tools are misleading you. I can think of plausible explanations, but they'd just be guesses. There's nothing all that surprising in running out of RAM, given what you've explained. A couple K per line is easy to burn. -Bryan -- http://mail.python.org/mailman/listinfo/python-list
Module baldy compiled to pyc?
Today I had a strange experience. I have copied some updated py files (modules) to a directory on a remote server, overwritting the old ones. The pyc files on the server were older. Many programs are importing these modules, and most of them are started as background jobs (from cron). They started to throw all kinds of errors. I checked the py files, and they did have class definitions inside. However when I tried to use them I got AttributeError exceptions. Telling that those things are not in the module. I checked their contents by importing them, and they were not defined indeed. Finally I have checked the module.__file__ attributes to see that they are imported from the right place. The __file__ contained the path to the compiled pyc file, but the path was correct. So finally I have deleted all pyc files, and suddenly every program was working again. (Starting the interpreter again and importing the modules again did not solve the problem.) I suspect that there were two (or more) programs starting at the same time, writting the same pyc file at the same time. It happened with two modules today. Over the years, I have always copied files to this server, and let background programs compile the pyc files as needed. I have never experienced anything like this before, and I cannot reproduce the error. The question is this: do you think this could happen? Is it possible that something else caused the problem? What else could it be? What are the chances that it will happen again, and how can I prevent it? Thanks, Laszlo -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27.09.12 09:08, Chris Angelico wrote: LAMP usually means PHP these days. There's a lot of that around. And Cyrillic Р means Ruby. :-P -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, 26 Sep 2012 08:45:30 -0700, wxjmfauth wrote:
> Sorry guys, I'm "only" able to see this (with the Python versions an end
> user can download):
[snip timeit results]
While you have been all doom and gloom and negativity that Python has
"destroyed" Unicode, I've actually done some testing. It seems that,
possibly, there is a performance regression in the "replace" method.
This is on Debian squeeze, using the latest rc version of 3.3, 3.3.0rc3:
py> timeit.repeat("('b'*1000).replace('b', 'a')")
[28.308280900120735, 29.012173799797893, 28.834429003298283]
Notice that Unicode doesn't come into it, they are pure ASCII strings.
Here's the same thing using 3.2.2:
py> timeit.repeat("('b'*1000).replace('b', 'a')")
[3.618225097656, 3.147739887237549, 3.132185935974121]
That's a factor of 9 slowdown in 3.3, and no Unicode. Obviously Python
has "destroyed ASCII".
(I get similar slowdowns for Unicode strings too, so clearly Python hates
all strings, not just ASCII.)
Now, for irrelevant reasons, here I swapped to Centos.
[steve@ando ~]$ python2.7 -m timeit "'b'*1000"
100 loops, best of 3: 0.48 usec per loop
[steve@ando ~]$ python3.2 -m timeit "'b'*1000"
100 loops, best of 3: 1.3 usec per loop
[steve@ando ~]$ python3.3 -m timeit "'b'*1000"
100 loops, best of 3: 0.397 usec per loop
Clearly 3.3 is the fastest at string multiplication, at least for this
trivial example. Just to prove that the result also applies to Unicode:
[steve@ando ~]$ python3.3 -m timeit "('你'*1000)"
100 loops, best of 3: 1.38 usec per loop
Almost identical to 3.2. And the reason it is slower than the 3.3 test
using 'b' above is almost certainly because the string uses four times
more memory:
[steve@ando ~]$ python3.3 -m timeit "('abcd'*1000)"
100 loops, best of 3: 0.919 usec per loop
So a little slower that the pure-ASCII version for the same amount of
memory, but not significantly so.
But add a call to replace, and things are very different:
[steve@ando ~]$ python2.7 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
10 loops, best of 3: 9.3 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
10 loops, best of 3: 5.43 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
10 loops, best of 3: 18.3 usec per loop
Three times slower, even for pure-ASCII strings. I get comparable results
for Unicode. Notice how slow Python 2.7 is:
[steve@ando ~]$ python2.7 -m timeit -s "s = u'你'*1000" "s.replace(u'你', u'a')"
1 loops, best of 3: 65.6 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = '你'*1000" "s.replace('你', 'a')"
10 loops, best of 3: 2.79 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = '你'*1000" "s.replace('你', 'a')"
1 loops, best of 3: 23.7 usec per loop
Even with the performance regression, it is still over twice as fast as
Python 2.7.
Nevertheless, I think there is something here. The consequences are nowhere
near as dramatic as jmf claims, but it does seem that replace() has taken a
serious performance hit. Perhaps it is unavoidable, but perhaps not.
If anyone else can confirm similar results, I think this should be raised as
a performance regression.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
CherryPy is in the list now. http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Thanks. Andriy > From: andriy.kornats...@live.com > To: python-list@python.org > Subject: RE: Fastest web framework > Date: Tue, 25 Sep 2012 13:52:25 +0300 > > > The post has been updated with two more frameworks (per community request): > tornado and web2py. > > Comments or suggestions are welcome. > > Thanks. > > Andriy Kornatskyy > > > > > From: andriy.kornats...@live.com > > To: python-list@python.org > > Subject: Fastest web framework > > Date: Sun, 23 Sep 2012 12:19:16 +0300 > > > > > > I have run recently a benchmark of a trivial 'hello world' application for > > various python web frameworks (bottle, django, flask, pyramid, web.py, > > wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might > > find it interesting: > > > > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html > > > > Comments or suggestions are welcome. > > > > Thanks. > > > > Andriy Kornatskyy > > > > -- > > http://mail.python.org/mailman/listinfo/python-list > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Hi Sorry guys, I'm "only" able to see this (with the Python versions an end user can download): [snip timeit results] While you have been all doom and gloom and negativity that Python has "destroyed" Unicode, I thought that jmf's concerns were solely concerned with the selection of latin1 as the 1 byte set. My impression was that if some set of characters was chosen that included all characters commonly used in French then all would be well with the world. But now I'm confused because latin1 seems to cater for French quite well: http://en.wikipedia.org/wiki/ISO/IEC_8859-1 -- Regards Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Module baldy compiled to pyc?
On Thu, 27 Sep 2012 11:00:36 +0200, Laszlo Nagy wrote: > Today I had a strange experience. I have copied some updated py files > (modules) to a directory on a remote server, overwritting the old ones. > The pyc files on the server were older. Many programs are importing > these modules, and most of them are started as background jobs (from > cron). They started to throw all kinds of errors. I checked the py > files, and they did have class definitions inside. However when I tried > to use them I got AttributeError exceptions. Telling that those things > are not in the module. It sounds to me like the timestamps on the .py files were messed up when you copied them, causing Python to prefer old, broken .pyc files instead of the newer .py files. > I suspect that there were two (or more) programs starting at the same > time, writting the same pyc file at the same time. I suppose that's not impossible, although you would need to check the Python source code to be sure. But I would expect that each process writes the .pyc file atomically, so even if two processes both try to create the .pyc file, one will harmlessly overwrite the other's output. I would be surprised if it were possible for two processes to simultaneously write to the same file -- that would require the Python compiler to explicitly open the .pyc file in shared writable mode, and why would it do that? Far more likely is a file system error. I recommend you run a disk check on the file server and see if it comes up with any errors. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms using Python?
Wayne Werner於 2012年9月27日星期四UTC+8上午12時05分31秒寫道： > On Fri, 21 Sep 2012, Dennis Lee Bieber wrote: > > > > > On Fri, 21 Sep 2012 14:26:04 +0530, Mayuresh Kathe > > > declaimed the following in gmane.comp.python.general: > > > > > >> Is there a good book on foundational as well as advanced algorithms > > >> using Python? > > >> > > > Depends on what you mean by "foundational"... > > > > > > Since Python has dynamic lists and dictionaries, I suspect you won't > > > find any textbook focusing on linked-list or hashed lookup algorithms > > > using Python. > > > > > > You can probably implement them, but they're not going to be very > > > efficient. (And never "remove" an element from the linked-list > > > implementation because Python would shift all the other elements, hence > > > your "links" become invalid). > > > > It's quite inefficient, but it would be fairly trivial to create a LL > > implementation like this: > > > > class Link: > > def __init__(self): > > self.next = None > > self.value = None > > > > class LinkedList: > > def __init__(self): > > self.head = None > > > > def add(self, value): > > node = Link() > > node.value = value > > self.append(node) > > > > def append(self, node): > > # Write some code > > > > It's fairly easy to use reference types as one would use pointers in > > . > > > > But it might actually require understanding pointers and such in the first > > place... > > > > I'm not really aware of any algorithm that's impossible/harder to > > implement in Python - Python just makes most things a lot easier so you > > never have to deal with the lower level algorithms. Which makes *me* happy > > :) > > > > -Wayne In python long integers of varried lengths of precesions, doubles, complex numbers, immutable tuples, modifiable lists, modifiable dictionaries, and functions and classes are all name resolved basic built in types. It is more interesting to implement a binary tree in python from a dictionary. Also the set part can be implemented by long integers or dictionaries. The symbolic computation part as in sympy is also a good example of high level programmings in python. But this also means a lot kids will finish their calculous homeworks trivially by machines instead of reasoning and learning in person. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano wrote: > On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: > And a response: > > http://data.geek.nz/python-is-doing-just-fine Summary of that article: "Sure, you have all these legitimate concerns, but look, cake!" -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27.09.12 12:33, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I think this should be raised as a performance regression. Yes, I confirm, it's a performance regression. It should be avoidable. Almost any PEP393 performance regression can be avoided. At least for such corner case. Just no one has yet optimized this case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 2012-09-27, Chris Angelico wrote: > On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano > wrote: > >> Given how Perl has slipped in the last decade or so, that would be a step >> backwards for Python :-P > > LAMP usually means PHP these days. There's a lot of that around. Yea, unfortunately. What a mess of a language. I recently had to learn enough PHP to make some changes to a web site we had done by an outside contractor. PHP feels like it was designed by taking a half-dozen other languages, chopping them into bits and then pulling random features/syntax/semantics at random from the various different piles. Those bits where then stuck together with duct tape and bubble gum and called PHP... As one of the contractors who wrote some of the PHP said: "PHP is like the worst parts of shell, Perl, and Java all combined into one language!" -- Grant Edwards grant.b.edwardsYow! Did something bad at happen or am I in a gmail.comdrive-in movie?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: > On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano > wrote: >> On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a >> response: >> >> http://data.geek.nz/python-is-doing-just-fine > > Summary of that article: > > "Sure, you have all these legitimate concerns, but look, cake!" Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, "Well, maybe, your concerns *might* be legitimate, but I don't think so because..." and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards wrote: > On 2012-09-27, Chris Angelico wrote: >> On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano >> wrote: >> >>> Given how Perl has slipped in the last decade or so, that would be a step >>> backwards for Python :-P >> >> LAMP usually means PHP these days. There's a lot of that around. > > Yea, unfortunately. What a mess of a language. I recently had to > learn enough PHP to make some changes to a web site we had done by an > outside contractor. PHP feels like it was designed by taking a > half-dozen other languages, chopping them into bits and then pulling > random features/syntax/semantics at random from the various different > piles. Those bits where then stuck together with duct tape and bubble > gum and called PHP... > > As one of the contractors who wrote some of the PHP said: "PHP is like > the worst parts of shell, Perl, and Java all combined into one > language!" I can't remember where I read it, and I definitely don't know if it's accurate to current thinking, but the other day I found a quote purporting to be from the creator of PHP saying that he didn't care about memory leaks, just restart Apache periodically. It's definitely true of most PHP scripts that they're unconcerned about resource leakage, on the assumption that everything'll get cleared out at the end of a page render. PHP seems to encourage sloppiness. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: ERROR:root:code for hash md5 was not found
I had that problem after moving my Python installation into another directory. Reinstalling Python helped. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 4:43 AM, Alex Strickland wrote: > I thought that jmf's concerns were solely concerned with the selection of > latin1 as the 1 byte set. My impression was that if some set of characters > was chosen that included all characters commonly used in French then all > would be well with the world. > > But now I'm confused because latin1 seems to cater for French quite well: > > http://en.wikipedia.org/wiki/ISO/IEC_8859-1 I understand ISO 8859-15 (Latin-9) to be the preferred Latin character set for French, as it includes the Euro sign as well as a few characters that are not in Latin-1 but are nonetheless infrequently found in French. -- http://mail.python.org/mailman/listinfo/python-list
Client Needs Sr. Java Developer, Sacramento, CA
Good Day, We have an urgent Contract Opening in Sr.Java Developer Looking forward to submit your resume for below mentioned Requirement… If you are interested, Please forward your latest resume along with location and pay rate details to r...@tech-netinc.com asked at the bottom of mail Job Title: Sr. Java Developer Location: Sacramento, CA Duration: 12+ Months Required Skills: • J2EE • SOA • Web services(Strong, i.e., 3-4 years) • Oracle pl/sql • UNIX platform • Full Name: • Current Location: • Pay Rate : • Contact Details: • Email: • Availability: • Visa Status: • Relocation to : • Last 4-digits of SSN: • References: • Ready for Telephonic discussion during office hours Thanks, Ram Dev Recruiter Tech-Net Inc. Tel: 916-458-4390 Ext 102 Email: r...@tech-netinc.com -- http://mail.python.org/mailman/listinfo/python-list
Re: #python archives?
On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano wrote: > My google-foo is failing me. Is the #python chatroom on freenode archived > anywhere on the web? #python doesn't have a policy against quiet bots that log channel interaction, but AFAIK there are no up-to-date public logs. As evidence to this, a certain anti-logging freenode user hasn't pestered #python ever since the last logging bot was banned (because of unrelated reasons). Is there any particular reason you want the logs? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Ordering of mailbox.mbox contents?
Reading through the docs[1] and the source, I'm trying to discern if there's any guarantee that the contents of a mbox file remain in a consistent ordering across add/delete calls. As best I can tell from the source, it _looks_ like the code keeps an existing file in the same order, deletions remove without changing the order, and additions append at the end of the file in the order they're added. That's what I'd expect. Is this accurate, or have I missed anything? Thanks, -tkc [1] http://docs.python.org/library/mailbox.html#mbox -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 13:46, Serhiy Storchaka wrote: On 27.09.12 12:33, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I think this should be raised as a performance regression. Yes, I confirm, it's a performance regression. It should be avoidable. Almost any PEP393 performance regression can be avoided. At least for such corner case. Just no one has yet optimized this case. I have taken a liberty and raised this on the bug tracker quoting Steven D'Aprano's original figures and your response above. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano wrote: > On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: > >> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano >> wrote: >>> On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a >>> response: >>> >>> http://data.geek.nz/python-is-doing-just-fine >> >> Summary of that article: >> >> "Sure, you have all these legitimate concerns, but look, cake!" > > Did you read the article or just make up a witty response? If so, you > half succeeded. > > It's more like, "Well, maybe, your concerns *might* be legitimate, but I > don't think so because..." and then he gives half a dozen or more reasons > why Python is in no danger. None of which involve cake, although one of > them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. If we're going to have a serious discussion about the problems Python faces in the future, then the topics that Calvin brings up are relevant. These are problems that, ideally, we would overcome. And I think, to some degree, we are working towards a future where these problems are solved. (Except perhaps the game development one, which is a rather tough problem in a lot of ways.) As people have noted, we do have Kivy, we do have PyPy, we do have PyJS and other such things. The future has possibilities for the problems Calvin mentions to be solved, even if they are problems today. The article that was linked, the response, it doesn't talk about this. When Calvin says that Python has problems with mobile, the article doesn't even say "but Kivy does mobile" -- it says "but Science people love Python!" When Calvin says that Python has problems being done on the web, the article doesn't even say "but PyJS!" (regardless of the problems of relying on a hijacked project), it says "education loves Python!" When Calvin says that Python has failed for game development, the article doesn't try to explain any way that Python is moving to success here, or any way that Calvin's assessment is wrong. Instead, it says, "But The Web loves Python!" There is a pattern here. The pattern is that the article does not actually directly respond to anything Calvin said. It doesn't try to carry a dialogue about concerns about problem areas Python has. It ignores Python's problems, and focuses on its strengths. Charitably, maybe we'd call this a way of encouraging people who are discouraged by the bleaker tone of Calvin's post. And that's valid, if we're worried about morale. Definitely Calvin's post could be -- and has been -- taken the wrong way. It could be taken as a way of saying, "Python is doomed!", even though that isn't something Calvin ever wrote (he appears, from my reading, to be more worried about a stagnating community than a failed language). Under that interpretation, we would want other, more encouraging voices around, talking about ways in which Python is good and will survive. Uncharitably, it's just a way of hiding one's head in the sand, ignoring any problems Python has by focusing on what problems it doesn't have. So that's why I said that the summary is, "but look, cake!". Instead of being a dialogue about improving Python, it's a distraction from the issues Calvin brought up. It brings up strengths, which are also part of Python, but don't have much at all to do with Python's weaknesses, or with what Calvin was talking about. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 17:16, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano wrote: On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: "Sure, you have all these legitimate concerns, but look, cake!" Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, "Well, maybe, your concerns *might* be legitimate, but I don't think so because..." and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. [snipped] -- Devin The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 07:13, Steven D'Aprano wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: Hi all, I though this might be of interest. http://www.ironfroggy.com/software/i-am-worried-about-the-future-of- python And a response: http://data.geek.nz/python-is-doing-just-fine Well there's definite proof that the PyPy people are all completely incompetent in a response on the above link, this is how easy it is "But ... why does the runtime environment have to be so limiting? Operations involving primitives could be easily compiled (on the fly - JIT) to machine code and more advanced objects exist as plug-ins. Oh, and it would be nice to be able to write such objects quickly and easily - not the convoluted mess that it is currently." Simples :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence wrote: > The article Steven D'Aprano referred to is not a direct response to the > article I referred to, yet your words are written as if it were. May I ask > why? Or have I missed something? Steven cited it with the words "And a response". ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 12:45 PM, Mark Lawrence wrote: > The article Steven D'Aprano referred to is not a direct response to the > article I referred to, yet your words are written as if it were. May I ask > why? Or have I missed something? Post hoc ergo propter hoc :( -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 17:49, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence wrote: The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? Steven cited it with the words "And a response". ChrisA Fair enough, we'll blame Steven on the grounds that he's Antipodean :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
RE: How to limit CPU usage in Python
Paul Rubin wrote: > Rolando Cañer Roblejo writes: > > Is it possible for me to put a limit in the amount of processor usage > > (% CPU) that my current python script is using? Is there any module > > useful for this task? > > One way is check your cpu usage once in a while, compare with elapsed > time, and if your % usage is above what you want, sleep for a suitable > interval before proceeding. > > Tim Roberts: reasons to want to do this might involve a shared host > where excessive cpu usage affects other users; or a computer with > limited power consumption, where prolonged high cpu activity causes > thermal or other problems. The problem is that checking the CPU usage is fairly misleading if you are worried about contention. If your process takes up 100% of CPU and nothing else needs the resource, does it matter? I would not want to sleep *unless* something else needs the resource. Of course, there might be a good/easy way of checking usage + contention, but I am unaware of any off the top of my head. On *nix you should just set the appropriate nice-ness and then let the OS handle CPU scheduling. Not sure what you would do for Windows--I assume OS X is the same as *nix for this context. 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: How to limit CPU usage in Python
On Thu, Sep 27, 2012 at 12:58 PM, Prasad, Ramit wrote: > On *nix you should just set the appropriate nice-ness and then > let the OS handle CPU scheduling. Not sure what you would do > for Windows--I assume OS X is the same as *nix for this context. On windows, you can also set the priority of a process, though it's a little different from the *nix niceness level. See http://code.activestate.com/recipes/496767/ for a recipe using pywin32. I believe the psutil module handles this too, but I don't think it manages to abstract away the platform differences. -- Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Mark Lawrence wrote: On 27/09/2012 17:16, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano wrote: On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: Summary of that article: "Sure, you have all these legitimate concerns, but look, cake!" Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, "Well, maybe, your concerns *might* be legitimate, but I don't think so because..." and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. [snipped] The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? The second article didn't reference the first directly, but was aimed at that general type of article. At any rate, Steven wrote as if it were a direct response. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
RE: Redirecting STDOUT to a Python Variable
Hans Mulder wrote: > On 22/09/12 23:57:52, ross.mars...@gmail.com wrote: > > To capture the traceback, so to put it in a log, I use this > > > > import traceback > > > > def get_traceback(): # obtain and return the traceback > > exc_type, exc_value, exc_traceback = sys.exc_info() > > return ''.join(traceback.format_exception(exc_type, exc_value, > exc_traceback)) > > This could be coded more succinctly as > > import sys, traceback > > def get_traceback(): # obtain and return the traceback > return ''.join(traceback.format_exception(*sys.exc_info())) Why not just use? return traceback.format_exc() > > > Suppose I have a script run by the scheduler, this captures the traceback > form any problems and emails them. > > > > if __name__ == '__main__': > > try: > > Runs_unattended() > > except: > > send_mail(send_from = yourEmailAddress, > > send_to = [ yourEmailAddress ], subject = 'Runs_unattended', > > text = '%s' % get_traceback(), > > files = [], server=yourLocalSMTP) > > Errhm, '%s' % get_traceback() is equiavalent to get_traceback() > How about: > > if __name__ == '__main__': > try: > Runs_unattended() > except: > send_mail(send_from = yourEmailAddress, > send_to = [ yourEmailAddress ], > subject = 'Runs_unattended', > text = get_traceback(), > files = [], > server=yourLocalSMTP) > 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: One of my joomla webpages has been hacked. Please help.
? G??ee? wrote: > I shouldn't have asked about Joomla here, or even about Python embedding > within Joomla cms. I was under the impression that the latter was relevant to > ask here but it seems it isnt. > > My bad, let's just close this thread so i don't waste anyone's time. Now when/if you get Joomla to run Python code and have a problem with *Python* code/coding, feel free to come back and ask questions on that. 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: Article on the future of Python
On 27.09.12 18:06, Ian Kelly wrote:
I understand ISO 8859-15 (Latin-9) to be the preferred Latin character
set for French, as it includes the Euro sign as well as a few
characters that are not in Latin-1 but are nonetheless infrequently
found in French.
Even for Latin-9 Python 3.3 can be a little faster 3.2.
$ ./python -m timeit -s "s=bytes(range(256))*100" "s.decode('latin1')"
Python 2.7: 105 usec
Python 3.2: 20.4 usec
Python 3.3: 4.98 usec
$ ./python -m timeit -s "s=bytes(range(256))*100" "s.decode('latin9')"
Python 2.7: 700 usec
Python 3.2: 94.6 usec
Python 3.3: 93.2 usec
--
http://mail.python.org/mailman/listinfo/python-list
RE: For Counter Variable
Tim Chase wrote: > [snip] though I'm minorly miffed that > enumerate()'s starting-offset wasn't back-ported into earlier 2.x > versions and have had to code around it for 1-based indexing; either > extra "+1"s or whip up my own simple enumerate() generator). Starting offset is in Python 2.6, unless you meant earlier than 2.6. >>> for idx, x in enumerate( xrange(5), 10 ): ... print idx, x ... 10 0 11 1 12 2 13 3 14 4 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
web access to configuration database
I want to make some configuration data available via a web service (bottle) that returns JSON data to a client which may be a python app or a jqgrid-based web page ui. The data structure is a list of dicts with strings, other dicts, and lists. It doesn't fit the relational database scheme; it looks like a nested key-value store. I want to handle get/post for crud operations. Any thoughts as to the best way to store the data? The magic solution would be a json-based database supporting get/post I guess. I've been looking at MongoDB, Redis, CouchDB, and ZODB. (apache thrift?) Currently learning Redis. thanks, --Tim -- http://mail.python.org/mailman/listinfo/python-list
RE: Capitalization for variable that holds a class
Dennis Lee Bieber wrote: > Sent: Sunday, September 23, 2012 11:53 AM > To: python-list@python.org > Subject: Re: Capitalization for variable that holds a class > > On Sun, 23 Sep 2012 16:48:38 +0100, Joshua Landau > declaimed the following in > gmane.comp.python.general: > > > Simple question: > > > > [myClass() for myClass in myClasses] > > vs > > [MyClass() for MyClass in myClasses] > > > > The recommended naming scheme for Python is that class DEFINITIONS > begin capitalized. Instances, methods/attributes, functions begin > lowercase. > > I abstain from the argument about camel-case vs _ (Ada "pretty > printers" automatically capitalize at _, so _ is common in Ada) > > class MyClass(object): > def myMethod(self): Are you (the OP) using Python 2 or 3? In python 2 list comprehensions leak; if you use MyClass as the list comprehension variable name it will overwrite the MyClass class definition (if it exists). >>> class MyClass(object): ... pass ... >>> print MyClass >>> _ = [ MyClass for MyClass in xrange( 5 ) ] >>> print MyClass 4 Ramit 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 little morning puzzle
Dwight Hutto wrote: > > Ergo: 'enumerate()' is the correct suggestion over manually > > maintaining your own index, despite it ostensibly being "more" code > > due to its implementation. > > But, therefore, that doesn't mean that the coder can just USE a > function, and not be able to design it themselves. So 'correct > suggestion' is a moot point. > Can you rephrase your first sentence? I am not sure what you mean. 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: Fastest web framework
Andriy Kornatskyy wrote: > Try to see 'Hello World' benchmark as an answer to the question how effective > is the framework inside... > > If computer X boots faster than Y, it means it is more effective in this > particular area. > > If a sportsman runs a distance 1 second faster than other, he got a medal (it > is not quite adequate to say if I load sportsman with 50 kilo bag he will not > run that fast... just try split the concerns). > > Thanks. > > Andriy > Not really, it depends on what each computer is doing during boot. To switch to the sportsman analogy, if sportsman A has to run 1 mile and along the way pick up 1 lb/kg every .1 mile while sportsman B has to pick up all the weight at the start. It is conceivable that sportsman A runs completes the run in 10 minutes while sportsman B runs the time in 9 minutes. Sportsman A might run the first .1 miles faster (sportsman A "boots" faster, but that is most likely less important than the overall long-term/real-world time to complete the task. 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
Did you know that about Islam?
Did you know that about Islam? http://www.youtube.com/v/e5-gmD-jUsc?rel=0 thank you -- http://mail.python.org/mailman/listinfo/python-list
teventlet: a light-weight method for handling events
Hello all: This was my first PyPi project to create. I'd like some feedback as to whether or not something like this is even moderately useful, and what I could do better with it. The blog article that details some of this is: http://tds-solutions.net/blog/?p=137 And the PyPi page: http://pypi.python.org/pypi/teventlet Essentially, Teventlet is just a handler that allows the registration of multiple callbacks; when something calls invoke, it dispatches all arguments to each individual callback. It's pretty small, and probably something anyone who is reasonably skilled could have written in a few minutes, but I wanted to put it out there anyway. Any ideas, suggestions/etc would be welcome. -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 5:33 AM, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I already did, about a month ago, for windows. I think the actual problem is with find, not replace (which does a find before the replace). When I asked on pydev, Victor Stinner had no explanation, but said he might look into it eventually. Others thought it not terribly important since 7 times blazingly fast is still fast (in your example, 29 versus 3 microseconds per operation. jmf wrapping a possible real issue with anti-3.3 crud did not help in getting attention to the regression. I also reported results of running stringbench.py on both 3.2 and 3.3 on windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as 3.2. Find/replace is the notable exception in stringbench, so it is an anomaly. Other things are faster in 3.3. I think this should be raised as a performance regression. I agree, and Mark did it. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
This flexible string representation is wrong by design. Expecting to divide "Unicode" in chunks and to gain something is an illusion. It has been created by a computer scientist who thinks "bytes" when on that field one has to think "bytes" and usage of the characters at the same time. The latin-1 chunk illustrates this wonderfully. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 12:16 PM, Devin Jeanpierre wrote: Charitably, maybe we'd call this a way of encouraging people who are discouraged by the bleaker tone of Calvin's post. And that's valid, if we're worried about morale. Definitely Calvin's post could be -- and has been -- taken the wrong way. It could be taken as a way of saying, "Python is doomed!", even though that isn't something Calvin ever wrote (he appears, from my reading, to be more worried about a stagnating community than a failed language). The title was "i-am-worried-about-the-future-of-python" (as in 'I am afraid Python will not have one'), not 'python has problems in some application areas'. Given the doom-y title and the tone of the article, excuse me for thinking doom was the topic. As for community: Calvin is worried that all the hot new people in these particular areas will not use and contribute to Python and the community. Under that interpretation, we would want other, more encouraging voices around, talking about ways in which Python is good and will survive. And that is what the second article was about. It turns out that there are hot new people in other growing areas where Python is growing. Computing for science, megadata, and education are not going away. Being a glue language for numerical computing was Python's first killer application nearly two decades ago, and it still is an important one. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 20:09, wxjmfa...@gmail.com wrote: This flexible string representation is wrong by design. Please state who agrees with this and why. Expecting to divide "Unicode" in chunks and to gain something is an illusion. Please provide the benchmarks to support your claim. It has been created by a computer scientist who thinks "bytes" when on that field one has to think "bytes" and usage of the characters at the same time. Please name this computer scientist so everybody knows to whom you are referring. The latin-1 chunk illustrates this wonderfully. I understand from an earlier post that latin-9 meets your needs completely for all French language characters plus the Euro sign, why don't you simply use that and stop rabitting on about latin-1. jmf Would you please be so kind as to stand up as your voice is rather muffled. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: using "*" to make a list of lists with repeated (and independent) elements
Tim Chase於 2012年9月27日星期四UTC+8上午6時44分42秒寫道： > On 09/26/12 17:28, 8 Dihedral wrote: > > > 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道： > > In these conditions, how to make this list [[0,0,0],[0,0,0]] with "*" > > without this behavior? > > >>> >>> a = [[0]*3 for i in xrange(2)] > > >>> >>> a[0][0]=2 > > >>> >>> a > > >>> [[2, 0, 0], [0, 0, 0]] > > > > > > def zeros(m,n): > > > a=[] > > > for i in xrange(m): > > > a.append([0]*n) > > > return a > > > > > > If one wants to tranlate to C, this is the style. > > > > But this is Python, so why the heck would anybody want to emulate > > *C* style? It could also be written in an assembly-language style, > > COBOL style, or a Fortran style...none of which are particularly > > valuable. > > > > Besides, a C-style would allocate a single array of M*N slots and > > then calculate 2d offsets into that single array. :-P > > > > -tkc a=[1, 2,3] b=[a]*4 print b a[1]=4 print b I thnik this is very clear about the situation in entangled references. -- http://mail.python.org/mailman/listinfo/python-list
test
Please ignore this post. I am testing to see if I can post successfully. -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On Thu, Sep 27, 2012 at 5:28 PM, ForeverYoung wrote: > Please ignore this post. > I am testing to see if I can post successfully. Is there a reason you can't wait until you have something to say / ask to see if it works? You're spamming a large number of inboxes with nothing. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: templating performance
On 09/27/2012 02:17 AM, alex23 wrote: On Sep 27, 7:50 am, Gelonida N wrote: http://mindref.blogspot.fr/2012/07/python-fastest-template.html This is already being discussed on the list. See the thread "Fastest template engine". Apologies everybody, I wanted to 'bookkmark' (forward this article to myself) and posted it accidentally once more to this group. (Can happen if not paying attention with Thunderbird :-( ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Capitalization for variable that holds a class
On 27 September 2012 18:20, Prasad, Ramit wrote: > Dennis Lee Bieber wrote: > > Sent: Sunday, September 23, 2012 11:53 AM > > To: python-list@python.org > > Subject: Re: Capitalization for variable that holds a class > > > > On Sun, 23 Sep 2012 16:48:38 +0100, Joshua Landau > > declaimed the following in > > gmane.comp.python.general: > > > > > Simple question: > > > > > > [myClass() for myClass in myClasses] > > > vs > > > [MyClass() for MyClass in myClasses] > > > > > > > The recommended naming scheme for Python is that class DEFINITIONS > > begin capitalized. Instances, methods/attributes, functions begin > > lowercase. > > > > I abstain from the argument about camel-case vs _ (Ada "pretty > > printers" automatically capitalize at _, so _ is common in Ada) > > > > class MyClass(object): > > def myMethod(self): > > Are you (the OP) using Python 2 or 3? In python 2 list > comprehensions leak; if you use MyClass as the list > comprehension variable name it will overwrite the > MyClass class definition (if it exists). > > >>> class MyClass(object): > ... pass > ... > >>> print MyClass > > >>> _ = [ MyClass for MyClass in xrange( 5 ) ] > >>> print MyClass > 4 > Don't worry, not only am I using Python 3 but I would be certain to use GenericUnusedClassName anyway ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
You're posting to both comp.lang.python and python-list, are you aware that that's redundant? On Fri, Sep 28, 2012 at 5:09 AM, wrote: > This flexible string representation is wrong by design. > Expecting to divide "Unicode" in chunks and to gain something > is an illusion. > It has been created by a computer scientist who thinks "bytes" > when on that field one has to think "bytes" and usage of the > characters at the same time. There's another range of numbers that, in some languages, is divided for efficiency's sake: Integers below 1<<[bit size]. In Python 2, such numbers were an entirely different data type (int vs long); other languages let you use the same data type for both, but "(1<<5)+1" will be executed much faster than "(1<<500)+1". (And far as I know, a conforming Python 3 implementation should be allowed to do that; 3.2 on Windows doesn't seem to, though.) That's all PEP 393 is; it's a performance improvement for a particular subset of values that happens to fit conveniently into the underlying machine's data storage. If Python were implemented on a 9-bit computer, I wouldn't be surprised if the PEP 393 optimizations were applied differently. It's nothing to do with Latin-1, except insofar as the narrowest form of string _happens_ to contain everything that's in Latin-1. Go blame the Unicode consortium for picking that. > The latin-1 chunk illustrates this wonderfully. Aside from replace(), as mentioned in this thread, are there any other ways that this is so wonderfully illustrated? Or is it "wonderfully" as in "I wonder if people will believe me if I keep spouting unsubstantiated claims"? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Reducing cache/buffer for faster display
I have these 2 scripts that are very heavy on the file i/o, consume a very reasonable amount of cpu and output their counters at a - very - relaxed pace to the console. The output is very simply done using something like: print "files:", nFiles, "\r", Yet alltough there is no real reason for it, even a pace of a print every 10-30 secs will be cached, only to actually show an output update every 1-2 min or so. When I run the scripts with "python -u myscript.py", the output is complete, very speedy and without any kind of impact on the actual work being one. Can this option be called from within the script? Or is there another option to make the display "a bit" speedier ? Runnning Python 2.7.3, but it seems to me I've allready had this problem a long, long time ago with other releases. -- When in doubt, use brute force. -- Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On 2012-09-27, Devin Jeanpierre wrote: > On Thu, Sep 27, 2012 at 5:28 PM, ForeverYoung wrote: >> Please ignore this post. >> I am testing to see if I can post successfully. > > Is there a reason you can't wait until you have something to say / ask > to see if it works? You're spamming a large number of inboxes with > nothing. Inboxes? What is this, usenet or email ? -- When in doubt, use brute force. -- Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On 9/27/2012 3:36 PM, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 5:28 PM, ForeverYoung wrote: Please ignore this post. I am testing to see if I can post successfully. Is there a reason you can't wait until you have something to say / ask to see if it works? You're spamming a large number of inboxes with nothing. I'm kind of thinking complaints about it are just doubling the spam to a large number of inboxes. You could've just doubled the spam in the OP's inbox and that would've been that. -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reducing cache/buffer for faster display
On Fri, Sep 28, 2012 at 7:57 AM, Rikishi42 wrote: > I have these 2 scripts that are very heavy on the file i/o, consume a very > reasonable amount of cpu and output their counters at a - very - relaxed > pace to the console. The output is very simply done using something like: > >print "files:", nFiles, "\r", > > > Yet alltough there is no real reason for it, even a pace of a print every > 10-30 secs will be cached, only to actually show an output update every 1-2 > min or so. Yup! Just add a call to sys.stdout.flush() after each print. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Reducing cache/buffer for faster display
In Chris Angelico writes: > On Fri, Sep 28, 2012 at 7:57 AM, Rikishi42 wrote: > > I have these 2 scripts that are very heavy on the file i/o, consume a very > > reasonable amount of cpu and output their counters at a - very - relaxed > > pace to the console. The output is very simply done using something like: > > > >print "files:", nFiles, "\r", > > > > > > Yet alltough there is no real reason for it, even a pace of a print every > > 10-30 secs will be cached, only to actually show an output update every 1-2 > > min or so. > Yup! Just add a call to sys.stdout.flush() after each print. Isn't terminal output line-buffered? I don't understand why there would be an output delay. (Unless the "\r" is messing things up...) -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, "The Gashlycrumb Tinies" -- http://mail.python.org/mailman/listinfo/python-list
Re: Reducing cache/buffer for faster display
On Fri, Sep 28, 2012 at 8:25 AM, John Gordon wrote: > Isn't terminal output line-buffered? I don't understand why there would > be an output delay. (Unless the "\r" is messing things up...) This is a classic progress-indication case, which does indeed mess up line-buffering. The carriage return (and no line feed, done in the Python 2 style of a trailing comma) puts the cursor back to the beginning of the line, ready to overwrite, and ripe for one of those old favorite incomplete overwrite errors - if nFiles monotonically increases, it's fine, but if it decreases, the display can get ugly. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On 9/27/2012 2:58 PM Rikishi42 said... Inboxes? What is this, usenet or email ? Yes. Both. Emile -- http://mail.python.org/mailman/listinfo/python-list
Using PipeController (v0.2) to run a pipe incrementally
I've released v0.2 of PipeController, my experimental tool to simulate pipes in Python. It can be downloaded here: http://dancingbison.com/pipe_controller-v0.2.zip Changes in v0.2: - module name changed to avoid clashes with pipes module in the standard Python library; the module is now called pipe_controller.py instead of pipes.py; - you can now pass input and output filename arguments on the command in your program that calls PipeController, instead of having to use I/O redirection; - you can now import class PipeController from the module, with: from pipe_controller import PipeController - you can now run a PipeController pipe incrementally, i.e., run the pipe in a loop, adding a pipe component (a Python function) in each iteration, and it can save the intermediate outputs resulting from each iteration, to separate output files; the program test_pipe_controller_03.py in the download package shows how to do this. This feature can be useful to debug your pipe's logic, and also to save the intermediate computation results in case they are of use in their own right. Blog post about using PipeController v0.2 to run a pipe incrementally: http://jugad2.blogspot.in/2012/09/using-pipecontroller-to-run-pipe.html - Vasudev Ram www.dancingbison.com jugad2.blogspot.com twitter.com/vasudevram -- http://mail.python.org/mailman/listinfo/python-list
Re: test
On Thu, 27 Sep 2012 17:36:57 -0400, Devin Jeanpierre wrote: > On Thu, Sep 27, 2012 at 5:28 PM, ForeverYoung wrote: >> Please ignore this post. >> I am testing to see if I can post successfully. > > Is there a reason you can't wait until you have something to say / ask > to see if it works? You're spamming a large number of inboxes with > nothing. It is perfectly legitimate to send a test message to Usenet to check that you can post. But it's not really appropriate to send it *here* unless you think that you have a specific problem with this newsgroup, comp.lang.python. Otherwise you should send test posts to dedicated testing newsgroups like alabama.test, alt.binaries.test or be.test. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 28, 2:47 am, Mark Lawrence wrote: > "... why does the runtime environment have to be so limiting? Operations > involving primitives could be easily compiled (on the fly - JIT) to > machine code and more advanced objects exist as plug-ins. Oh, and it > would be nice to be able to write such objects quickly and easily - not > the convoluted mess that it is currently." > > Simples :) You should see how awesome _my_ imaginary implementation is! -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 28, 2:17 am, Devin Jeanpierre wrote: > Uncharitably, it's just a way of hiding one's head in the sand, > ignoring any problems Python has by focusing on what problems it > doesn't have. But isn't that what counterpoint is all about? Calvin's article highlighted what he felt were areas that Python isn't successful, while Tim McNamara's pointed out areas it was. Just because Python isn't used much in commercial video games doesn't undermine the point that it's heavily used in education and research. Does Python _have_ to be a go-to tool in gaming for it to not be on its death march? Or more to the point: rather than just complain about it... It's not like there aren't active communities that _are_ working in this area: PyGame, pyglet, Kivy are all projects that can be contributed to. I love using Python and will endeavour to do so wherever I can, but it's always going to be the case that a language has strengths & weaknesses that other languages lack. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reducing cache/buffer for faster display
On 2012-09-27, Chris Angelico wrote: > On Fri, Sep 28, 2012 at 7:57 AM, Rikishi42 wrote: >> I have these 2 scripts that are very heavy on the file i/o, consume a very >> reasonable amount of cpu and output their counters at a - very - relaxed >> pace to the console. The output is very simply done using something like: >> >>print "files:", nFiles, "\r", >> >> >> Yet alltough there is no real reason for it, even a pace of a print every >> 10-30 secs will be cached, only to actually show an output update every 1-2 >> min or so. > > Yup! Just add a call to sys.stdout.flush() after each print. Update: tried it, ran it, I love it. Thanks ! -- When in doubt, use brute force. -- Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: Reducing cache/buffer for faster display
On 2012-09-27, Chris Angelico wrote: > On Fri, Sep 28, 2012 at 8:25 AM, John Gordon wrote: >> Isn't terminal output line-buffered? I don't understand why there would >> be an output delay. (Unless the "\r" is messing things up...) > > This is a classic progress-indication case, which does indeed mess up > line-buffering. The carriage return (and no line feed, done in the > Python 2 style of a trailing comma) puts the cursor back to the > beginning of the line, ready to overwrite, and ripe for one of those > old favorite incomplete overwrite errors - if nFiles monotonically > increases, it's fine, but if it decreases, the display can get ugly. True, but that wasn't the problem here. The updates where. Thanks for the given answer, I'll try it. The scripts in question only increase numbers. But should that not be the case, solutions are simple enough. The numbers can be formatted to have a fixed size. In the case of random line contents (a list of filesnames, say) it's enough to create an output function that is aware of the length of the previously printed line, and add enough spaces to the current one to wipe exess content. Thanks again for the suggestion. -- When in doubt, use brute force. -- Ken Thompson -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, 28 Sep 2012 00:32:58 +1000, Chris Angelico wrote: > On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards > wrote: >> On 2012-09-27, Chris Angelico wrote: >>> On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano >>> wrote: >>> Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P >>> >>> LAMP usually means PHP these days. There's a lot of that around. >> >> Yea, unfortunately. What a mess of a language. I recently had to >> learn enough PHP to make some changes to a web site we had done by an >> outside contractor. PHP feels like it was designed by taking a >> half-dozen other languages, chopping them into bits and then pulling >> random features/syntax/semantics at random from the various different >> piles. Those bits where then stuck together with duct tape and bubble >> gum and called PHP... >> >> As one of the contractors who wrote some of the PHP said: "PHP is like >> the worst parts of shell, Perl, and Java all combined into one >> language!" > > I can't remember where I read it, and I definitely don't know if it's > accurate to current thinking, but the other day I found a quote > purporting to be from the creator of PHP saying that he didn't care > about memory leaks, just restart Apache periodically. It's definitely > true of most PHP scripts that they're unconcerned about resource > leakage, on the assumption that everything'll get cleared out at the end > of a page render. PHP seems to encourage sloppiness. Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
> Fair enough, but it's the M in the LAMP stack I object to. I'd much > rather have P. +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 9:05 PM, Jason Friedman wrote: Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. +1 I know this isn't the list for database discussions, but I've never gotten a decent answer. I don't know much about either, so I'm kind of curious why postgresql over mysql? -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 9:05 PM, Jason Friedman wrote: Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. +1 I know this isn't the list for database discussions, but I've never gotten a decent answer. I don't know much about either, so I'm kind of curious why postgresql over mysql? I'll try not to get too OT... I had previously just used MySQL (and SQLite), but have been reaading some PostGres stuff lately. I took a look around and basically... you and I won't know or notice a difference probably ever. There's all sorts of crazy tweaks you can get for reliability, speed, and backups depending on what you use. So the only advice I can give on that is just learn to use both. And even better yet, just use SQLAlchemy if you're ever touching a database from Python because it handles all the mucky SQL for you - you just define the ORM. (Hey look! A Python module!) My $0.02 -Wayne -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls
It's past > time to stop feeding this troll, please. You mean like the post above you sentbitch please, I'm eatin good right now. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Wed, Sep 26, 2012 at 8:40 PM, alex23 wrote: > On Sep 26, 5:06 pm, Dwight Hutto wrote: >> You can "Plonk" my dick bitches. > > You do understand that when you have so many people react badly to how > you phrase things, that the problem most likely lies with you and not > them? Depends on the demographic. That the only person who actually reacts favourably to this > garbage coming from you is *you*? Yeah...I'm egotistical. > > There is no place for racist or sexist speech here. \ There never was any from me Reply personally > to whomever you want with whatever invective you choose, that's your > right (just as it is their right to flag your emails as spam, as I > have). Yeah, hit the mute button if you don't like me. That's a brilliant fucking idea...buddy. But this is a place for public discussion and, again, we do not > need you driving away people who might actually contribute positively > simply because you're unable or unwilling to always do so. Uhm, I do post appropriately, unless you're trolling the board, with a few other avatars, and buddies in order to stomp a flame war someone else started...IMHO. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:14 PM, Littlefield, Tyler wrote: > I know this isn't the list for database discussions, but I've never gotten a > decent answer. I don't know much about either, so I'm kind of curious why > postgresql over mysql? MySQL is an open-source PRODUCT owned by a for-profit company. PostgreSQL is an open-source PROJECT and is unowned. A lot of the major technical differences are outlined here: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL -- Greg Donald -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wrote: > the only advice I can give on that is > just learn to use both. I find there's little to lose in having experience with both. Most every good web framework out there supports lots of different databases through generic ORM layers.. so flipping back and forth to see which database is better for your particular app and workload is trivial. -- Greg Donald -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, Sep 28, 2012 at 2:12 PM, Greg Donald wrote: > On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wrote: >> the only advice I can give on that is >> just learn to use both. > > I find there's little to lose in having experience with both. > > Most every good web framework out there supports lots of different > databases through generic ORM layers.. so flipping back and forth to > see which database is better for your particular app and workload is > trivial. Learning both is good, if for no reason than that learning more tends to be advantageous. As Greg said in his other post, PGSQL is a completely open source project. That's a significant point imho. Other points to consider: * MySQL is designed for dynamic web sites, with lots of reading and not too much writing. Its row and table locking system is pretty rudimentary, and it's quite easy for performance to suffer really badly if you don't think about it. But if your needs are simple, MySQL is probably enough. PostgreSQL uses MVCC to avoid locks in many cases. You can happily read from a row while it's being updated; you'll be unaware of the update until it's committed. * Postgres has solid support for advanced features like replication. I don't know how good MySQL's replication is, never tried it. Can't say. This might be completely insignificant. * The default MySQL engine, MyISAM, doesn't do proper transaction logging etc. InnoDB is better for this, but the internal tables (where your database *structure* is maintained) are MyISAM. This imposes a definite risk. * Both engines have good support in popular languages, including (dragging this back on topic, kicking and screaming) Python. For further details, poke around on the web; I'm sure you'll find plenty of good blog posts etc. But as for me and my house, we will have Postgres serve us. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto wrote: > [ lots of screed that demonstrates that Dwight hasn't grokked the hacker > culture ] Dwight, have a read of these documents. They may help you to understand how the python-list community operates, and perhaps more so, why most of the regulars here think the way they do. Actually, this may be of interest to quite a few people, so I'll post it on-list. http://catb.org/~esr/faqs/ ChrisA -- http://mail.python.org/mailman/listinfo/python-list
iPhone App To Help You Learn Spanish Faster By Using Flashcards With Pictures
http://goo.gl/CRhLz - "Spanish Flashcards with Pictures" is an iPhone app that will help you learn Spanish faster by using flashcards with pictures (learn over 300 most commonly used words in the English / Spanish language from A to Z), thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Fri, Sep 28, 2012 at 12:40 AM, Chris Angelico wrote: > On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto wrote: >> [ lots of screed that demonstrates that Dwight hasn't grokked the hacker >> culture ] Don't hack, but could very well if necessary. > > Dwight, have a read of these documents. They may help you to > understand how the python-list community operates, and perhaps more > so, why most of the regulars here think the way they do. They have double digit I.Q.'s ? Actually, > this may be of interest to quite a few people, so I'll post it > on-list. Go right aheadbuddy. > > http://catb.org/~esr/faqs/ > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On 9/27/2012 10:50 PM, Dwight Hutto wrote: On Fri, Sep 28, 2012 at 12:40 AM, Chris Angelico wrote: On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto wrote: [ lots of screed that demonstrates that Dwight hasn't grokked the hacker culture ] Don't hack, but could very well if necessary. You couldn't hack your self out of a wet paper bag, and you're fooling noone. Sorry... buddy. You should go away now; You asked who is laughing at you the other day, and at that point you had the ability to salvage (or at least attempt to salvage) your reputation with a few people. You've pretty much blown that away at this point, so a belated answer to your question is everyone. Dwight, have a read of these documents. They may help you to understand how the python-list community operates, and perhaps more so, why most of the regulars here think the way they do. They have double digit I.Q.'s ? Actually, this may be of interest to quite a few people, so I'll post it on-list. Go right aheadbuddy. http://catb.org/~esr/faqs/ ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 10:37 PM, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:12 PM, Greg Donald wrote: On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wrote: the only advice I can give on that is just learn to use both. I find there's little to lose in having experience with both. Most every good web framework out there supports lots of different databases through generic ORM layers.. so flipping back and forth to see which database is better for your particular app and workload is trivial. I plan to do that, just so I have both. I've had the experience of mysql, so I guess postgresql is up next. I was just really curious why so many people prefered it. Perhaps off topic (actually really off topic), but if I were to dump my tables from mysql out into flat-files, does postgresql use the same basic structure? IIRC there's a sql98 standard or something like that. Learning both is good, if for no reason than that learning more tends to be advantageous. As Greg said in his other post, PGSQL is a completely open source project. That's a significant point imho. Other points to consider: * MySQL is designed for dynamic web sites, with lots of reading and not too much writing. Its row and table locking system is pretty rudimentary, and it's quite easy for performance to suffer really badly if you don't think about it. But if your needs are simple, MySQL is probably enough. PostgreSQL uses MVCC to avoid locks in many cases. You can happily read from a row while it's being updated; you'll be unaware of the update until it's committed. * Postgres has solid support for advanced features like replication. I don't know how good MySQL's replication is, never tried it. Can't say. This might be completely insignificant. * The default MySQL engine, MyISAM, doesn't do proper transaction logging etc. InnoDB is better for this, but the internal tables (where your database *structure* is maintained) are MyISAM. This imposes a definite risk. You've lost me here; there are two different engines. From what I got from your post, innoDB just essentially wraps MyIsam with some pretty (or apparently not so pretty) locking stuff to help with transactions? * Both engines have good support in popular languages, including (dragging this back on topic, kicking and screaming) Python. For further details, poke around on the web; I'm sure you'll find plenty of good blog posts etc. But as for me and my house, we will have Postgres serve us. Will do, thanks for all the feedback (both on and off list). I'm not a huge database person; I've never really played around with much of it since there's a lot more to understand and I can't just mess with it like any other language, so I was unaware of a lot, and still am in terms of performance. I've obviously seen a ton of blog posts talking about the differences, but they tend to dive into the inner mechanics, something which I don't understand all that well. PS: Someone mentioned my messages were not indented properly; is this still the case? Apparently thunderbird allows ctrl+right bracket to outdent, so I assume my messages should be the outer ones with others being indented farther. ChrisA -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Fri, Sep 28, 2012 at 1:12 AM, Littlefield, Tyler wrote: > On 9/27/2012 10:50 PM, Dwight Hutto wrote: >> >> On Fri, Sep 28, 2012 at 12:40 AM, Chris Angelico wrote: >>> >>> On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto >>> wrote: [ lots of screed that demonstrates that Dwight hasn't grokked the hacker culture ] >> >> Don't hack, but could very well if necessary. > > > You couldn't hack your self out of a wet paper bag, and you're fooling > noone. Yeah I could. Sorry... buddy. You should go away now; So you can dominate with a lame ass attempt to approach my responses with a manipulative tactic to discredit me, including such hits as racism, and sexism? You asked who is laughing at > you the other day, and at that point you had the ability to salvage (or at > least attempt to salvage) your reputation with a few people. Nobody, they're laughing at your failed attempt to discredit me in a on thread response in which I was a respondent. Please don't disguise your foolishnish with lies. You've pretty > much blown that away at this point, so a belated answer to your question is > everyone. You mean I went to sleep, woke up and responded? Nice attempt, but you can set a random seed of mine up your ass. > > >>> Dwight, have a read of these documents. They may help you to >>> understand how the python-list community operates, and perhaps more >>> so, why most of the regulars here think the way they do. >> >> They have double digit I.Q.'s ? >> >> Actually, >>> >>> this may be of interest to quite a few people, so I'll post it >>> on-list. >> >> Go right aheadbuddy. >> >>> http://catb.org/~esr/faqs/ >>> >>> ChrisA >>> -- >>> http://mail.python.org/mailman/listinfo/python-list >> >> >> > > > -- > Take care, > Ty > http://tds-solutions.net > The aspen project: a barebones light-weight mud engine: > http://code.google.com/p/aspenmud > He that will not reason is a bigot; he that cannot reason is a fool; he that > dares not reason is a slave. > -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
REST code-golf: How concisely can you expose and consume services?
web2py (7 lines): https://gist.github.com/3798093 Includes creation of models, validator, controllers and urls. Rules: - Must have [at least] the same functionality as my 7-line example - Imports are allowed and not taken into line count, on the condition that everything remains generic. I.e.: one can change model and controller names &etc without modifying imported libraries - Can't import/take the code from web2py (e.g.: https://github.com/web2py/web2py/blob/master/gluon/tools.py#L4098) (feel free to write them in reply to this email and/or as gist comments =]) Good luck! -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe deal with python command line inside a program
Hi, have you been able to solve this problem ?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Sep 28, 10:21 am, Dwight Hutto wrote: > On Fri, Sep 28, 2012 at 1:12 AM, Littlefield, Tyler > wrote: > > On 9/27/2012 10:50 PM, Dwight Hutto wrote: > > >> On Fri, Sep 28, 2012 at 12:40 AM, Chris Angelico wrote: > > >>> On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto > >>> wrote: > > [ lots of screed that demonstrates that Dwight hasn't grokked the hacker > culture ] > > >> Don't hack, but could very well if necessary. > > > You couldn't hack your self out of a wet paper bag, and you're fooling > > noone. > > Yeah I could. > > Sorry... buddy. You should go away now; > > So you can dominate with a lame ass attempt to approach my responses > with a manipulative tactic to discredit me, including such hits as > racism, and sexism? > > You asked who is laughing at > > > you the other day, and at that point you had the ability to salvage (or at > > least attempt to salvage) your reputation with a few people. > > Nobody, they're laughing at your failed attempt to discredit me in a > on thread response in which I was a respondent. > > Please don't disguise your foolishnish with lies. > > You've pretty > > > much blown that away at this point, so a belated answer to your question is > > everyone. > > You mean I went to sleep, woke up and responded? Nice attempt, but you > can set a random seed of mine up your ass. > > > > > > > > > > > > >>> Dwight, have a read of these documents. They may help you to > >>> understand how the python-list community operates, and perhaps more > >>> so, why most of the regulars here think the way they do. > > >> They have double digit I.Q.'s ? > > >> Actually, > > >>> this may be of interest to quite a few people, so I'll post it > >>> on-list. > > >> Go right aheadbuddy. > > >>>http://catb.org/~esr/faqs/ > > >>> ChrisA > >>> -- > >>>http://mail.python.org/mailman/listinfo/python-list > > > -- > > Take care, > > Ty > >http://tds-solutions.net > > The aspen project: a barebones light-weight mud engine: > >http://code.google.com/p/aspenmud > > He that will not reason is a bigot; he that cannot reason is a fool; he that > > dares not reason is a slave. Some facts that are well-known enough but somehow seem relevant to this discussion. Technology is called a great enabler -- A little less gushingly its a great multiplier. When we look a little impartially at it we see that as technology increases in scope/power the corresponding human involvement gets more and more passive. Coming to the specific technology-stack -- mailing-lists atop the internet -- we see the following: When I hit the send button Ive no idea who will read what I send. Likewise what I end up reading may not be something I specifically wish to read. Specifically, Ive no idea what is the size of the python-list readership -- surely in hundreds, more likely thousands. So when I feel like making a response to one or two people which has more heat than (python-related) light, it would help to consider the thousand(s) who will read it who are not involved/interested in the fracas. A more physical analogy: Lets say I am driving along happily on the freeway and someone does something to me that generates severe justifiable road-rage. So I stop the car, get down and do my schtick -- shout, shoot, mow-him-down, whatever -- and in the process create a jam of a hundred vehicles all around. However justifiable my rage, I would be lucky to get anyone's support! A more personal point. I find that anger is usually a thin cover for depression. And depression inversely correlates with amount of sunshine I see. So before hitting the send button, it may be a good idea to sleep over and see if the rising sun changes my mood. Coming to threads like this one: We've seen an old member of this list scolded for stretching the drinking jokes a bit too far. And another old member who posted a youtube link which had nothing to do with python even though the subject said 'OT' So… Staying withing python-related discussions and using courteous language is the general rule for all. If you follow that you should be ok -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Fri, Sep 28, 2012 at 1:51 AM, rusi wrote: > On Sep 28, 10:21 am, Dwight Hutto wrote: >> On Fri, Sep 28, 2012 at 1:12 AM, Littlefield, Tyler >> wrote: >> > On 9/27/2012 10:50 PM, Dwight Hutto wrote: >> >> >> On Fri, Sep 28, 2012 at 12:40 AM, Chris Angelico wrote: >> >> >>> On Fri, Sep 28, 2012 at 1:47 PM, Dwight Hutto >> >>> wrote: >> >> [ lots of screed that demonstrates that Dwight hasn't grokked the hacker >> culture ] >> >> >> Don't hack, but could very well if necessary. >> >> > You couldn't hack your self out of a wet paper bag, and you're fooling >> > noone. >> >> Yeah I could. >> >> Sorry... buddy. You should go away now; >> >> So you can dominate with a lame ass attempt to approach my responses >> with a manipulative tactic to discredit me, including such hits as >> racism, and sexism? >> >> You asked who is laughing at >> >> > you the other day, and at that point you had the ability to salvage (or at >> > least attempt to salvage) your reputation with a few people. >> >> Nobody, they're laughing at your failed attempt to discredit me in a >> on thread response in which I was a respondent. >> >> Please don't disguise your foolishnish with lies. >> >> You've pretty >> >> > much blown that away at this point, so a belated answer to your question is >> > everyone. >> >> You mean I went to sleep, woke up and responded? Nice attempt, but you >> can set a random seed of mine up your ass. >> >> >> >> >> >> >> >> >> >> >> >> >>> Dwight, have a read of these documents. They may help you to >> >>> understand how the python-list community operates, and perhaps more >> >>> so, why most of the regulars here think the way they do. >> >> >> They have double digit I.Q.'s ? >> >> >> Actually, >> >> >>> this may be of interest to quite a few people, so I'll post it >> >>> on-list. >> >> >> Go right aheadbuddy. >> >> >>>http://catb.org/~esr/faqs/ >> >> >>> ChrisA >> >>> -- >> >>>http://mail.python.org/mailman/listinfo/python-list >> >> > -- >> > Take care, >> > Ty >> >http://tds-solutions.net >> > The aspen project: a barebones light-weight mud engine: >> >http://code.google.com/p/aspenmud >> > He that will not reason is a bigot; he that cannot reason is a fool; he >> > that >> > dares not reason is a slave. > > Some facts that are well-known enough but somehow seem relevant to > this discussion. > Technology is called a great enabler -- A little less gushingly its a > great multiplier. > When we look a little impartially at it we see that as technology > increases in scope/power the corresponding human involvement gets more > and more passive. > But technology should be engaged by many different view points, in order to insure that the output of technology is within the, not only the grasp of outsiders, but the scope of those who wish to debate it's usage in many different areas in order to have stability of the society(societies) that produce the output. > Coming to the specific technology-stack -- mailing-lists atop the > internet -- we see the following: > When I hit the send button Ive no idea who will read what I send. > Likewise what I end up reading may not be something I specifically > wish to read. That's common on mailing lists, and the discussions they maintain, as well as the usage membership. > > Specifically, Ive no idea what is the size of the python-list > readership -- surely in hundreds, more likely thousands. > Then it's part of, but the only side of, your public persona. > So when I feel like making a response to one or two people which has > more heat than (python-related) light, it would help to consider the > thousand(s) who will read it who are not involved/interested in the > fracas. Don't be a little bitch, and respond. Instead you're whining about it. > > A more physical analogy: Lets say I am driving along happily on the > freeway and someone does something to me that generates severe > justifiable road-rage. So I stop the car, get down and do my schtick > -- shout, shoot, mow-him-down, whatever -- and in the process create a > jam of a hundred vehicles all around. However justifiable my rage, I > would be lucky to get anyone's support! It's called information overload, and temporary insanity...go ask a lawyer list. > > A more personal point. I find that anger is usually a thin cover for > depression. A medical condition which can be cause by many different factors, and all legal. And depression inversely correlates with amount of > sunshine I see. This is more seasonal depression, and human biological adjustment to circadian rhythm in nature that appears in several areas. So before hitting the send button, it may be a good > idea to sleep over and see if the rising sun changes my mood. It always does, it's biological in nature for this to happen. > > Coming to threads like this one: > We've seen an old member of this list scolded for stretching the > drinking jokes a bit too far. Probably me, and you have no idea what I'm not saying when i
