Re: Python and Ruby
Nobody writes: > A better metric is whether using N features has O(N) complexity, or O(N^2) > (where you have to understand how each feature relates to each other > feature) or even O(2^N) (where you have to understand every possible > combination of interactions). M. Felleisen wrote a paper trying to formalize some metric on the expressive power of programming languages. I skimmed through it for about a minute and wasn't convinced, but it apparently has gathered some respect. I want to read it more carefully sometime: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3147 - new .pyc format
>>> Personally, I think it is a terribly idea to keep the source file and >>> byte code file in such radically different places. They should be kept >>> together. What you call "clutter" I call having the files that belong >>> together kept together. >> >> I see why you think so, it's reasonable, however there is compelling >> argument, I think, for the opposite view: namely to keep things >> separate. An average developer definitely wants easy access to .py >> files. However I see no good reason for having access to .pyc files. I >> for one have never inspected a .pyc file. Why would you want to have a >> .pyc file at hand? > > If you don't care about access to .pyc files, why do you care where they > are? If they are in a subdirectory module.pyr, then shrug and ignore the > subdirectory. > > If you (generic you) are one of those developers who don't care > about .pyc files, then when you are browsing your source directory and > see this: > > > module.py > module.pyc > > you just ignore the .pyc file. Or delete it, and Python will re-create it > as needed. So if you see > > module.pyr/ > > just ignore that as well. > > > >> If we don't really want to have .pyc files in convenient locations >> because we (almost) never want to access them really, then I'd say it's >> a good idea to keep them totally separate and so make don't get in the >> way. > > I like seeing them in the same place as the source file, because when I > start developing a module, I often end up renaming it multiple times > before it settles on a final name. When I rename or move it, I delete > the .pyc file, and that ensures that if I miss changing an import, and > try to import the old name, it will fail. > > By hiding the .pyc file elsewhere, it is easy to miss deleting one, and > then the import won't fail, it will succeed, but use the old, obsolete > byte code. Okay, I see your point but I think your argument about importing shows that python is doing something suboptimal because I have to worry about .pyc files. Ideally, I only would need to worry about python source files. There is now a chance to 'fix' (quotation marks because maybe there is nothing to fix, according to some) this issue and make all pyc files go away and having python magically doing the right thing. A central pyc repository would be something I was thinking about, but I admit it's a half baked or not even that, probably quarter baked idea. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 2, 3:28 am, Steven D'Aprano wrote: > > There is no module numbers in the standard library, at least not in 2.5. It's new in 2.6 (and 3.0, I think; it's there in 3.1, anyway). It provides abstract base classes for numeric types; see the fractions module source for some of the ways it can be used. Here are the docs: http://docs.python.org/library/numbers.html and also PEP 3141, on which it's based: http://www.python.org/dev/peps/pep-3141/ -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano wrote: > On Sat, 30 Jan 2010 16:58:34 +, tanix wrote: [...] > > The very idea of using a number of blanks to identify your block level > > is as insane as it gets. > > Not at all. People do it all the time. The very idea of expecting people > to count nested braces to identify block level is what is crazy, which is > why in languages with braces people still indent the blocks. for reading written code, it's surely helpful to have the code indented, though for *human* reading, the count of blanks seems rather inessential, as long as intended difference in indents is more pronounced than incidental difference between same-level lines. for writing new code, it's not necessarily that helpful to be *forced* to keep with strict indenting rules. in early development phases, code is often experimental, and parts of it may need to be blocked or unblocked as the codebase grows, and for experimentation, the need to carefully and consistently indent and de-indent large chunks of code can easily lead to a mess (blame it on the programmer, not the language, but still). yes, there are editors that help you indent chunks of code, but see below. there are languages where indentation can be either enforced and allow one to omit some syntactic nuissance like braces or begin-end clauses, or made optional, requiring other syntactic means for delimiting blocks etc. (consider f# with its #light declaration, for example.) [...] > In any case, if your IDE mixes tabs and spaces, your IDE is broken and > you should fix your tools rather than blame the language. as long as you are limited to your own code, sure. but if many work on the same bit, and use different editors and indentation policies, blanks-tabs indentation issues are not unlikely. you can have blanks converted to tabs and vice versa automatically, but that's clearly a nuisance. > > > > Braces is the most reliable way to identify blocks. > > Nonsense. For the compiler, both are equally reliable, and for the human > reader, indents beat braces easily. if blanks and tabs are mixed together as indentation, the setting of your ide can easily mess up the indentation, making the structure unclear. in some editors, you can have braces highlighted, so that it's even easier to see where a block ends or starts. and more advanced editors help one see the structure of the code, whereby both indentation and braces are made less important for the reader. but yes, indentation surely helps in reading the code. > > > > Sane compilers ignore blanks altogether. > > Really? So a "sane compiler" sees no difference between: > > for x in mylist: > > and > > forxinmylist: > > > I'm glad I don't have to program using a compiler you consider "sane". the point here was, i think, that blanks may have no syntactic meaning, though they can still be essential at the lexical level. your example targeted the lexical level, and that's rather irrelevant to the problem of syntactically meaningful indentation discussed here. vQ -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Carl Banks wrote: On Feb 1, 7:33 pm, Tim Chase wrote: Stephen Hansen wrote: First, I don't shadow built in modules. Its really not very hard to avoid. Given the comprehensive nature of the batteries-included in Python, it's not as hard to accidentally shadow a built-in, unknown to you, but yet that is imported by a module you are using. The classic that's stung me enough times (and many others on c.l.p and other forums, as a quick google evidences) such that I *finally* remember: bash$ touch email.py bash$ python ... >>> import smtplib Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/smtplib.py", line 46, in import email.Utils ImportError: No module named Utils Using "email.py" is an innocuous name for a script/module you might want to do emailish things, and it's likely you'll use smtplib in the same code...and kablooie, things blow up even if your code doesn't reference or directly use the built-in email.py. email.py is not an innocuous name, it's a generic name in a global namespace, which is a Bad Thing. Plus what does a script or module called "email.py" actually do? Send email? Parse email? "email" is terrible name for a module and you deserve what you got for using it. Name your modules "send_email.py" or "sort_email.py" or if it's a library module of related functions, "email_handling.py". Modules and scripts do things (usually), they should be given action words as names. (**) Questionable though it be, if the Standard Library wants to use an "innocuous" name, It can. Carl Banks That does not solve anything, if the smtplib follows your advice, then you'll be shadowing its send_email module. The only way to avoid collision would be to name your module __PDSFLSDF_send_email__13221sdfsdf__.py That way, the probabilty you'd shadow one package hidden module is below the probability that Misses Hilton ever says something relevant. However nobody wants to use such names. Stephen gave good advices in this thread that helps avoiding this issue. JM -- http://mail.python.org/mailman/listinfo/python-list
unable to catch this exception
Exception in thread Thread-9 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/local/lib/python2.6/threading.py", line 522, in __bootstrap_inner File "/var/www/html/cssh.py", line 875, in run File "/var/www/html/cssh.py", line 617, in ssh_connect : 'NoneType' object has no attribute 'BadAuthenticationType' This happens on interpreter shutdown, even though I do try to catch the AttributeError exception: try: fake = paramiko.BadAuthenticationType try: self.conobj.connect(self.ip, username=self.username, key_filename=self.sshprivkey, port=self.port, timeout=opts.timeout) loginsuccess = True except paramiko.BadAuthenticationType, e: # this is line 617 self.conerror = str(e) except paramiko.SSHException, e: self.conerror = str(e) except socket.timeout, e: self.conerror = str(e) except socket.error, e: self.conerror = str(e) except AttributeError: # this happens on interpreter shutdown self.conerror = 'shutdown' It's clear what happens: paramiko gets its attributes cleared or the module perhaps gets unloaded and as result "paramiko" label leads to None, which obviously has no attribute BadAuthenticationType. However, even though this is surrounded by try .. except AttributeError block, it evidently isn't catch. How to catch that exception? Or at least preven displaying this message? Regards, mk -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop searching takes too long!
On Jan 29, 7:07 pm, Steven D'Aprano wrote: > On Fri, 29 Jan 2010 14:49:06 -0800, Jonathan Gardner wrote: > > On Jan 28, 3:52 pm, elsa wrote: > > >> I've got a problem with my program, in that the code just takes too > >> long to run. Here's what I'm doing. If anyone has any tips, they'd be > >> much appreciated! > > > First of all, don't play with large lists. Large lists have a tendency > > to grow larger over time, until they get absurdly large. > > > If you're dealing with a long list, work with it like you'd work with a > > file. If you need random access, stick it in some form of database, such > > as BDB or PostgreSQL. If you need an index, stick it in some form of DB. > > Eventually, large lists end up like that anyway. Don't fool yourself > > early on---prepare for the worst and solve the problems of tomorrow > > today. > > Talk about premature optimization. The OP probably has a few hundreds of > thousands of items, millions at most, which is trivial on a modern PC. > Your way of thinking is what has led to Firefox using a database to > manage a few thousand bookmarks and cookies, which in turn leads to > consistent data corruption problems. (I've been keeping note, and so far > my installation of Firefox 3 has had database corruption at startup one > time out of five.) > I think there's a difference between writing your code so that you have the option of using a database, or a flat file, or any other type of serial data source, and actually using a database (or whatever.) I prefer to write my code so that I don't have to re-write it 6 months later. Having worked with datasets that are truly enormous, whenever I see a list that is unbounded (as this appears to be), I freak out because unbounded can be a really, really big number. Might as well write software that works for the truly enormous case and the really large case and be done with it once and for all. -- http://mail.python.org/mailman/listinfo/python-list
ANN: GMPY 1.11 released
Everyone, I'm pleased to annouce the final release of GMPY 1.11. GMPY is a wrapper for the MPIR or GMP multiple-precision arithmetic library. GMPY 1.11 is available for download from: http://code.google.com/p/gmpy/ In addition to support for Python 3.x, there are several new features in this release: - Even faster conversion to/from Python longs. - Performance improvements by reducing function overhead. - Performance improvements by improved caching. - Support for cdivmod, fdivmod, and tdivmod. - Unicode strings are accepted on Python 2.x and 3.x. - Fixed regression in GMPY 1.10 where True/False were no longer recognized. Changes since 1.11rc1: - Recognizes GMP 5. - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). Comments on provided binaries The 32-bit Windows installers were compiled with MinGW32 using MPIR 1.3.1 and will automatically recognize the CPU type and use code optimized for the CPU at runtime. The 64-bit Windows installers were compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed instructions are included if you want to compile your own binary. Please report any issues! casevh -- http://mail.python.org/mailman/listinfo/python-list
threading+popen2 hang
Hello,
I've seen many messages and bug reports on popen2 about pipes, buffer
size problems, sub-processes not properly closed, race conditions,
popen2 not being thread safe... But I still can't figure what applies
to my case.
This piece of code:
#!/usr/bin/python
import threading
import popen2
class MyThread ( threading.Thread ):
def run ( self ):
#popenChild = popen2.Popen3("cat /etc/passwd")
#popenChild = popen2.Popen3("/usr/bin/iostat -V")
popenChild = popen2.Popen3("/usr/bin/iostat -k -x 1 2")
popenChild.wait()
print 'Bye'
MyThread().start()
Works fine on RHEL5/python 2.4.3
Hangs on RHEL4/python 2.3.4
I presume it hangs on wait().
It does not hang with:
popenChild = popen2.Popen3("/usr/bin/iostat -V") # short output
popenChild = popen2.Popen3("cat /etc/passwd") # long output
It does not hang outside of a thread:
#!/usr/bin/python
import popen2
popenChild = popen2.Popen3("/usr/bin/iostat -k -x 1 2")
#print popenChild.fromchild.readlines()
popenChild.wait()
print 'Bye'
Could someone explain this to me ?
Thanks in advance.
Louis Coilliot
--
http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
Masklinn wrote:
When trying to load the following config file, I get an error
``ConfigParser.NoOptionError: No option 'handlers' in section: 'logger_0'`` (in
both Python 2.6.4 and Python 3.1.1 on OSX, obviously ConfigParser is spelled
configparser in 3.1):
[loggers]
keys=root,0
[handlers]
keys=console
[formatters]
keys=simple
[logger_root]
handlers=console
[logger_0]
level=DEBUG
qualname=0
[handler_console]
class=StreamHandler
formatter=simple
args=()
[formatter_simple]
format=%(asctime)s:%(levelname)-8s:%(name)s::%(message)s
the goal is simply to have a logging level different on ``0`` than it is on
``root``, but to get it I have to include a handler on ``0`` and stop
propagation (or messages are displayed on both root and 0).
Do note that this behavior (of mandating handlers) does *not* happen when
loggers are configured programmatically.
Should this be considered a bug? Worthy of opening a request on the tracker?
And while I'm at it, a few other oddities/annoyances I noticed in logging:
* have to specify the `root` logger in loggers/keys, even though it's mandatory
to configure the root logger, or I get the following error::
Traceback (most recent call last):
File "test.py", line 6, in
logging.config.fileConfig('logging.conf')
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/logging/config.py",
line 82, in fileConfig
_install_loggers(cp, handlers, disable_existing_loggers)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/logging/config.py",
line 183, in _install_loggers
llist.remove("root")
ValueError: list.remove(x): x not in list
* the ``args`` option is required when defining a handler, even in the example
above where the handler doesn't take any argument (mandatory ones, anyway)
* Logger.log() doesn't take level names, only numerical levels, even after
having called ``addLevelName``. This makes logging with custom levels much less
clear as one has to write something along the lines of ``logging.log(100,
'Houston, we have a problem')`` instead of the clearer
``logging.log('PANTS_ON_FIRE', 'Houston, we have a problem')``. Note that since
the introduction of _checkLevel fixing that is trivial:
To add a custom level, I would proceed that way:
logging.ALERT = 45
logging.addLevelName(logging.ALERT, 'ALERT !!')
logging.getLogger().log(logging.ALERT, 'test')
Passing a string to the log method as you did is incorrect.
Regarding your first point, I guess it's anti pattern. One way to do it:
1/ Configure the root logger with the lowest value 0, so the root logger
does not filter any level.
2/ Configure each of your logger with the correct level
That way you can configure your '0' logger as you (badly :o)) named it
with one level, and configure a potential '1' logger with another level.
Don't bother with propagation. That way you won't need to duplicate your
handlers on every logger.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: unable to catch this exception
On Tue, Feb 2, 2010 at 3:20 AM, mk wrote: > Exception in thread Thread-9 (most likely raised during interpreter > shutdown): > Traceback (most recent call last): > File "/usr/local/lib/python2.6/threading.py", line 522, in > __bootstrap_inner > File "/var/www/html/cssh.py", line 875, in run > File "/var/www/html/cssh.py", line 617, in ssh_connect > : 'NoneType' object has no attribute > 'BadAuthenticationType' > > > This happens on interpreter shutdown, even though I do try to catch the > AttributeError exception: > > try: > fake = paramiko.BadAuthenticationType > try: > self.conobj.connect(self.ip, username=self.username, > key_filename=self.sshprivkey, port=self.port, timeout=opts.timeout) > loginsuccess = True > except paramiko.BadAuthenticationType, e: # this is line 617 > self.conerror = str(e) > except paramiko.SSHException, e: > self.conerror = str(e) > except socket.timeout, e: > self.conerror = str(e) > except socket.error, e: > self.conerror = str(e) > except AttributeError: > # this happens on interpreter shutdown > self.conerror = 'shutdown' > > > It's clear what happens: paramiko gets its attributes cleared or the module > perhaps gets unloaded and as result "paramiko" label leads to None, which > obviously has no attribute BadAuthenticationType. > > However, even though this is surrounded by try .. except AttributeError > block, it evidently isn't catch. How to catch that exception? Or at least > preven displaying this message? Let's see if psychic debugging works...at 4 am... Pure conjecture: Do you have something like the following elsewhere in your code?: try: #code except SomeError, AttributeError: #code For why this causes problems, consider: except SomeError, e: vs. except SomeError, SomeOtherError: Example: try: raise IndexError except IndexError, IOError: pass print repr(IOError) #==> IndexError() Hence, in your case, `AttributeError` may no longer refer to AttributeError. You can check this by adding a `print repr(AttributeError)` at the right place in your code. I further conjecture that pyflakes/pychecker/etc. might issue a warning about the offending bit of code. "Third Option" solution: Since you take the same action no matter the exception's type, have you considered simplifying your code to: fake = paramiko.BadAuthenticationType try: self.conobj.connect(self.ip, username=self.username, key_filename=self.sshprivkey, port=self.port, timeout=opts.timeout) loginsuccess = True except Exception, e: self.conerror = str(e) Cheers, Chris -- http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
passing string for editing in input()
Hello, Is there an easy way to get an editing (readline) in Python that would contain string for editing and would not just be empty? I googled but found nothing. Regards, mk -- http://mail.python.org/mailman/listinfo/python-list
Re: passing string for editing in input()
On Tue, Feb 2, 2010 at 5:24 AM, mk wrote: > Hello, > > Is there an easy way to get an editing (readline) in Python that would > contain string for editing and would not just be empty? > > I googled but found nothing. Er...: http://docs.python.org/library/readline.html It's the third hit for "python readline". Actually reading the page, sounds like you want readline.insert_text() specifically. Cheers, Chris -- Satan, thy name is MMW http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: recv_into(bytearray) complains about a "pinned buffer"
Le Tue, 02 Feb 2010 00:12:34 +0100, Martin v. Loewis a écrit : >> recv_into() should simply be fixed to use the new buffer API, as it >> does in 3.x. > > I don't think that's the full solution. The array module should also > implement the new buffer API, so that it would also fail with the old > recv_into. There was a patch for this in http://bugs.python.org/issue6071 , but the bug was closed when hashlib was "fixed". -- http://mail.python.org/mailman/listinfo/python-list
Re: passing string for editing in input()
mk wrote: > Is there an easy way to get an editing (readline) in Python that would > contain string for editing and would not just be empty? http://mail.python.org/pipermail/python-list/2009-June/1209309.html Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Let me preface everything by thanking you and all those who replied for their comments. I have only one follow-up question (or rather, set of related questions) that I'm very keen about, plus a bit of a vent at the end. In Steven D'Aprano writes: >As for fixing it, unfortunately it's not quite so simple to fix without >breaking backwards-compatibility. The opportunity to do so for Python 3.0 >was missed. This last point is to me the most befuddling of all. Does anyone know why this opportunity was missed for 3.0? Anyone out there with the inside scoop on this? Was the fixing of this problem discussed in some PEP or some mailing list thread? (I've tried Googling this but did not hit on the right keywords to bring up the deliberations I'm looking for.) ~k [NB: as I said before, what follows begins to slide into a vent, and is quite unimportant; I've left it, for whatever grain of truth it may contain, as an grossly overgrown PS; feel free to ignore it, I'm *by far* most interested in the question stated in the paragraph right above, because it will give me, I hope, a better sense of where the biggest obstacles to fixing this problem lie.] P.S. Yes, I see the backwards-compatibility problem, but that's what rolling out a whole new versions is good for; it's a bit of a fresh start. I remember hearing GvR's Google Talk on the coming Python 3, which was still in the works then, and being struck by the sheer *modesty* of the proposed changes (while the developers of the mythical Perl6 seemed to be on a quest for transcendence to a Higher Plane of Programming, as they still are). In particular the business with print -> print() seemed truly bizarre to me: this is a change that will break a *huge* volume of code, and yet, judging by the rationale given for it, the change solves what are, IMHO, a relatively minor annoyances. Python's old print statement is, I think, at most a tiny little zit invisible to all but those obsessed with absolute perfection. And I can't imagine that whatever would be required to fix Python's import system could break more code than redefining the rules for a workhorse like print. In contrast, the Python import problem is a ticking bomb potentially affecting all code that imports other modules. All that needs to happen is that, in a future release of Python, some new standard module emerges (like numbers.py emerged in 2.6), and this module is imported by some module your code imports. Boom! Note that it was only coincidental that the bug I reported in this thread occurred in a script I wrote recently. I could have written both scripts before 2.6 was released, and the new numbers.py along with it; barring the uncanny clairvoyance of some responders, there would have been, at the time, absolutely no plausible reason for not naming one of the two scripts numbers.py. To the argument that the import system can't be easily fixed because it breaks existing code, one can reply that the *current* import system already breaks existing code, as illustrated by the example I've given in this thread: this could have easily been old pre-2.6 code that got broken just because Python decided to add numbers.py to the distribution. (Yes, Python can't guarantee that the names of new standard modules won't clash with the names of existing local modules, but this is true for Perl as well, and due to Perl's module import scheme (and naming conventions), a scenario like the one I presented in this thread would have been astronomically improbable. The Perl example shows that the design of the module import scheme and naming conventions for standard modules can go a long way to minimize the consequences of this unavoidable potential for future name clashes.) -- http://mail.python.org/mailman/listinfo/python-list
Re: passing string for editing in input()
Peter Otten wrote: mk wrote: Is there an easy way to get an editing (readline) in Python that would contain string for editing and would not just be empty? http://mail.python.org/pipermail/python-list/2009-June/1209309.html Peter Thanks a lot! Just what I needed. Regards, mk -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterating over a function call
[snip] >> 2. side effect of (maybe) leaking the iterator variable "value" into >> the code following the loop (if the iterator is not empty). > > So? it is sometime useful. Except that you can't guarantee that it will be set since the for loop will not execute if the iterable is empty. >> >> I can take care of 2 by explicitly deleting the variable at the end: >> >> del value >> >> but I'd probably forget to do that sometimes. > > So? If having 'value' bound breaks your subsequent code, I consider it > buggy. Quite so. I just like to eliminate the possibility up front. If 'value' is never bound, the the bug will show up sooner. -- Gerald Britton -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On 2010-02-02, Roy Smith wrote: > In article , kj > wrote: > >> Through a *lot* of trial an error I finally discovered that the >> root cause of the problem was the fact that, in the same directory >> as buggy.py, there is *another* innocuous little script, totally >> unrelated, whose name happens to be numbers.py. >> [...] >> It turns out that buggy.py imports psycopg2, as you can see, and >> apparently psycopg2 (or something imported by psycopg2) tries to >> import some standard Python module called numbers; instead it ends >> up importing the innocent myscript/numbers.py, resulting in *absolute >> mayhem*. > > I feel your pain, but this is not a Python problem, per-se. I think it is. There should be different syntax to import from "standard" places and from "current directory". Similar to the difference between "foo.h" and in cpp. > The general > pattern is: > > 1) You have something which refers to a resource by name. > > 2) There is a sequence of places which are searched for this >name. Searching the current directory by default is the problem. Nobody in their right mind has "." in the shell PATH and IMO it shouldn't be in Python's import path either. Even those wreckless souls who do put "." in their path put it at the end so they don't accidentally override system commands. -- Grant Edwards grante Yow! So this is what it at feels like to be potato visi.comsalad -- http://mail.python.org/mailman/listinfo/python-list
Re: Python packet capture utility
On 2010-02-02, VYAS ASHISH M-NTB837 wrote: > > Dear All > > I want to capture tcp packets in python. I need to do this on both > Windows and Linux on python3.1 > > I came across the following: > http://sourceforge.net/projects/pycap/ > http://sourceforge.net/projects/pylibpcap/ > http://code.google.com/p/pypcap/ > http://oss.coresecurity.com/projects/pcapy.html > > > I am not able to evaluate on my own. And we're supposed to evaluate them for you? pycap: last release 5/2003. pylibpcap: last release 5/2008 pycap: last release 1/2007 pcapy: last release 3/2007 > Which one should I pick up? I'd start with the newest one. It's the one I use, and it works fine for me. > Priority is python3.1 support on both windows and Linux. I don't think any of them support 3.1. > I don't have to do many/complex operations. If it is not so > programmer friendly I am OK. > > Also let me know if 2to3 would help here if there is not > python3 support. I'f you're not expereienced porting libraries from 2.4 to 3.1, then you shouldn't be using 3.1. -- Grant Edwards grante Yow! Did you move a lot of at KOREAN STEAK KNIVES this visi.comtrip, Dingy? -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, Feb 2, 2010 at 6:13 AM, kj wrote: > In Steven > D'Aprano writes: > > >As for fixing it, unfortunately it's not quite so simple to fix without > >breaking backwards-compatibility. The opportunity to do so for Python 3.0 > >was missed. > > This last point is to me the most befuddling of all. Does anyone > know why this opportunity was missed for 3.0? Anyone out there > with the inside scoop on this? Was the fixing of this problem > discussed in some PEP or some mailing list thread? (I've tried > Googling this but did not hit on the right keywords to bring up > the deliberations I'm looking for.) > The problem with "fixing" the import system is that touching it in any way potentially breaks *vast* volumes of code that works just right, right now in any version of Python. It's not even something you can easily test: there's a lot of edge-cases supporting various features that have been added over the years. A pure-python import mechanism with a set of test-cases to "prove" it reliably mimic'd the existing mechanism wasn't even complete by the time Python3 came out, without that, any changes to "fix" Python3+'s import system would just be a shot in the dark. And there'd be no telling just /what/ it would break if you start changing these very old import semantics. > P.S. Yes, I see the backwards-compatibility problem, but that's > what rolling out a whole new versions is good for; it's a bit of > a fresh start. I remember hearing GvR's Google Talk on the coming > Python 3, which was still in the works then, and being struck by > the sheer *modesty* of the proposed changes (while the developers > of the mythical Perl6 seemed to be on a quest for transcendence to > a Higher Plane of Programming, as they still are). Yes, it was a relatively modest upgrade, thankfully so. We actually have our fixed language, and Perl6 is coming on some point on the horizon. Python3 allowed backwards incompatible changes, but they still needed to have a justification to them: and more importantly, they usually needed to change from one well-defined state to a new, 'cleaner' well-defined state, so they could be automatically corrected or at least easily found. The Bytes/Unicode situation is one case where there wasn't a well-defined state you can convert from, and so with Python3, every single string you really need to look at and decide, "Should this have been bytes, or characters?". Having to ask that question for every string is a significant burden, to expect someone to have to ask the same sort of question for every single import is asking -way- too much for people porting to Python 3. Py3k's adoption is a slow, uphill process-- no one expected (from my reading at least)-- it to take less then years and multiple 3.x iterations before people would /really/ significantly start using it. There's too many third party modules people depend on and they have to slowly be converted. They're being converted, and IMHO there's steadily growing momentum on this (albeit not huge momentum), but had they messed with the import semantics-- this would be /way/ more difficult, and you might end up with a DOA project. > In particular > the business with print -> print() seemed truly bizarre to me: this > is a change that will break a *huge* volume of code, and yet, > judging by the rationale given for it, the change solves what are, > IMHO, a relatively minor annoyances. Python's old print statement > is, I think, at most a tiny little zit invisible to all but those > obsessed with absolute perfection. You have a very strange perception of huge. For one thing, every single use of print() can be converted -automatically-: the rules of this change are very clear. The print statement was a bizarre sort of wart (look at >>!) and fixing it is easy. Further, *huge* volume of code-- /really/?! In my experience, print isn't really all /that/ common after you get out of the tutorial and start doing real code. If you're doing lots of shell scripting maybe that's not the case: but for any sort of server-daemon-process sort of apps, print is utterly unacceptable. I use the logging module. For GUI apps, same. But for those times when you use print.. its /really easy/ to fix. And I can't imagine that whatever > would be required to fix Python's import system could break more > code than redefining the rules for a workhorse like print. > Your imagination is lacking here then: virtually every single bit of Python code uses import, and messing with it can have wide implications that you can't even /define/ ahead of time. As such you can't write a guide, a 2to3 fixer, or a HOWTO to tell people: hey, this is how you used to do things in Python2, this is how you do them in Python3. Having them mess with the import machinery would be throwing every Py3 developer under the bus, saying, "Well, just run it. Fix whatever errors happen." > In contrast, the Python import problem is a ticking bomb potentially > affecting all code that impor
Re: Python and Ruby
Jonathan Gardner wrote: One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. $bar = foo; # Call 'foo; with no args, assign to '$bar' $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar' # By the way, this '&' is not the bitwise-and '&' $bar->() # Call whatever '$bar' is pointing at with no args Compare with python: foo() # Call 'foo' with no args. bar = foo() # 'bar' is now pointing to whatever 'foo()' returned bar = foo # 'bar' is now pointing to the same thing 'foo' points to bar() # Call 'bar' with no args One is simple, consistent, and easy to explain. The other one requires the introduction of advanced syntax and an entirely new syntax to make function calls with references. If you get rid of the syntax specific to Perl, then having to explicitly obtain a function reference, or to dereference the result, is not such a big deal: foo # Call 'foo' with no args. bar = foo# Call 'foo; with no args, assign to 'bar' bar = &foo # Don't call 'foo', but assign a pointer to it to 'bar' bar^ # Call whatever 'bar' is pointing at with no args (Here I use ^ instead of -> to dereference.) Compared with Python, it saves 3 lots of (), but needs & and ^ added. Still a net saving. One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. I'd say that having this "&" symbol in front of "foo" makes it more obvious than just foo by itself. But I agree not quite as clean. Another thing is that you have to know whether "bar" is a function, or a function ref, and use the appropriate syntax. Sometimes this is helpful, sometimes not. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
Jean-Michel Pichavant wrote:
>To add a custom level, I would proceed that way:
>
>logging.ALERT = 45
>logging.addLevelName(logging.ALERT, 'ALERT !!')
>logging.getLogger().log(logging.ALERT, 'test')
>
>Passing a string to the log method as you did is incorrect.
I know it's currently incorrect. My point was more along the line that there
was *no reason* for it to be incorrect. logging already contains all the tools
for log('PANTS_ON_FIRE') to be allowed
>Regarding your first point, I guess it's anti pattern. One way to do it:
>1/ Configure the root logger with the lowest value 0, so the root logger
>does not filter any level.
>2/ Configure each of your logger with the correct level
>
>That way you can configure your '0' logger as you (badly :o)) named it
>with one level, and configure a potential '1' logger with another level.
>Don't bother with propagation. That way you won't need to duplicate your
>handlers on every logger.
re logger 0, no need for complex name for a test case (and it allowed me to
create easy-to-remember 0.1 and 0.1.2 if needed)
Re your answer, from what I understand you want the root logger to NOTSET and
then each child logger with its correct level? But that's not a solution, each
and every level will *still* require a handler explicitly configured on it.
That's in fact very much my issue: logging refuses that a logger be
handler-less in a config file, it's mandatory to configure a handler any time a
logger is configured.
--
http://mail.python.org/mailman/listinfo/python-list
ANN: Leo 4.7 b3 released
Leo 4.7 beta 3 February 2, 2009 Leo 4.7 beta 3 is now available at: http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106 Leo 4.7 beta 3 fixes all known serious bugs in Leo. Leo is a text editor, data organizer, project manager and much more. See: http://webpages.charter.net/edreamleo/intro.html The highlights of Leo 4.7: -- - Leo now uses the simplest possible internal data model. This is the so-called "one-node" world. - Leo supports Python 3.x. - Leo requires Python 2.6 or above. - Several important improvements in file handling. - Leo converts @file nodes to @thin nodes automatically. - @auto-rst now works much more reliably reliably. - Leo no longer @noref trees. Such trees are not reliable in cooperative environments. - A new Windows installer. - Many other features, including new command line options and new plugins. - Dozens of bug fixes. Edward K. Ream Links: -- Leo: http://webpages.charter.net/edreamleo/front.html Forum:http://groups.google.com/group/leo-editor Download: http://sourceforge.net/project/showfiles.php?group_id=3458 Bzr: http://code.launchpad.net/leo-editor/ Quotes: http://webpages.charter.net/edreamleo/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
No return to the parent function
I've a main function called i.e. *foo()* which has a block of code that is repetead several times (for the error catching code and error reporting), but that code has a return to exit of *foo()* --- foo(): ... if self.background: _log.exception(str(error)) return ReturnCode.ERROR, None else: raise NameError(error) --- So I would tu put that code block into a separated function (*throw() *), but the problem is that it returns to the parent function (foo()). How to solve it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Logging oddity: handlers mandatory in every single logger?
Masklinn wrote:
Jean-Michel Pichavant wrote:
To add a custom level, I would proceed that way:
logging.ALERT = 45
logging.addLevelName(logging.ALERT, 'ALERT !!')
logging.getLogger().log(logging.ALERT, 'test')
Passing a string to the log method as you did is incorrect.
I know it's currently incorrect. My point was more along the line that there
was *no reason* for it to be incorrect. logging already contains all the tools
for log('PANTS_ON_FIRE') to be allowed
The reason is that log takes an *int* as first argument that defines the
logging level. You gave a string. So There is definitely a reason for it
to be incorrect.
Regarding your first point, I guess it's anti pattern. One way to do it:
1/ Configure the root logger with the lowest value 0, so the root logger
does not filter any level.
2/ Configure each of your logger with the correct level
That way you can configure your '0' logger as you (badly :o)) named it
with one level, and configure a potential '1' logger with another level.
Don't bother with propagation. That way you won't need to duplicate your
handlers on every logger.
re logger 0, no need for complex name for a test case (and it allowed me to
create easy-to-remember 0.1 and 0.1.2 if needed)
Re your answer, from what I understand you want the root logger to NOTSET and
then each child logger with its correct level? But that's not a solution, each
and every level will *still* require a handler explicitly configured on it.
That's in fact very much my issue: logging refuses that a logger be
handler-less in a config file, it's mandatory to configure a handler any time a
logger is configured.
the field handlers must be defined even if empty.
[loggers]
keys=root,0,1
[handlers]
keys=console
[formatters]
keys=simple
[logger_root]
level=DEBUG
handlers=console
[logger_1]
level=INFO
qualname=1
handlers=
[logger_0]
level=DEBUG
qualname=0
handlers=
[handler_console]
class=StreamHandler
formatter=simple
args=()
[formatter_simple]
format=%(asctime)s:%(levelname)-8s:%(name)s::%(message)s
import logging; import logging.config
logging.config.fileConfig("log.config")
l1 = logging.getLogger("1")
l0 = logging.getLogger("0")
l1.debug('I am l1')
...
l0.debug('I am l0')
... 2010-02-02 17:48:55,710:DEBUG :0::I am l0
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: No return to the parent function
Joan Miller writes: > I've a main function called i.e. *foo()* which has a block of code > that is repetead several times (for the error catching code and error > reporting), but that code has a return to exit of *foo()* > > --- > foo(): > ... > if self.background: > _log.exception(str(error)) > return ReturnCode.ERROR, None > else: > raise NameError(error) > > --- > > So I would tu put that code block into a separated function (*throw() > *), but the problem is that it returns to the parent function (foo()). > How to solve it? If I understand correctly, you can simply do this: def throw(...): if ...: ... return ... else: raise ... def foo(): ... return throw(...) HTH I.e. if throw returns something, foo returns it as well. If throw raises an exception, it will go through foo. Is this what you want? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: No return to the parent function
On 2 feb, 16:55, Arnaud Delobelle wrote: > Joan Miller writes: > > I've a main function called i.e. *foo()* which has a block of code > > that is repetead several times (for the error catching code and error > > reporting), but that code has a return to exit of *foo()* > > > --- > > foo(): > > ... > > if self.background: > > _log.exception(str(error)) > > return ReturnCode.ERROR, None > > else: > > raise NameError(error) > > > --- > > > So I would tu put that code block into a separated function (*throw() > > *), but the problem is that it returns to the parent function (foo()). > > How to solve it? > > If I understand correctly, you can simply do this: > > def throw(...): > if ...: > ... > return ... > else: > raise ... > > def foo(): > ... > return throw(...) > > HTH > > I.e. if throw returns something, foo returns it as well. If throw > raises an exception, it will go through foo. Is this what you want? > > -- > Arnaud Yes, that is it. It was more simple that I had thinked, thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote:
>>> It turns out that buggy.py imports psycopg2, as you can see, and
>>> apparently psycopg2 (or something imported by psycopg2) tries to
>>> import some standard Python module called numbers; instead it ends
>>> up importing the innocent myscript/numbers.py, resulting in *absolute
>>> mayhem*.
>>
>> I feel your pain, but this is not a Python problem, per-se.
>
> I think it is.
I agree.
> There should be different syntax to import from
> "standard" places and from "current directory". Similar to the
> difference between "foo.h" and in cpp.
I don't know if that's necessary. Only supporting the "foo.h" case would
work fine if Python behaved like gcc, i.e. if the "current directory"
referred to the directory contain the file performing the import rather
than in the process' CWD.
As it stands, imports are dynamically scoped, when they should be
lexically scoped.
>> The general
>> pattern is:
>>
>> 1) You have something which refers to a resource by name.
>>
>> 2) There is a sequence of places which are searched for this
>>name.
>
> Searching the current directory by default is the problem.
> Nobody in their right mind has "." in the shell PATH and IMO it
> shouldn't be in Python's import path either. Even those
> wreckless souls who do put "." in their path put it at the end
> so they don't accidentally override system commands.
Except, what should be happening here is that it should be searching the
directory containing the file performing the import *first*. If foo.py
contains "import bar", and there's a bar.py in the same directory as
foo.py, that's the one it should be using.
The existing behaviour is simply wrong, and there's no excuse for it
("but it's easier to implement" isn't a legitimate argument).
The only situation where the process' CWD should be used is for an import
statement in a non-file source (i.e. stdin or the argument to the -c
switch).
--
http://mail.python.org/mailman/listinfo/python-list
Re: No return to the parent function
Joan Miller wrote: I've a main function called i.e. *foo()* which has a block of code that is repetead several times (for the error catching code and error reporting), but that code has a return to exit of *foo()* --- foo(): ... if self.background: _log.exception(str(error)) return ReturnCode.ERROR, None else: raise NameError(error) --- So I would tu put that code block into a separated function (*throw() *), but the problem is that it returns to the parent function (foo()). How to solve it? Call it in a return statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
* Nobody:
On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote:
It turns out that buggy.py imports psycopg2, as you can see, and
apparently psycopg2 (or something imported by psycopg2) tries to
import some standard Python module called numbers; instead it ends
up importing the innocent myscript/numbers.py, resulting in *absolute
mayhem*.
I feel your pain, but this is not a Python problem, per-se.
I think it is.
I agree.
There should be different syntax to import from
"standard" places and from "current directory". Similar to the
difference between "foo.h" and in cpp.
I don't know if that's necessary. Only supporting the "foo.h" case would
work fine if Python behaved like gcc, i.e. if the "current directory"
referred to the directory contain the file performing the import rather
than in the process' CWD.
As it stands, imports are dynamically scoped, when they should be
lexically scoped.
The general
pattern is:
1) You have something which refers to a resource by name.
2) There is a sequence of places which are searched for this
name.
Searching the current directory by default is the problem.
Nobody in their right mind has "." in the shell PATH and IMO it
shouldn't be in Python's import path either. Even those
wreckless souls who do put "." in their path put it at the end
so they don't accidentally override system commands.
Except, what should be happening here is that it should be searching the
directory containing the file performing the import *first*. If foo.py
contains "import bar", and there's a bar.py in the same directory as
foo.py, that's the one it should be using.
The existing behaviour is simply wrong, and there's no excuse for it
("but it's easier to implement" isn't a legitimate argument).
+1
The only situation where the process' CWD should be used is for an import
statement in a non-file source (i.e. stdin or the argument to the -c
switch).
Hm, not sure about that last.
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On 2/2/2010 9:13 AM, kj wrote: As for fixing it, unfortunately it's not quite so simple to fix without breaking backwards-compatibility. The opportunity to do so for Python 3.0 was missed. This last point is to me the most befuddling of all. Does anyone know why this opportunity was missed for 3.0? Anyone out there with the inside scoop on this? Was the fixing of this problem discussed in some PEP or some mailing list thread? (I've tried Googling this but did not hit on the right keywords to bring up the deliberations I'm looking for.) There was a proposal to put the whole stdlib into a gigantic package, so that import itertools would become, for instance import std.itertools. Guido rejected that. I believe he both did not like it and was concerned about making upgrade to 3.x even harder. The discussion was probably on the now closed py3k list. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
What's this vText() annotation mean?
What does this vText() annotation mean in a returned list:- [['Apr 19', vText(u'PAYE'), ''], ['Mar 31', vText(u'VAT'), ''], ['May 19', vText(u'Year end PAYE'), '']] I *guess* it's some sort of indication of non-constant text, I need a way to make it constant (well, to get a constant copy of it) because a function I'm passing it to is complaining about a type mismatch:- TypeError: in method 'Fl_Input__value', argument 2 of type 'char const *' -- Chris Green -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 2, 9:02 am, Nobody wrote: > I don't know if that's necessary. Only supporting the "foo.h" case would > work fine if Python behaved like gcc, i.e. if the "current directory" > referred to the directory contain the file performing the import rather > than in the process' CWD. > > As it stands, imports are dynamically scoped, when they should be > lexically scoped. Mostly incorrect. The CWD is in sys.path only for interactive sessions, and when started with -c switch. When running scripts, the directory where the script is located is used instead, not the process's working directory. So, no, it isn't anything like dynamic scoping. > The only situation where the process' CWD should be used is for an import > statement in a non-file source (i.e. stdin or the argument to the -c > switch). It already is that way, chief. I think you're misunderstanding what's wrong here; the CWD doesn't have anything to do with it. Even if CWD isn't in the path you still get the bad behavior kj noted. So now what? Python's importing can be improved but there's no foolproof way to get rid of the fundamental problem of name clashes. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 2, 2:49 am, Jean-Michel Pichavant wrote: > Carl Banks wrote: > > Name your modules "send_email.py" or "sort_email.py" or if it's a > > library module of related functions, "email_handling.py". Modules and > > scripts do things (usually), they should be given action words as > > names. > > > (**) Questionable though it be, if the Standard Library wants to use > > an "innocuous" name, It can. > > That does not solve anything, Of course it does, it solves the problem of having poorly-named modules. It also helps reduce possibility of name clashes. > if the smtplib follows your advice, then > you'll be shadowing its send_email module. > The only way to avoid collision would be to name your module > __PDSFLSDF_send_email__13221sdfsdf__.py I know, and as we all know accidental name clashes are the end of the world and Mother Python should protect us feeble victims from any remote possibility of ever having a name clash. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: What's this vText() annotation mean?
tinn...@isbd.co.uk writes: > What does this vText() annotation mean in a returned list:- > > [['Apr 19', vText(u'PAYE'), ''], It means your list contains an instance of a class whose __repr__() method returns "vText(u'PAYE')". If it follows common practice, the class is probably named "vText". You are likely to be importing and using a module that defines a class called "vText". I don't know such a module, I don't think it's in the standard library so it would be useful if you gave more details about the context. A quick google for "vtext python" yields something about an iCalendar package for python. Is it what you are using? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: recv_into(bytearray) complains about a "pinned buffer"
> Clearly it was added to work with an array, and it's > being used with an array. Why shouldn't people use it > with Python 2.x? Because it's not thread-safe; it may crash the interpreter if used incorrectly. Of course, if you don't share the array across threads, it can be safe to use. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Carl Banks wrote: On Feb 2, 2:49 am, Jean-Michel Pichavant wrote: Carl Banks wrote: Name your modules "send_email.py" or "sort_email.py" or if it's a library module of related functions, "email_handling.py". Modules and scripts do things (usually), they should be given action words as names. (**) Questionable though it be, if the Standard Library wants to use an "innocuous" name, It can. That does not solve anything, Of course it does, it solves the problem of having poorly-named modules. It also helps reduce possibility of name clashes. Actually don't you think it will increase the possibility ? There are much less possibilties of properly naming an object than badly naming it. So if everybody tend to properly name their object with their obvious version like you proposed, the set of possible names will decrease, increasing the clash ratio. I'm just nitpicking by the way, but it may be better to ask for better namespacing instead of naming (which is good thing but unrelated to the OP issue). JM -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
In Terry Reedy writes: >On 2/2/2010 9:13 AM, kj wrote: >>> As for fixing it, unfortunately it's not quite so simple to fix without >>> breaking backwards-compatibility. The opportunity to do so for Python 3.0 >>> was missed. >> >> This last point is to me the most befuddling of all. Does anyone >> know why this opportunity was missed for 3.0? Anyone out there >> with the inside scoop on this? Was the fixing of this problem >> discussed in some PEP or some mailing list thread? (I've tried >> Googling this but did not hit on the right keywords to bring up >> the deliberations I'm looking for.) >There was a proposal to put the whole stdlib into a gigantic package, so >that >import itertools >would become, for instance >import std.itertools. >Guido rejected that. I believe he both did not like it and was concerned >about making upgrade to 3.x even harder. The discussion was probably on >the now closed py3k list. Thanks. I'll look for this thread. ~K -- http://mail.python.org/mailman/listinfo/python-list
lists as an efficient implementation of large two-dimensional arrays(!)
An instructive lesson in YAGNI ("you aren't going to need it"),
premature optimization, and not making assumptions about Python data
structure implementations.
I need a 1000 x 1000 two-dimensional array of objects. (Since they are
instances of application classes it appears that the array module is
useless; likewise, since I am using Python 3.1, so among other things,
I can't use numpy or its relatives.) The usage pattern is that the
array is first completely filled with objects. Later, objects are
sometimes accessed individually by row and column and often the entire
array is iterated over.
Worried (unnecessarily, as it turns out) by the prospect of 1,000,000
element list I started by constructing a dictionary with the keys 1
through 1000, each of which had as its value another dictionary with
the keys 1 through 1000. Actual values were the values of the second
level dictionary.
Using numbers to fill the array to minimize the effect of creating my
more complex objects, and running Python 3.1.1 on an 8-core Mac Pro
with 8Gb memory, I tried the following
#create and fill the array:
t1 = time.time()
d2 = {}
for j in range(1000):
d2[j] = dict()
for k in range(1000):
d2[j][k] = k
print( round(time.time() - t1, 2))
0.41
# access each element of the array:
t1 = time.time()
for j in range(1000):
for k in range(1000):
elt = d2[j][k]
print( round(time.time() - t1, 2))
0.55
My program was too slow, so I started investigating whether I could
improve on the two-level dictionary, which got used a lot. To get
another baseline I tried a pure 1,000,000-element list, expecting the
times to be be horrendous, but look!
# fill a list using append
t1 = time.time()
lst = []
for n in range(100):
lst.append(n)
print( round(time.time() - t1, 2))
0.26
# access every element of a list
t1 = time.time()
for n in range(100):
elt = lst[n]
print( round(time.time() - t1, 2))
0.25
What a shock! I could save half the execution time and all my clever
work and awkward double-layer dictionary expressions by just using a
list!
Even better, look what happens using a comprehension to create the
list instead of a loop with list.append:
t1 = time.time()
lst = [n for n in range(100)]
print( round(time.time() - t1, 2))
0.11
Half again to create the list.
Iterating over the whole list is easier and faster than iterating over
the double-level dictionary, in particular because it doesn't involve
a two-level loop. But what about individual access given a row and a
column?
t1 = time.time()
for j in range(1000):
for k in range(1000):
elt = lst[j * 1000 + k]
print( round(time.time() - t1, 2))
0.45
This is the same as for the dictionary.
I tried a two-level list and a few other things but still haven't
found anything that works better than a single long list -- just like
2-D arrays are coded in old-style languages, with indices computed as
offsets from the beginning of the linear sequence of all the values.
What's amazing is that creating and accessing 1,000,000-element list
in Python is so efficient. The usual moral obtains: start simple,
analyze problems (functional or performance) as they arise, decide
whether they are worth the cost of change, then change in very limited
ways. And of course abstract and modularize so that, in my case, for
example, none of the program's code would be affected by the change
from a two-level dictionary representation to using a single long list.
I realize there are many directions an analysis like this can follow,
and many factors affecting it, including patterns of use. I just
wanted to demonstrate the basics for a situation that I just
encountered. In particular, if the array was sparse, rather than
completely full, the two-level dictionary implementation would be the
natural representation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 2, 11:07 am, Jean-Michel Pichavant wrote: > Carl Banks wrote: > > On Feb 2, 2:49 am, Jean-Michel Pichavant > > wrote: > > >> Carl Banks wrote: > > >>> Name your modules "send_email.py" or "sort_email.py" or if it's a > >>> library module of related functions, "email_handling.py". Modules and > >>> scripts do things (usually), they should be given action words as > >>> names. > > >>> (**) Questionable though it be, if the Standard Library wants to use > >>> an "innocuous" name, It can. > > >> That does not solve anything, > > > Of course it does, it solves the problem of having poorly-named > > modules. It also helps reduce possibility of name clashes. > > Actually don't you think it will increase the possibility ? There are > much less possibilties of properly naming an object than badly naming it. You've got to be kidding me, you're saying that a bad name like email.py is less likely to clash than a more descriptive name like send_email.py? > So if everybody tend to properly name their object with their obvious > version like you proposed, the set of possible names will decrease, > increasing the clash ratio. I did not propose obvious module names. I said obvious names like email.py are bad; more descriptive names like send_email.py are better. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: lists as an efficient implementation of large two-dimensional arrays(!)
Did you try it with an array object using the array module?
On Tue, Feb 2, 2010 at 3:14 PM, Mitchell L Model wrote:
> An instructive lesson in YAGNI ("you aren't going to need it"), premature
> optimization, and not making assumptions about Python data structure
> implementations.
>
> I need a 1000 x 1000 two-dimensional array of objects. (Since they are
> instances of application classes it appears that the array module is
> useless; likewise, since I am using Python 3.1, so among other things, I
> can't use numpy or its relatives.) The usage pattern is that the array is
> first completely filled with objects. Later, objects are sometimes accessed
> individually by row and column and often the entire array is iterated over.
>
> Worried (unnecessarily, as it turns out) by the prospect of 1,000,000
> element list I started by constructing a dictionary with the keys 1 through
> 1000, each of which had as its value another dictionary with the keys 1
> through 1000. Actual values were the values of the second level dictionary.
>
> Using numbers to fill the array to minimize the effect of creating my more
> complex objects, and running Python 3.1.1 on an 8-core Mac Pro with 8Gb
> memory, I tried the following
>
> #create and fill the array:
> t1 = time.time()
> d2 = {}
> for j in range(1000):
> d2[j] = dict()
> for k in range(1000):
> d2[j][k] = k
> print( round(time.time() - t1, 2))
>
> 0.41
>
> # access each element of the array:
> t1 = time.time()
> for j in range(1000):
> for k in range(1000):
> elt = d2[j][k]
> print( round(time.time() - t1, 2))
>
> 0.55
>
> My program was too slow, so I started investigating whether I could improve
> on the two-level dictionary, which got used a lot. To get another baseline I
> tried a pure 1,000,000-element list, expecting the times to be be
> horrendous, but look!
>
> # fill a list using append
> t1 = time.time()
> lst = []
> for n in range(100):
> lst.append(n)
> print( round(time.time() - t1, 2))
>
> 0.26
>
> # access every element of a list
> t1 = time.time()
> for n in range(100):
> elt = lst[n]
> print( round(time.time() - t1, 2))
>
> 0.25
>
> What a shock! I could save half the execution time and all my clever work
> and awkward double-layer dictionary expressions by just using a list!
>
> Even better, look what happens using a comprehension to create the list
> instead of a loop with list.append:
>
> t1 = time.time()
> lst = [n for n in range(100)]
> print( round(time.time() - t1, 2))
>
> 0.11
>
> Half again to create the list.
>
> Iterating over the whole list is easier and faster than iterating over the
> double-level dictionary, in particular because it doesn't involve a
> two-level loop. But what about individual access given a row and a column?
>
> t1 = time.time()
> for j in range(1000):
> for k in range(1000):
> elt = lst[j * 1000 + k]
> print( round(time.time() - t1, 2))
>
> 0.45
>
> This is the same as for the dictionary.
>
> I tried a two-level list and a few other things but still haven't found
> anything that works better than a single long list -- just like 2-D arrays
> are coded in old-style languages, with indices computed as offsets from the
> beginning of the linear sequence of all the values. What's amazing is that
> creating and accessing 1,000,000-element list in Python is so efficient. The
> usual moral obtains: start simple, analyze problems (functional or
> performance) as they arise, decide whether they are worth the cost of
> change, then change in very limited ways. And of course abstract and
> modularize so that, in my case, for example, none of the program's code
> would be affected by the change from a two-level dictionary representation
> to using a single long list.
>
> I realize there are many directions an analysis like this can follow, and
> many factors affecting it, including patterns of use. I just wanted to
> demonstrate the basics for a situation that I just encountered. In
> particular, if the array was sparse, rather than completely full, the
> two-level dictionary implementation would be the natural representation.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Gerald Britton
--
http://mail.python.org/mailman/listinfo/python-list
python admin abuse complaint
This is a short complaint on admin abuse on #python irc channel on
freenode.net.
Here's a log:
2010-02-02
(12:11:57 PM) The topic for #python is: NO LOL | http://pound-python.org/
| It's too early to use Python 3.x | Pasting > 3 lines? Pastebin:
http://paste.pocoo.org/ | Tutorial: http://docs.python.org/tut/ | FAQ:
http://effbot.org/pyfaq/ | New Programmer? Read http://tinyurl.com/thinkcspy
| #python.web #wsgi #python-fr #python.de #python-es #python.tw
#python.pl #python-br #python-jp #python-nl #python-ir #python-
offtopic
(12:12:00 PM) _habnabit: pr100, I replaced it with str.startswith,
actually.
(12:12:01 PM) jarray52: Jarray
(12:12:11 PM) _habnabit: jarray52, yes, you are.
(12:12:16 PM) xahlee: is hash={} and hash.clean() identical?
(12:12:18 PM) eggy_: OhnoesRaptor: getting sockets (and event loops
etc) right is quite tricky
(12:12:21 PM) OhnoesRaptor: I know how to do sockets right eggy, just
wondering whats up with the python verison :D
(12:12:24 PM) mode (+o dash) by ChanServ
(12:12:30 PM) You have been kicked by dash: (No.)
---
I have not been using irc for the past about 2 year. (possibly perhaps
2 times in i think #web channel) In particular, i have not been in in
freenode.net's #python channel. I don't know who is dash.
Xah
∑ http://xahlee.org/
☄
--
http://mail.python.org/mailman/listinfo/python-list
Re: Threading issue with SQLite
Many thanks to all who replied to my questions re. SQLite connections, cursors and threading. Looks like I have got some reading to do regarding connection pooling and a decent SQLite ORM package. Does anyone know of any which are Python 3 compatible? Many thanks, Alanj -- http://mail.python.org/mailman/listinfo/python-list
Your impression of for-novice writings on assertions
I've started on ch 3 of my beginner's intro to programming, now delving into the details of the Python language. It's just a few pages yet, file [03 asd.pdf] (no real title yet!) at http://tinyurl.com/programmingbookP3> which is at Google Docs. The first topic is about assertions and exceptions. I wonder whether this text is easy or difficult to understand for a beginner. Or any improvements that could be made. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: lists as an efficient implementation of large two-dimensional arrays(!)
On 08:36 pm, gerald.brit...@gmail.com wrote: On Tue, Feb 2, 2010 at 3:14 PM, Mitchell L Model wrote: I need a 1000 x 1000 two-dimensional array of objects. (Since they are instances of application classes it appears that the array module is useless; Did you try it with an array object using the array module? Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: converting XML to hash/dict/CustomTreeCtrl
Hi,
Sorry for being vague but here my question about converting an xml into
a dict. I found some examples online but none gives the dict/result I
want. The xml looks like this:
This is the note
on calculation times
609.081574
2531.972081
65.119100
1772.011230
kind="timers">
72.418861
28.285192
0.000
607.432373
483328
483328
4182777856
4182777856
1
1943498
0
1640100156
411307840
709596712
1406752
737720720
0
607.432373
5164184694
2054715622
using this script (taken from http://code.activestate.com/recipes/410469/):
from xml.etree import cElementTree as ElementTree
class XmlListConfig(list):
def __init__(self, aList):
for element in aList:
if element:
# treat like dict
if len(element) == 1 or element[0].tag != element[1].tag:
self.append(XmlDictConfig(element))
# treat like list
elif element[0].tag == element[1].tag:
self.append(XmlListConfig(element))
elif element.text:
text = element.text.strip()
if text:
self.append(text)
class XmlDictConfig(dict):
'''
Example usage:
>>> tree = ElementTree.parse('your_file.xml')
>>> root = tree.getroot()
>>> xmldict = XmlDictConfig(root)
Or, if you want to use an XML string:
>>> root = ElementTree.XML(xml_string)
>>> xmldict = XmlDictConfig(root)
And then use xmldict for what it is... a dict.
'''
def __init__(self, parent_element):
if parent_element.items():
self.update(dict(parent_element.items()))
for element in parent_element:
if element:
# treat like dict - we assume that if the first two tags
# in a series are different, then they are all different.
if len(element) == 1 or element[0].tag != element[1].tag:
aDict = XmlDictConfig(element)
# treat like list - we assume that if the first two tags
# in a series are the same, then the rest are the same.
else:
# here, we put the list in dictionary; the key is the
# tag name the list elements all share in common, and
# the value is the list itself
aDict = {element[0].tag: XmlListConfig(element)}
# if the tag has attributes, add those to the dict
if element.items():
aDict.update(dict(element.items()))
self.update({element.tag: aDict})
# this assumes that if you've got an attribute in a tag,
# you won't be having any text. This may or may not be a
# good idea -- time will tell. It works for the way we are
# currently doing XML configuration files...
elif element.items():
self.update({element.tag: dict(element.items())})
# finally, if there are no child tags and no attributes, extract
# the text
else:
self.update({element.tag: element.text})
tree = ElementTree.parse('test.xml')
root = tree.getroot()
xmldict = XmlDictConfig(root)
print xmldict
Which I get this dict:
{'stats': {'kind': 'position', 'stats': [{'kind': 'section', 'stats':
{'kind': 'timers', 'name': 'timers', 'timer': [{'system': '65.119100',
'user': '2531.972081', 'elapsed': '609.081574', 'name': 'totaltime',
'description': 'Total time'}, {'elapsed': '1772.011230', 'name':
'partialTimer', 'description': 'Gravitational Displacement'},
[{'elapsed': '72.418861', 'name': 'subATimer', 'description': 'Phase
time A'}, {'elapsed': '28.285192', 'name': 'subBTimer', 'description':
'Phase time B'}, {'elapsed': '0.000', 'name': 'spaceMem', 'description':
'Space memory'}], {'elapsed': '607.432373', 'name': 'endTime',
'description': 'End'}]}, 'name': 'time', 'string': {'name':
'timersNote', 'description': 'Note:'}, 'description': 'Timing summary'},
[[{'current': '483328', 'peak': '483328', 'name': 'heapSpace',
'description': 'Total Space'}, {'current': '4182777856', 'peak':
'4182777856', 'name': 'spaceResidentSize', 'description': 'Space
resident size'}, '1', '1943498', '0'], [{'current': '411307840', 'peak':
'1640100156', 'name': 'geoSpace', 'description': 'Geo-Space'},
{'current': '1406752', 'peak': '709596712', 'name': 'gridSpace',
'd
Re: Your impression of for-novice writings on assertions
On Feb 2, 12:54 pm, "Alf P. Steinbach" wrote: > The first topic is about assertions and exceptions. I wonder whether this text > is easy or difficult to understand for a beginner. Or any improvements that > could be made. To my eyes it reads nicely. You may want to try it out on a real beginner to get their feedback. I like your section on assertions. You could add examples of other ways assertions can be used (loop invariants, sanity checks, post- condition contract checks). For example, validate a loop invariant during a selection sort. In the hypot() example, use an assertion for sanity checking by verifying an expected mathematical relationship such as the triangle inequality: assert abs(c) <= abs(a) + abs(b). The pythagorean triple example can use assertions to check post conditions: assert all(isinstance(x, int) for x in (a,b,c)) and a*a +b*b==c*c. Raymond -- http://mail.python.org/mailman/listinfo/python-list
PyQt4 designer custom properties - combo box style
I am creating custom widgets for the PyQt4 Designer. I can create custom properties, but I'm looking for how to create a custom property that has a combo box drop down. I've seen them in the example widgets and tried following them, but they are using pre-defined items to populate their property, so it's not a very clear example of how to get the combo box property to work. Is there any other examples or help for this kind of setup? Thanks, Andrew -- http://mail.python.org/mailman/listinfo/python-list
PyPI source dependencies?
I'm trying to build PyObjC from source (because the binary doesn't work on OSX 10.5) and I can't figure out how to get all the dependencies downloaded automatically. Am I missing something? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: python admin abuse complaint
On Feb 2, 12:40 pm, Xah Lee wrote:
>
> (12:12:16 PM) xahlee: is hash={} and hash.clean() identical?
>
I think you mean hash.clear() instead of hash.clean()
The answer is that "hash = {}" will create a new dict and assign it to
"hash", while "hash.clear()" simply guts the dict that "hash" is
pointing to.
In the end, both will result in "has" pointing to an empty dict.
However, if you had something else pointing to what "hash" was
pointing to, they will no longer be pointing to the same, empty hash
after "hash = {}" is run.
>>> a = b = {1:2}
>>> a
{1: 2}
>>> b
{1: 2}
>>> a.clear()
>>> a
{}
>>> b
{}
>>> a = b = {1:2}
>>> a = {}
>>> a
{}
>>> b
{1: 2}
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
Op 2010-02-02 18:02, Nobody schreef: > On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote: > It turns out that buggy.py imports psycopg2, as you can see, and apparently psycopg2 (or something imported by psycopg2) tries to import some standard Python module called numbers; instead it ends up importing the innocent myscript/numbers.py, resulting in *absolute mayhem*. >>> >>> I feel your pain, but this is not a Python problem, per-se. >> >> I think it is. > > I agree. > >> There should be different syntax to import from >> "standard" places and from "current directory". Similar to the >> difference between "foo.h" and in cpp. > > I don't know if that's necessary. Only supporting the "foo.h" case would > work fine if Python behaved like gcc, i.e. if the "current directory" > referred to the directory contain the file performing the import rather > than in the process' CWD. That is what I would have expected, it is the way I would have implemented it, and I don't understand why anyone would think differently. Yet not everyone seems to agree. Apparently, contrary to my expectations, Python looks in the directory containing the currently running script instead. That means that the behavior of "import foo" depends very much on circumstances not under control of the module in which that statement appears. Very fragile. Suggestions to use better names or just poor workarounds, IMO. Of the same nature are suggestions to limit the amount of scrips/modules in a directory... my /usr/bin contains no less than 2685 binaries, with 0 problems of name clashes; there is IMO no reason why Python should restrict itself to any less. Generally I like the design decisions used in Python, or at least I understand the reasons; in this case though, I don't see the advantages of the current approach. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 1, 6:34 pm, kj wrote: > > An innocuous little script, let's call it buggy.py, only 10 lines > long, and whose output should have been, at most two lines, was > quickly dumping tens of megabytes of non-printable characters to > my screen (aka gobbledygook), and in the process was messing up my > terminal *royally*. > In linux terminals, try running the command "reset" to clear up any gobbledy-gook. It also works if you happen to hit CTRL-C while entering a password, in the rare case that it fails to set the text back to visible mode. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 2:21 am, waku wrote: > > for writing new code, it's not necessarily that helpful to be *forced* > to keep with strict indenting rules. in early development phases, > code is often experimental, and parts of it may need to be blocked or > unblocked as the codebase grows, and for experimentation, the need to > carefully and consistently indent and de-indent large chunks of code > can easily lead to a mess (blame it on the programmer, not the > language, but still). yes, there are editors that help you indent > chunks of code, but see below. > > there are languages where indentation can be either enforced and allow > one to omit some syntactic nuissance like braces or begin-end clauses, > or made optional, requiring other syntactic means for delimiting > blocks etc. (consider f# with its #light declaration, for example.) > If you're writing "experimental code", you're doing it wrong. Every line of code you write may end up on the space shuttle one day (so to speak!) Why not write the code well-formatted in the first place, so that any bugs you introduce are as easily visible as possible? The only reason why you may want to write crap code without proper formatting is because your text editor is stupid. If that's the case, get rid of your text editor and find some tools that help you do the right thing the first time. > > as long as you are limited to your own code, sure. but if many work > on the same bit, and use different editors and indentation policies, > blanks-tabs indentation issues are not unlikely. you can have blanks > converted to tabs and vice versa automatically, but that's clearly a > nuisance. > If you're text editor has a problem with indenting, you have a terrible text editor. Period, end of sentence. You can't screw in bolts with a hammer, and you can't level with a saw. Don't try to write code in any language without a real text editor that can do proper indentation. Don't let your teammates use deficient text editors either. I wouldn't appreciate it if I delivered precision components that my teammates tried to install with sledgehammers. This is the 21st Century. Good text editors are not hard to find on any platform. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:21 pm, Nobody wrote: > > You don't need to know the entire language before you can use any of it > (if you did, Python would be deader than a certain parrot; Python's dark > corners are *really* dark). > I'm curious. What dark corners are you referring to? I can't think of any. Especially with the direction Python 3 is going, it seems like even the slightly dim corners are being rounded away. I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, __getattribute__, __new__ and __get__. These are the darkest corners I know of, and these are not at all dark. It takes a few paragraphs of documentation to explain all the details of each these features. I hold the entire Python language in my head, and I can still remember when my next meeting is. Compare that to something like Haskell, where you have to read entire books before you truly understand what monads are actually doing behind the scenes, and how Haskell actually interprets and runs your program, or to understand what the esoteric error messages that crop up are actually caused be. Yes, there are people that know how to do stuff in Haskell. These are really smart people, the cream of the crop, so to speak. But that doesn't make Haskell a simple language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:36 pm, John Bokma wrote:
> Jonathan Gardner writes:
> > One of the bad things with languages like perl
>
> FYI: the language is called Perl, the program that executes a Perl
> program is called perl.
>
> > without parentheses is that getting a function ref is not obvious. You
> > need even more syntax to do so. In perl:
>
> > foo(); # Call 'foo' with no args.
> > $bar = foo; # Call 'foo; with no args, assign to '$bar'
> > $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar'
> > # By the way, this '&' is not the bitwise-and '&'
>
> It should be $bar = \&foo
> Your example actually calls foo...
>
I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.
> > One is simple, consistent, and easy to explain. The other one requires
> > the introduction of advanced syntax and an entirely new syntax to make
> > function calls with references.
>
> The syntax follows that of referencing and dereferencing:
>
> $bar = \...@array; # bar contains now a reference to array
> $bar->[ 0 ]; # first element of array referenced by bar
> $bar = \%hash; # bar contains now a reference to a hash
> $bar->{ key }; # value associated with key of hash ref. by bar
> $bar = \&foo; # bar contains now a reference to a sub
> $bar->( 45 ); # call sub ref. by bar with 45 as an argument
>
> Consistent: yes. New syntax? No.
>
Except for the following symbols and combinations, which are entirely
new and different from the $...@% that you have to know just to use
arrays and hashes.
\@, ->[ ]
\%, ->{ }
\&, ->( )
By the way:
* How do you do a hashslice on a hashref?
* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?
Compare with Python's syntax.
# The only way to assign
a = b
# The only way to call a function
b(...)
# The only way to access a hash or array or string or tuple
b[...]
> Also, it helps to think of
>
> $ as a thing
> @ as thingies indexed by numbers
> % as thingies indexed by keys
>
I'd rather think of the task at hand than what each of the funky
symbols on my keyboard mean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 7:23 am, "bartc" wrote: > Jonathan Gardner wrote: > > One of the bad things with languages like perl and Ruby that call > > without parentheses is that getting a function ref is not obvious. You > > need even more syntax to do so. In perl: > > > foo(); # Call 'foo' with no args. > > $bar = foo; # Call 'foo; with no args, assign to '$bar' > > $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar' > > # By the way, this '&' is not the bitwise-and '&' > > $bar->() # Call whatever '$bar' is pointing at with no args > > > Compare with python: > > > foo() # Call 'foo' with no args. > > bar = foo() # 'bar' is now pointing to whatever 'foo()' returned > > bar = foo # 'bar' is now pointing to the same thing 'foo' points to > > bar() # Call 'bar' with no args > > > One is simple, consistent, and easy to explain. The other one requires > > the introduction of advanced syntax and an entirely new syntax to make > > function calls with references. > > If you get rid of the syntax specific to Perl, then having to explicitly > obtain a function reference, or to dereference the result, is not such a big > deal: > > foo # Call 'foo' with no args. > bar = foo # Call 'foo; with no args, assign to 'bar' > bar = &foo # Don't call 'foo', but assign a pointer to it to 'bar' > bar^ # Call whatever 'bar' is pointing at with no args > > (Here I use ^ instead of -> to dereference.) Compared with Python, it saves > 3 lots of (), but needs & and ^ added. Still a net saving. > On one shoulder, a demon taunts the programmer: "Ohmygosh, you can save three keystrokes if you introduce an entirely new syntax with odd squiggles that make no pronounceable sound in the English language! Perhaps one day, you can program APL in Python!" The angel that sits on the other shoulder says, "Alas, poor programmer, one day, you'll have to read that and understand it. And heaven help us when we hire a poor college graduate to maintain the code we wrote five years ago. Or worse, when that poor college graduate writes code and expects us to read it!" Thankfully, Guido has banished that demon from the realm of Python a long time ago. > > One of the bad things with languages like perl and Ruby that call > > without parentheses is that getting a function ref is not obvious. > > I'd say that having this "&" symbol in front of "foo" makes it more obvious > than just foo by itself. But I agree not quite as clean. > > Another thing is that you have to know whether "bar" is a function, or a > function ref, and use the appropriate syntax. Sometimes this is helpful, > sometimes not. > Thankfully, in Python, everything is a ref, so everything is consistent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:50 pm, Nobody wrote:
> On Mon, 01 Feb 2010 14:13:38 -0800, Jonathan Gardner wrote:
> > I judge a language's simplicity by how long it takes to explain the
> > complete language. That is, what minimal set of documentation do you
> > need to describe all of the language?
>
> That's not a particularly good metric, IMHO.
>
> A simple "core" language doesn't necessarily make a language simple to
> use. You can explain the entirety of pure lambda calculus or combinators
> in five minutes, but you wouldn't want to write real code in either (and
> you certainly wouldn't want to read such code which was written by someone
> else).
>
> For a start, languages with a particularly simple "core" tend to delegate
> too much to the library. One thing which puts a lot of people off of
> lisp is the lack of infix operators; after all, (* 2 (+ 3 4)) works fine
> and doesn't require any additional language syntax. For an alternative,
> Tcl provides the "expr" function which essentially provides a sub-language
> for arithmetic expressions.
>
> A better metric is whether using N features has O(N) complexity, or O(N^2)
> (where you have to understand how each feature relates to each other
> feature) or even O(2^N) (where you have to understand every possible
> combination of interactions).
>
> > With a handful of statements,
> > and a very short list of operators, Python beats out every language in
> > the Algol family that I know of.
>
> Not once you move beyond the 10-minute introduction, and have to start
> thinking in terms of x + y is x.__add__(y) or maybe y.__radd__(x) and also
> that x.__add__(y) is x.__getattribute__('__add__')(y) (but x + y *isn't*
> equivalent to the latter due to __slots__), and maybe .__coerce__() gets
> involved somewhere, and don't even get me started on __metaclass__ or
> __init__ versus __new__ or ...
>
> Yes, the original concept was very nice and clean, but everything since
> then has been wedged in there by sheer force with a bloody great hammer.
I strongly suggest you read the documentation on these bits of Python.
If you're scared of __new__ versus __init__, then you haven't been
programming very long in any language. There is a case when you need
one over the other. The same goes for the other concepts.
Programming languages that don't provide these features (like
Javascript) are nice for toy programs, but lack the power to
accommodate the needs of large apps.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python admin abuse complaint
Xah Lee wrote:
> This is a short complaint on admin abuse on #python irc channel on
> freenode.net.
>
> Here's a log:
>
> 2010-02-02
>
> (12:11:57 PM) The topic for #python is: NO LOL | http://pound-python.org/
> | It's too early to use Python 3.x | Pasting > 3 lines? Pastebin:
> http://paste.pocoo.org/ | Tutorial: http://docs.python.org/tut/ | FAQ:
> http://effbot.org/pyfaq/ | New Programmer? Read http://tinyurl.com/thinkcspy
> | #python.web #wsgi #python-fr #python.de #python-es #python.tw
> #python.pl #python-br #python-jp #python-nl #python-ir #python-
> offtopic
> (12:12:00 PM) _habnabit: pr100, I replaced it with str.startswith,
> actually.
> (12:12:01 PM) jarray52: Jarray
> (12:12:11 PM) _habnabit: jarray52, yes, you are.
> (12:12:16 PM) xahlee: is hash={} and hash.clean() identical?
> (12:12:18 PM) eggy_: OhnoesRaptor: getting sockets (and event loops
> etc) right is quite tricky
> (12:12:21 PM) OhnoesRaptor: I know how to do sockets right eggy, just
> wondering whats up with the python verison :D
> (12:12:24 PM) mode (+o dash) by ChanServ
> (12:12:30 PM) You have been kicked by dash: (No.)
>
> ---
>
> I have not been using irc for the past about 2 year. (possibly perhaps
> 2 times in i think #web channel) In particular, i have not been in in
> freenode.net's #python channel. I don't know who is dash.
>
> Xah
> ∑ http://xahlee.org/
>
> ☄
Frankly, Xah Lee, I find it ironic that you see fit to complain about
abuse of the IRC channel when you have apparently felt free to ignore
the many complaints about your behavior on this and other newsgroups
over many years.
"As ye sew, so shall ye reap". I imagine that your reputation has
preceded you, and that dash (whom I *do* know) is simply looking to keep
a well-known nuisance from bothering the rest of the users on the channel.
For the present my sympathies are all with him. The PSF will, however,
investigate this issue and I will report back to you off-list in due course.
regards
Steve
--
Steve HoldenChairman, Python Software Foundation
The Python Community Conference http://python.org/psf/
PyCon 2010 Atlanta Feb 19-21http://us.pycon.org/
Watch PyCon on video now! http://pycon.blip.tv/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner writes: > Compare with Python's syntax. > > # The only way to assign > a = b > > # The only way to call a function > b(...) > > # The only way to access a hash or array or string or tuple > b[...] For all of your examples, there are other ways supported. I do wish this focus on “only way” would depart, it's a fallacy and not helpful. What is important (and supports the main point of your message) is that for each of the above, whether or not they are the only way, they are the one *obvious* way to do the operation. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, Feb 2, 2010 at 1:38 PM, Roel Schroeven < rschroev_nospam...@fastmail.fm> wrote: > Apparently, contrary to my expectations, Python looks in the directory > containing the currently running script instead. That means that the > behavior of "import foo" depends very much on circumstances not under > control of the module in which that statement appears. Very fragile. > Suggestions to use better names or just poor workarounds, IMO. Of the > same nature are suggestions to limit the amount of scrips/modules in a > directory... my /usr/bin contains no less than 2685 binaries, with 0 > problems of name clashes; there is IMO no reason why Python should > restrict itself to any less. > > Generally I like the design decisions used in Python, or at least I > understand the reasons; in this case though, I don't see the advantages > of the current approach. This really isn't anything new, novel, or even interesting. Its been known forever that Python searches the script's directory for other scripts, there's reasons for this. Its also been known forever that its not really an ideal situation, and so over the last seven or so years, Python's been working on fixing it. http://www.python.org/dev/peps/pep-0328/ In 2.5, you could activate your modules to use absolute imports by default, thus requiring you to use special syntax to access modules in your own path. In 2.6, relative imports of modules in the same dir (thus, possible shadowing modules) raises a deprecation warning. In Python 3+, you have to use the explicit syntax to get at modules in the current directory. This has taken years to address, yeah, because touching the import machinery is -dangerous-; you have to do it very carefully to be sure that vast amounts of code doesn't break that's relying on the existing, not-entirely-well-documented-or-defined mechanics. Why was Python designed like this? Ask Guido. I don't know, but I'm not surprised: python was always very /flat/ originally. Strict, flat scopes, didn't even have packages, etc. Its slowly gotten a little more nested / deeper over time-- from limited nested scoping (only for enclosing functions), to now absolute imports being default. Its a slow process seeking a delicate balance; "flat is better then nested" vs "namespaces are one honking great idea" are somewhat contradictory, after all :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On 2/2/2010 2:43 PM, kj wrote: In Terry Reedy writes: On 2/2/2010 9:13 AM, kj wrote: As for fixing it, unfortunately it's not quite so simple to fix without breaking backwards-compatibility. The opportunity to do so for Python 3.0 was missed. This last point is to me the most befuddling of all. Does anyone know why this opportunity was missed for 3.0? Anyone out there with the inside scoop on this? Was the fixing of this problem discussed in some PEP or some mailing list thread? (I've tried Googling this but did not hit on the right keywords to bring up the deliberations I'm looking for.) There was a proposal to put the whole stdlib into a gigantic package, so that import itertools would become, for instance import std.itertools. Guido rejected that. I believe he both did not like it and was concerned about making upgrade to 3.x even harder. The discussion was probably on the now closed py3k list. Thanks. I'll look for this thread. Stephen Hansen's post explains a bit more than I did. To supplement his explanation: since print *was* a keyword, every use of 'print' in 2.x denotes a print statement with standard semantics. Therefore 2to3 *knows* what the statement means and can translate it. On the other hand, 'import string' usually means 'import the string module of the stdlib', but it could mean 'import my string module'. This depends on the execution environment. Moreover, I believe people have intentionally shadowed stdlib modules. So. like it or not, 2to3 cannot know what 'import string' means. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Overcoming python performance penalty for multicore CPU
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
if the GIL just limited Python to running on one CPU at a time,
but it's worse than that; there's excessive overhead due to
a lame locking implementation. Running CPU-bound multithreaded
code on a dual-core CPU runs HALF AS FAST as on a single-core
CPU, according to Beasley.
My main server application, which runs "sitetruth.com"
has both multiple processes and multiple threads in each process.
The system rates web sites, which involves reading and parsing
up to 20 pages from each domain. Analysis of each domain is
performed in a separate process, but each process uses multiple
threads to read process several web pages simultaneously.
Some of the threads go compute-bound for a second or two at a time as
they parse web pages. Sometimes two threads (but never more than three)
in the same process may be parsing web pages at the same time, so
they're contending for CPU time.
So this is nearly the worst case for the lame GIL lock logic.
Has anyone tried using "affinity" ("http://pypi.python.org/pypi/affinity";)
to lock each Python process to a single CPU? Does that help?
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
Calling a "raw" python function from C++
Hello. I've been crawling the web for an answer to this one, but have come up empty. We can currently only use Boost 1.36 for our project, i.e. we are having problems using later versions of Boost. We are using Boost.Python to interface with Cheetah. Problem: In Boost 1.36, how do you call a "raw" method of a python class from C++? In particular, what C++ code is needed to call a "raw constructor", i.e. a constructor that can take an arbitrary number of positional and keyword arguments by using *args, **kwargs? For instance, this is defined in a ".py" file. class Gain: def __init__( self, *args, **kwargs ): ... In C++ we have (where "gainClass" is the Gain class above referenced from C++): - namespace bp = boost::python; bp::object gainObject = gainClass( /* what goes here to call the above Gain constructor? */ ); - Passing a tuple and a dict doesn't work. I wish we could use the most recent version of Boost, since in this you can just do this: - bp::object gainObject = gainClass( *bp::tuple(), **bp::dict() ); - But this is not available in Boost 1.36 TIA -- Harmon -- http://mail.python.org/mailman/listinfo/python-list
Re: lists as an efficient implementation of large two-dimensional arrays(!)
On 2/2/2010 3:14 PM, Mitchell L Model wrote: I need a 1000 x 1000 two-dimensional array of objects. I would just use 1000 element list, with each element being a 1000 element list or array (if possible). Then l2d[i][j] works fine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Ben Finney wrote: > Jonathan Gardner writes: > >> Compare with Python's syntax. >> >> # The only way to assign >> a = b >> >> # The only way to call a function >> b(...) >> >> # The only way to access a hash or array or string or tuple >> b[...] > > For all of your examples, there are other ways supported. I do wish this > focus on “only way” would depart, it's a fallacy and not helpful. > And besides which most people get the quote wrong. The "authoritative" version from the Zen is, as you clearly already know There should be one-- and preferably only one --obvious way to do it. > What is important (and supports the main point of your message) is that > for each of the above, whether or not they are the only way, they are > the one *obvious* way to do the operation. > Quite. People might be interested to know the history of the Zen, which I got directly from Tim Peters over lunch one day. It was composed, apparently, during the commercial breaks one evening while he was watching professional wrestling on the television! So it's wise not to take the Zen too seriously. It wasn't written to guide, but to amuse. The fact that it can do both is a testament to Tim's sagacity. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
In article , D'Arcy J.M. Cain wrote: > >If you have a problem and you think that regular expressions are the >solution then now you have two problems. Regex is really overkill for >the OP's problem and it certainly doesn't improve readability. If you're going to use a quote, it works better if you use the exact quote and attribute it: 'Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.' --Jamie Zawinski -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 5:01 pm, Jonathan Gardner
wrote:
> On Feb 1, 6:36 pm, John Bokma wrote:
>
>
>
>
>
> > Jonathan Gardner writes:
> > > One of the bad things with languages like perl
>
> > FYI: the language is called Perl, the program that executes a Perl
> > program is called perl.
>
> > > without parentheses is that getting a function ref is not obvious. You
> > > need even more syntax to do so. In perl:
>
> > > foo(); # Call 'foo' with no args.
> > > $bar = foo; # Call 'foo; with no args, assign to '$bar'
> > > $bar = &foo; # Don't call 'foo', but assign a pointer to it to '$bar'
> > > # By the way, this '&' is not the bitwise-and '&'
>
> > It should be $bar = \&foo
> > Your example actually calls foo...
>
> I rest my case. I've been programming perl professionally since 2000,
> and I still make stupid, newbie mistakes like that.
>
> > > One is simple, consistent, and easy to explain. The other one requires
> > > the introduction of advanced syntax and an entirely new syntax to make
> > > function calls with references.
>
> > The syntax follows that of referencing and dereferencing:
>
> > $bar = \...@array; # bar contains now a reference to array
> > $bar->[ 0 ]; # first element of array referenced by bar
> > $bar = \%hash; # bar contains now a reference to a hash
> > $bar->{ key }; # value associated with key of hash ref. by bar
> > $bar = \&foo; # bar contains now a reference to a sub
> > $bar->( 45 ); # call sub ref. by bar with 45 as an argument
>
> > Consistent: yes. New syntax? No.
>
> Except for the following symbols and combinations, which are entirely
> new and different from the $...@% that you have to know just to use
> arrays and hashes.
>
> \@, ->[ ]
> \%, ->{ }
> \&, ->( )
>
> By the way:
> * How do you do a hashslice on a hashref?
> * How do you invoke reference to a hash that contains a reference to
> an array that contains a reference to a function?
>
> Compare with Python's syntax.
>
> # The only way to assign
> a = b
>>> locals().__setitem__('a', 'b')
>>> print a
b
> # The only way to call a function
> b(...)
>>> def b(a):
...print a*2
>>> apply(b, (3,))
6
> # The only way to access a hash or array or string or tuple
> b[...]
>>> b={}
>>> b[1] = 'a'
>>> print b.__getitem__(1)
a
--
http://mail.python.org/mailman/listinfo/python-list
Re: Overcoming python performance penalty for multicore CPU
On 11:02 pm, na...@animats.com wrote:
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course. It would be adequate
if the GIL just limited Python to running on one CPU at a time,
but it's worse than that; there's excessive overhead due to
a lame locking implementation. Running CPU-bound multithreaded
code on a dual-core CPU runs HALF AS FAST as on a single-core
CPU, according to Beasley.
It's not clear that Beasley's performance numbers apply to any platform
except OS X, which has a particularly poor implementation of the
threading primitives CPython uses to implement the GIL.
You should check to see if it actually applies to your deployment
environment.
The GIL has been re-implemented recently. Python 3.2, I think, will
include the new implementation, which should bring OS X performance up
to the level of other platforms. It may also improve certain other
aspects of thread switching.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problems embedding python 2.6 in C++
En Tue, 02 Feb 2010 02:26:57 -0300, Paul escribió: I've managed to get it working and so far stable... Glad to see you finally made it work! Current working version: [...] mycppclass::callpy(funcname, args...) m_mypymodule = PyImport_Import(pModuleName) pyargs = PyTuple_SetItem * args PyCallable_Check(func) PyObject_CallObject(func,pyargs) Py_XDECREF(m_mypymodule) So now the module is being imported each function call (luckily I don't have to worry about performance) Remember that after the module is successfully imported by the first time, a subsequent import returns early, as soon as it finds the module in sys.modules[] -- the performance penalty shouldn't be so big. I assume this means that the internal representation of the imported module is being corrupted by something. I found another person with a similar issue here: http://mail.python.org/pipermail/python-dev/2004-March/043306.html - that is a long time ago but another multi-threaded app. I'm happy to use the working method but I'd like to understand what is going on a bit more. Can anyone shed any further light? Sorry, I cannot help on this. Seems to happen only with an embedded interpreter and a multithreaded application, and I've never used Python in that scenario. If you could trim your code to a minimal example that shows the faulty behavior, that would be great, so others can test it too and eventually determine what's going on. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Your impression of for-novice writings on assertions
On 2-2-2010 21:54, Alf P. Steinbach wrote: I've started on ch 3 of my beginner's intro to programming, now delving into the details of the Python language. Alf, I think it's a good read so far. I just don't like the smilies that occur in the text. It's a book (or article) that I'm reading, not an instant messaging conversation. Irmen -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner wrote: On Feb 2, 7:23 am, "bartc" wrote: Jonathan Gardner wrote: One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. ... If you get rid of the syntax specific to Perl, then having to explicitly obtain a function reference, or to dereference the result, is not such a big deal: foo # Call 'foo' with no args. bar = foo # Call 'foo; with no args, assign to 'bar' bar = &foo # Don't call 'foo', but assign a pointer to it to 'bar' bar^ # Call whatever 'bar' is pointing at with no args (Here I use ^ instead of -> to dereference.) Compared with Python, it saves 3 lots of (), but needs & and ^ added. Still a net saving. On one shoulder, a demon taunts the programmer: "Ohmygosh, you can save three keystrokes if you introduce an entirely new syntax with odd squiggles that make no pronounceable sound in the English language! Perhaps one day, you can program APL in Python!" ... Thankfully, Guido has banished that demon from the realm of Python a long time ago. You mean & (bitwise AND in Python) and ^ (bitwise XOR in Python)? :-) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Your impression of for-novice writings on assertions
Alf P. Steinbach wrote: > I've started on ch 3 of my beginner's intro to programming, now delving > into the details of the Python language. > > It's just a few pages yet, file [03 asd.pdf] (no real title yet!) at > http://tinyurl.com/programmingbookP3> which is at Google Docs. > > The first topic is about assertions and exceptions. I wonder whether > this text is easy or difficult to understand for a beginner. Or any > improvements that could be made. > I don't think it's helpful in Python to refer to "... variables, which are named locations in memory, ..." because Python specifically eschews this model, and trying to explain assignment (especially of mutable objects) in those terms will lead to conceptual difficulties. Also, why introduce exceptions by talking about "error handling" when the term "exception handling" is hanging in the air? This is also a conceptual thing, since you want to get the reader used to the idea that it's a legitimate programming technique to use exceptions as part of their programs' normal control flow. I'd also recommend taking docstrings a little more seriously, since their use makes code much more self-documenting - someone can import your module and learn its API using the help() function. You may have done that in an earlier chapter. Just a few points for you to think about, and reject if you choose. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Your impression of for-novice writings on assertions
On Feb 3, 7:54 am, "Alf P. Steinbach" wrote: > I've started on ch 3 of my beginner's intro to programming, now delving into > the > details of the Python language. > > It's just a few pages yet, file [03 asd.pdf] (no real title yet!) at > http://tinyurl.com/programmingbookP3> which is at Google Docs. > > The first topic is about assertions and exceptions. I wonder whether this text > is easy or difficult to understand for a beginner. Or any improvements that > could be made. > > Cheers, > > - Alf The only issue I have with what is there is the example - most programmers are not interested in solving mathematical equations and the code is enough to make the reader go cross-eyed. IMO the example code tends to detract from the point you are trying to make about using and how to use assertions. I would suggest a much simpler (to read) example than the one given. Ideally I would like to see more than one example with the examples graded from simple to more complex. A simple example could be just using the assert statement to verify pre-condition (assumptions) made on parameters to a function i.e. def divide (x, y): return x / y The programmer obviously assumed that y will never be 0 - so with one simple example you teach two points: 1. how an assert can be used 2. when programming look for unconscious assumptions Peter P.S. You also raise an interesting issue in my mind when quoting Knuth and siting TeX as an example application with no known bugs - Knuth advocated and used literate programming when writing TeX to achieve "clarity". I believe he (still?) cites the fact that TeX is so bug free because he used Literate Programming to write it (well, at least one reason). So should we be trying to teach literate programming to beginners? You did open that can of worms by quoting and siting Knuth and TeX... :-) -- http://mail.python.org/mailman/listinfo/python-list
Python's Reference And Internal Model Of Computing Languages
just wrote this essay. Comment & feedback very welcome.
Python's Reference And Internal Model Of Computing Languages
Xah Lee, 2010-02-02
In Python, there are 2 ways to clear a hash: âmyHash = {}â and
âmyHash.clear()â. What is the difference?
â
The difference is that âmyHash={}â simply creates a new empty hash and
assigns to myHash, while âmyHash.clear()â actually clear the hash the
myHash is pointing to.
What does that mean?? Here's a code that illustrates:
# python
# 2 ways to clear hash and their difference
aa = {'a':3, 'b':4}
bb = aa
aa = {}
print bb # prints {'a': 3, 'b': 4}
aa = {'a':3, 'b':4}
bb = aa
aa.clear()
print bb # prints {}
This is like this because of the âreferenceâ concept. The opposite
alternative, is that everything is a copy, for example in most
functional langs. (with respect to programer-visible behavior, not how
it is implemented)
From the aspect of the relation of the language source code to the
program behavior by the source code, this âreferenceâ-induced behavior
is similar to dynamic scope vs lexicol scope. The former being un-
intuitive and hard to understand the latter more intuitive and clear.
The former requires the lang to have a internal model of the language,
the latter more correspond to source code WYSIWYG. The former being
easy to implement and is in early langs, the latter being more popular
today.
As with many languages that have concept of references, or pointers,
this is a complexity that hampers programing progress. The concept of
using some sort of âreferenceâ as part of the language is due to
implementation efficiency. Starting with C and others in 1960s up to
1990s. But as time went on, this concept in computer languages are
gradually disappearing, as they should.
Other langs that have this âreferenceâ concept as ESSENTIAL part of
the semantic of the language, includes: C, C++, Java, Perl, Common
Lisp. (of course, each using different terminologies, and each lang
faction will gouge the other faction's eyes out about what is the true
meaning of terms like âreferenceâ, âobjectâ, âlist/sequence/vector/
array/hashâ, and absolutely pretend other meanings do not exist.
(partly due to, their ignorance of langs other than their own, partly,
due to male power struggle nature.))
Languages that do not have any âreferenceâ or âobjectâ, or otherwise
does not require the programer to have some internal model of source
code, are: Mathematica, JavaScript, PHP. (others may include TCL,
possibly assembly langs.)
For some detail on this, see: Jargons And High Level Languages and
Hardware Modeled Computer Languages.
---
(perm url of this essay can be found on my website.)
Xah
â http://xahlee.org/
â
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3147 - new .pyc format
On Tue, 02 Feb 2010 09:38:07 +0100, Daniel Fetchinson wrote: >> I like seeing them in the same place as the source file, because when I >> start developing a module, I often end up renaming it multiple times >> before it settles on a final name. When I rename or move it, I delete >> the .pyc file, and that ensures that if I miss changing an import, and >> try to import the old name, it will fail. >> >> By hiding the .pyc file elsewhere, it is easy to miss deleting one, and >> then the import won't fail, it will succeed, but use the old, obsolete >> byte code. > > > Okay, I see your point but I think your argument about importing shows > that python is doing something suboptimal because I have to worry about > .pyc files. Ideally, I only would need to worry about python source > files. That's no different from any language that is compiled: you have to worry about keeping the compiled code (byte code or machine language) in sync with the source code. Python does most of that for you: it automatically recompiles the source whenever the source code's last modified date stamp is newer than that of the byte code. So to a first approximation you can forget all about the .pyc files and just care about the source. But that's only a first approximation. You might care about the .pyc files if: (1) you want to distribute your application in a non-human readable format; (2) if you care about clutter in your file system; (3) if you suspect a bug in the compiler; (4) if you are working with byte-code hacks; (5) if the clock on your PC is wonky; (6) if you leave random .pyc files floating around earlier in the PYTHONPATH than your source files; etc. > There is now a chance to 'fix' (quotation marks because maybe > there is nothing to fix, according to some) this issue and make all pyc > files go away and having python magically doing the right thing. Famous last words... The only ways I can see to have Python magically do the right thing in all cases would be: (1) Forget about byte-code compiling, and just treat Python as a purely interpreted language. If you think Python is slow now... (2) Compile as we do now, but only keep the byte code in memory. This would avoid all worries about scattered .pyc files, but would slow Python down significantly *and* reduce functionality (e.g. losing the ability to distribute non-source files). Neither of these are seriously an option. > A > central pyc repository would be something I was thinking about, but I > admit it's a half baked or not even that, probably quarter baked idea. A central .pyc repository doesn't eliminate the issues developers may have with byte code files, it just puts them somewhere else, out of sight, where they are more likely to bite. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: > I did not propose obvious module names. I said obvious names like > email.py are bad; more descriptive names like send_email.py are better. But surely send_email.py doesn't just send email, it parses email and receives email as well? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to catch this exception
En Tue, 02 Feb 2010 08:20:34 -0300, mk escribió: Exception in thread Thread-9 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/var/www/html/cssh.py", line 617, in ssh_connect : 'NoneType' object has no attribute 'BadAuthenticationType' So you started several threads, and one of them was in them middle of connecting to somewhere when the program exited, correct? This happens on interpreter shutdown, even though I do try to catch the AttributeError exception: try: fake = paramiko.BadAuthenticationType try: self.conobj.connect(self.ip, username=self.username, key_filename=self.sshprivkey, port=self.port, timeout=opts.timeout) loginsuccess = True except paramiko.BadAuthenticationType, e: # this is line 617 self.conerror = str(e) except paramiko.SSHException, e: self.conerror = str(e) except socket.timeout, e: self.conerror = str(e) except socket.error, e: self.conerror = str(e) except AttributeError: # this happens on interpreter shutdown self.conerror = 'shutdown' It's clear what happens: paramiko gets its attributes cleared or the module perhaps gets unloaded and as result "paramiko" label leads to None, which obviously has no attribute BadAuthenticationType. As part of the interpreter shutdown procedure, module globals are set to None. Code that might be executed in those very precarious circumstances should NOT reference any globals. However, even though this is surrounded by try .. except AttributeError block, it evidently isn't catch. How to catch that exception? Or at least preven displaying this message? You could keep a local reference to those global names; by example, by adding 'fake' default arguments: def ssh_connect(self, other, arguments, paramiko=paramiko, socket=socket): ... or perhaps: def ssh_connect(self, other, arguments): BadAuthenticationType = paramiko.BadAuthenticationType socket_timeout = socket.timeout try: ... except BadAuthenticationType, e: ... except socket_timeout, e: ... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Overcoming python performance penalty for multicore CPU
On Feb 3, 9:02 am, John Nagle wrote:
> I know there's a performance penalty for running Python on a
> multicore CPU, but how bad is it? I've read the key paper
> ("www.dabeaz.com/python/GIL.pdf"), of course.
It's a shame that Python 3.x is dead to you, otherwise you'd be able
to enjoy the new GIL implementation in 3.2:
http://www.dabeaz.com/python/NewGIL.pdf
Actually, it looks like you probably still can:
+ patch for 2.5.4: http://thread.gmane.org/gmane.comp.python.devel/109929
+ patch for 2.7? http://bugs.python.org/issue7753
(Can't comment on affinity, though, sorry)
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
(For reasons I don't understand Stephen Hansen's posts don't show in my news server. I became aware of his reply from a passing reference in one of Terry Reedy's post. Then I found Hansen's post online, and then an earlier one, and pasted the relevant portion below.) > First, I don't shadow built in modules. Its really not very hard to avoid. ...*if* you happen to be clairvoyant. I still don't see how the rest of us could have followed this fine principle in the case of numbers.py prior to Python 2.6. > Secondly, I use packages structuring my libraries, and avoid junk > directories of a hundred some odd 'scripts'. (I feel so icky now...) > Third, I don't execute scripts in that directory structure directly, but > instead do python -c 'from package.blah import main; main.main()' or some > such. Usually via some short-cut, or a runner batch file. Breathtaking... I wonder why the Python documentation, in particular the official Python tutorial, is not more forthcoming with these rules. ~K -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
In Terry Reedy writes: >On 2/2/2010 2:43 PM, kj wrote: >> In Terry >> Reedy writes: >> >>> On 2/2/2010 9:13 AM, kj wrote: >> > As for fixing it, unfortunately it's not quite so simple to fix without > breaking backwards-compatibility. The opportunity to do so for Python 3.0 > was missed. This last point is to me the most befuddling of all. Does anyone know why this opportunity was missed for 3.0? Anyone out there with the inside scoop on this? Was the fixing of this problem discussed in some PEP or some mailing list thread? (I've tried Googling this but did not hit on the right keywords to bring up the deliberations I'm looking for.) >> >>> There was a proposal to put the whole stdlib into a gigantic package, so >>> that >> >>> import itertools >> >>> would become, for instance >> >>> import std.itertools. >> >>> Guido rejected that. I believe he both did not like it and was concerned >>> about making upgrade to 3.x even harder. The discussion was probably on >>> the now closed py3k list. >> >> >> Thanks. I'll look for this thread. >Stephen Hansen's post explains a bit more than I did. To supplement his >explanation: since print *was* a keyword, every use of 'print' in 2.x >denotes a print statement with standard semantics. Therefore 2to3 >*knows* what the statement means and can translate it. On the other >hand, 'import string' usually means 'import the string module of the >stdlib', but it could mean 'import my string module'. This depends on >the execution environment. Moreover, I believe people have intentionally >shadowed stdlib modules. So. like it or not, 2to3 cannot know what >'import string' means. Thanks, this dispels some of the mystery. ~K -- http://mail.python.org/mailman/listinfo/python-list
Re: libpcap and python
On 2月1日, 下午8时47分, Mag Gam wrote: > Hello All, > > I used tcpdump to capture data on my network. I would like to analyze > the data using python -- currently using ethereal and wireshark. > > I would like to get certain type of packets (I can get the hex code > for them), what is the best way to do this? Lets say I want to capture > all events of `ping localhost` > > TIA You need python module "pypcap" or "pcapy" to capture the packet, and the you can use Python to analyze it. To decode the internet packet you can use "dpkt". Good Luck! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Reference And Internal Model Of Computing Languages
> On Tue, 2010-02-02 at 17:28 -0800, Xah Lee wrote:
I know, I know, do not feed the trolls. But this is just so *wrong*
that I can't help myself.
> In Python, there are 2 ways to clear a hash:
No, no there's not. There's one way to clear a hash and there's one way
to assign a new object to a variable.
> âmyHash = {}â and
> âmyHash.clear()â. What is the difference?
> The difference is that âmyHash={}â simply creates a new empty hash and
> assigns to myHash, while âmyHash.clear()â actually clear the hash the
> myHash is pointing to.
>
> What does that mean?? Here's a code that illustrates:
>
> # python
> # 2 ways to clear hash and their difference
> aa = {'a':3, 'b':4}
> bb = aa
> aa = {}
> print bb # prints {'a': 3, 'b': 4}
>
> aa = {'a':3, 'b':4}
> bb = aa
> aa.clear()
> print bb # prints {}
>
> This is like this because of the âreferenceâ concept.
...snip inane babble...
> Languages that do not have any âreferenceâ or âobjectâ, or otherwise
> does not require the programer to have some internal model of source
> code, are: Mathematica, JavaScript, PHP. (others may include TCL,
> possibly assembly langs.)
Just so we're all clear exactly how much thought has gone into this
little rant, here's a transcript from a JavaScript session:
var aa = {};
var bb = aa;
aa.hello = "world";
alert(bb.hello) --> "world"
delete bb.hello
alert(aa.hello) --> "undefined"
OMFG, references!!
Come to think of it, the JavaScript and Python object models are really
very similar. I'm genuinely curious now - what little sprinkle of magic
fairy dust has earned JavaScript objects the Xah Lee seal of approval
while Python objects miss out?
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
r...@rfk.id.au| http://www.rfk.id.au/ramblings/gpg/ for details
signature.asc
Description: This is a digitally signed message part
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's Reference And Internal Model Of Computing Languages
Ryan Kelly writes: > I know, I know, do not feed the trolls. But this is just so *wrong* > that I can't help myself. See: http://xkcd.com/386/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Reference And Internal Model Of Computing Languages
()On Feb 2, 6:46Â pm, Ryan Kelly wrote:
> > On Tue, 2010-02-02 at 17:28 -0800, Xah Lee wrote:
>
> I know, I know, do not feed the trolls. Â But this is just so *wrong*
> that I can't help myself.
>
> > In Python, there are 2 ways to clear a hash:
>
> No, no there's not. Â There's one way to clear a hash and there's one way
> to assign a new object to a variable.
>
>
>
>
>
> > Â âmyHash = {}â and
> > âmyHash.clear()â. What is the difference?
> > The difference is that âmyHash={}â simply creates a new empty hash and
> > assigns to myHash, while âmyHash.clear()â actually clear the hash the
> > myHash is pointing to.
>
> > What does that mean?? Here's a code that illustrates:
>
> > # python
> > # 2 ways to clear hash and their difference
> > aa = {'a':3, 'b':4}
> > bb = aa
> > aa = {}
> > print bb # prints {'a': 3, 'b': 4}
>
> > aa = {'a':3, 'b':4}
> > bb = aa
> > aa.clear()
> > print bb # prints {}
>
> > This is like this because of the âreferenceâ concept.
>
> ...snip inane babble...
>
> > Languages that do not have any âreferenceâ or âobjectâ, or otherwise
> > does not require the programer to have some internal model of source
> > code, are: Mathematica, JavaScript, PHP. (others may include TCL,
> > possibly assembly langs.)
>
> Just so we're all clear exactly how much thought has gone into this
> little rant, here's a transcript from a JavaScript session:
>
> Â var aa = {};
> Â var bb = aa;
> Â aa.hello = "world";
> Â alert(bb.hello) Â --> Â "world"
> Â delete bb.hello
> Â alert(aa.hello) Â --> Â "undefined"
>
> OMFG, references!!
>
> Come to think of it, the JavaScript and Python object models are really
> very similar. Â I'm genuinely curious now - what little sprinkle of magic
> fairy dust has earned JavaScript objects the Xah Lee seal of approval
> while Python objects miss out?
Thanks. You are right. I think i put JavaScript there without much
thinking.
Xah
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
kj wrote: > > (For reasons I don't understand Stephen Hansen's posts don't show > in my news server. I became aware of his reply from a passing > reference in one of Terry Reedy's post. Then I found Hansen's post > online, and then an earlier one, and pasted the relevant portion > below.) > > > >> First, I don't shadow built in modules. Its really not very hard to avoid. > > ...*if* you happen to be clairvoyant. I still don't see how the rest of us > could have followed this fine principle in the case of numbers.py > prior to Python 2.6. > Clearly the more you know about the standard library the less likely this is to be a problem. Had you been migrqating from an earlier version the breakage would have alerted you to look for some version-dependent difference. >> Secondly, I use packages structuring my libraries, and avoid junk >> directories of a hundred some odd 'scripts'. > > (I feel so icky now...) > Be as flippant as you like, but that is good advice. >> Third, I don't execute scripts in that directory structure directly, but >> instead do python -c 'from package.blah import main; main.main()' or some >> such. Usually via some short-cut, or a runner batch file. > > Breathtaking... I wonder why the Python documentation, in particular > the official Python tutorial, is not more forthcoming with these > rules. > Because despite the fact that this issue has clearly bitten you badly enough to sour you against the language, such issues are remarkably rare in practice and normally rather easier to debug. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Feb 2, 5:49 pm, Steven D'Aprano wrote: > On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: > > I did not propose obvious module names. I said obvious names like > > email.py are bad; more descriptive names like send_email.py are better. > > But surely send_email.py doesn't just send email, it parses email and > receives email as well? No, it doesn't. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Reference And Internal Model Of Computing Languages
Paul Rubin wrote: Ryan Kelly writes: I know, I know, do not feed the trolls. But this is just so *wrong* that I can't help myself. See: http://xkcd.com/386/ :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: How to guard against bugs like this one?
On Tue, 02 Feb 2010 19:55:15 -0800, Carl Banks wrote: > On Feb 2, 5:49 pm, Steven D'Aprano > wrote: >> On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: >> > I did not propose obvious module names. I said obvious names like >> > email.py are bad; more descriptive names like send_email.py are >> > better. >> >> But surely send_email.py doesn't just send email, it parses email and >> receives email as well? > > No, it doesn't. Nevertheless, as a general principle, modules will tend to be multi- purpose and/or generic. How would you rename the math or random modules to be less "obvious" and more "descriptive"? And of course, the less obvious the name, the harder it becomes for people to find and use it. Which extreme would you rather? import zip import compress_and_decompress_files_to_zip_archives I'm sympathetic to the position you're taking. It's not bad advice at all, but I think you're over-selling it as a complete solution to the problem of name clashes. I think it can only slightly alleviate the problem of name clashes, not eliminate it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner writes: > I can explain, in an hour, every single feature of the Python language > to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner writes:
> On Feb 1, 6:36 pm, John Bokma wrote:
[..]
>> It should be $bar = \&foo
>> Your example actually calls foo...
>
> I rest my case. I've been programming perl professionally since 2000,
> and I still make stupid, newbie mistakes like that.
Uhm, in another post you wrote that you could explain Python in an hour
to an experienced programmer and you *still* make mistakes like that in
Perl!?
By the way, the language is called Perl. If you write "I've been
programming perl" in a Perl related group some people might read it as
that you've been working on the internals of the perl executable (in C)
>> > One is simple, consistent, and easy to explain. The other one requires
>> > the introduction of advanced syntax and an entirely new syntax to make
>> > function calls with references.
>>
>> The syntax follows that of referencing and dereferencing:
>>
>> $bar = \...@array; # bar contains now a reference to array
>> $bar->[ 0 ]; # first element of array referenced by bar
>> $bar = \%hash; # bar contains now a reference to a hash
>> $bar->{ key }; # value associated with key of hash ref. by bar
>> $bar = \&foo; # bar contains now a reference to a sub
>> $bar->( 45 ); # call sub ref. by bar with 45 as an argument
>>
>> Consistent: yes. New syntax? No.
>>
>
> Except for the following symbols and combinations, which are entirely
> new and different from the $...@% that you have to know just to use
> arrays and hashes.
>
> \@, ->[ ]
@array, one item: $array[ 1 ];
$arrayref, one item: $arrayref->[ 1 ];
> \%, ->{ }
%hash, one item: $hash{ key };
hence: $hashref, one item: $hash->{ key }
> \&, ->( )
should now be clear ;-)
You *should* have no problem with that if you have been
programming professionally Perl since 2000 IMNSHO. Otherwise print my
post or copy it on a post-it note ;-).
Remember that all this was added to Perl in version 5. So it had to be
added in a way that wouldn't break Perl 4. Perl is, in my experience
quite good in backwards compatibility. Quite some Perl modules on CPAN
work from 5.00x-5.10 and most likely will work without trouble in 5.12.
> By the way:
> * How do you do a hashslice on a hashref?
I will reply like it's a genuine question, and not like "Oh, look, how
silly Perl works". I don't care about that much. I do like Perl and am
starting to like Python.
@$hashref{ 'key1', 'key2', 'key3' };
> * How do you invoke reference to a hash that contains a reference to
> an array that contains a reference to a function?
I guess you mean:
$hashref->{ key }[ index ]( arguments );
The long version is:
$hashref->{ key }->[ index ]->( arguments );
[ Python advocacy snipped]
> I'd rather think of the task at hand than what each of the funky
> symbols on my keyboard mean.
Then just quit programming Perl ;-) Perl has always come naturally to
me, no idea why. Recently I said to a close friend:
Python is like my desk, which I prefer to keep clean and neat.
Perl is like my livingroom, which I prefer to keep clean and neat to
some extend, but some mess is allowed. For example, the cat can be
there. Toys of my daughter are allowed to be all over the place. A
pleasant mess, but not too much.
I won't repeat what I said about PHP ;-).
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: > Jonathan Gardner writes: > >> I can explain, in an hour, every single feature of the Python language >> to an experienced programmer, all the way up to metaclasses, > > Either you're a hell of a talker, or I am far, far away from being an > experienced programmer. It's advocacy like this, IMO, that keeps people > away from a language, because you can't feel nothing but a failure after > a statement like this. Surely you're exaggerating? Without making any aspersions towards Jonathan either way, the Internet is full of both blowhards and geniuses. Anyone who lets the off-the-cup claims of either ruin their self-confidence is unlikely to be thinking about learning Python, they're probably sitting alone in a dark room staring as the walls close in. Either that or on MySpace. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
RE:calling python from lisp
Autor: Martin Rubey Data: 2008-10-29 09:34 +900 Dla: python-list CC: sage-devel Temat: calling python from lisp http://archives.free.net.ph/message/20081029.003410.172560ac.pl.html >sys:1: RuntimeWarning: Python C API version mismatch for module pol: This >Python has API version 1013, module pol has version 1011. I modified some of pythononlisp including this. http://www2s.biglobe.ne.jp/~niitsuma/pythononlispex.html plz try. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 2, 12:45 am, casevh wrote: > Everyone, > > I'm pleased to annouce the final release of GMPY 1.11. > GMPY is a wrapper for the MPIR or GMP multiple-precision > arithmetic library. GMPY 1.11 is available for download from: > > http://code.google.com/p/gmpy/ > > In addition to support for Python 3.x, there are several new > features in this release: > > - Even faster conversion to/from Python longs. > - Performance improvements by reducing function overhead. > - Performance improvements by improved caching. > - Support for cdivmod, fdivmod, and tdivmod. > - Unicode strings are accepted on Python 2.x and 3.x. > - Fixed regression in GMPY 1.10 where True/False were no > longer recognized. > > Changes since 1.11rc1: > - Recognizes GMP 5. > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > Comments on provided binaries > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > 1.3.1 and will automatically recognize the CPU type and use code > optimized for the CPU at runtime. The 64-bit Windows installers were > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > instructions are included if you want to compile your own binary. > > Please report any issues! My previous replies didn't show up. Something to do the .announce group? I'll trim that and try again. Sorry if they show up eventually. Two issues: 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply >>> gmpy.version() '1.11' Aren't these different versions? How are we supposed to tell them apart? 2] Is it true that the only changes since 1.11rc1 are not applicable to me since - I'm not using Windows - whether it recognizes GMP 5 is moot as GMP 5 cannot be compiled on a Mac (according to GMP site) Is it possible GMP's problems with getting GMP 5 to compile are the same ones I had with 3.1 on Snow Leopard? (They bemoan not having a set of every Mac system.) Think it would behoove me to try it? > > casevh -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano writes: > On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: > >> Jonathan Gardner writes: >> >>> I can explain, in an hour, every single feature of the Python language >>> to an experienced programmer, all the way up to metaclasses, >> >> Either you're a hell of a talker, or I am far, far away from being an >> experienced programmer. It's advocacy like this, IMO, that keeps people >> away from a language, because you can't feel nothing but a failure after >> a statement like this. > > Surely you're exaggerating? No, because if I was I would've put a smiley there somewhere. I am learning Python, for a time to be honest. I can manage in the language quite well. I consider myself quite an experienced Perl programmer, I have no problems with the constructs Jonathan elsewhere in this thread claims to have problems with after 10 years of professional Perl programming. They come natural to me. But I don't see myself being able to understand every Python feature in a talk of an hour *with* the current understanding of Python I have (read halfway through Programming In Python 3, read selected chapters on decorators, etc.). > Without making any aspersions towards Jonathan either way, the Internet > is full of both blowhards and geniuses. Anyone who lets the off-the-cup > claims of either ruin their self-confidence is unlikely to be thinking > about learning Python, they're probably sitting alone in a dark room > staring as the walls close in. I am quite serious about learning Python, I do write professionally in it [1], but I am convinced that I need at least several months more of studying to feel comfortable with most (not even all) of Python. To me a much more relastic view on learning a programming language is: http://norvig.com/21-days.html [1] very small programs, and my customer is fully aware of that I am learning a new language but trust me, which is great. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
John Bokma writes: > Steven D'Aprano writes: > >> On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: >> >>> Jonathan Gardner writes: >>> I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, >>> >>> Either you're a hell of a talker, or I am far, far away from being an >>> experienced programmer. It's advocacy like this, IMO, that keeps people >>> away from a language, because you can't feel nothing but a failure after >>> a statement like this. >> >> Surely you're exaggerating? > > No, because if I was I would've put a smiley there somewhere. I am > learning Python, for a time to be honest. I can manage in the language > quite well. Clarification: for a beginner that is. > [1] very small programs, and my customer is fully aware of that I am > learning a new language but trust me, which is great. Should've been "but trusts me,". -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Overcoming python performance penalty for multicore CPU
On 2/2/2010 9:02 PM, alex23 wrote:
On Feb 3, 9:02 am, John Nagle wrote:
I know there's a performance penalty for running Python on a
multicore CPU, but how bad is it? I've read the key paper
("www.dabeaz.com/python/GIL.pdf"), of course.
It's a shame that Python 3.x is dead to you, otherwise you'd be able
to enjoy the new GIL implementation in 3.2:
http://www.dabeaz.com/python/NewGIL.pdf
Actually, it looks like you probably still can:
+ patch for 2.5.4: http://thread.gmane.org/gmane.comp.python.devel/109929
+ patch for 2.7? http://bugs.python.org/issue7753
The patch was rejected for 2.7 (and earlier) because it could break code
as explained in the discussion. One would have to apply and compile
their own binary.
--
http://mail.python.org/mailman/listinfo/python-list
newbie qns : how do i use xmldiff?
Hi , I am pretty new to python , and reading up on it. Basically I am trying to compare xml files . I know difflib have it but it does not work out as expected. I was looking at xmldiff , unfortunately I am not able to find documentation how to call it from python. Anyone knows a link or doc to it as I have been looking high and low for few days? lastly , is there a py (or algorithm) where it behaves exactly like diff ? Greatly appreciated. Thanks john -- http://mail.python.org/mailman/listinfo/python-list
expy 0.5.2 released
Hi, expy is an expressway to extend python. in release 0.5.2, expy now supports custom exceptions, besides all built-in ones, and exception handling is made easy. for more info, see http://expy.sourceforge.net/ cheers, Yingjie -- http://mail.python.org/mailman/listinfo/python-list
