Cython 0.12.1 released
I'm happy to announce the release of Cython 0.12.1. == About == Cython is a language that makes writing C extensions for the Python language as easy as Python itself. Cython is based on the well-known Pyrex, but supports more cutting edge functionality and optimizations.Cython is an ideal language for wrapping external C libraries, and for fast C modules that speed up the execution of Python code. For more information, see http://cython.org. == Where to get it == http://cython.org http://pypi.python.org/pypi/Cython == New Features == * Type inference improvements. There have been several bug fixes and improvements to the type inferencer. Notably, there is now a safe mode enabled by setting the infer_types directive to None. (The None here refers to the default mode, which will be the default in 0.13.) This safe mode limits inference to Python object types and C doubles, which should speed up execution without affecting any semantics such as integer overflow behavior like infer_types=True might. There is also an infer_types.verbose option which allows one to see what types are inferred. * The boundscheck directive works for lists and tuples as well as buffers. * len(s) and s.decode(encoding) are efficiently supported for char* s. * Cython's INLINE macro has been renamed to CYTHON_INLINE to reduce conflict and has better support for the MSVC compiler on Windows. It is no longer clobbered if externally defined. * Revision history is now omitted from the source package, resulting in a 85% size reduction. Running make repo will download the history and turn the directory into a complete Mercurial working repository. * Cython modules don't need to be recompiled when the size of an external type grows. (A warning, rather than an error, is produced.) This should be helpful for binary distributions relying on NumPy. Several other bugs and minor improvements have been made. This release should be fully backwards compatible with 0.12. For a list of tickets closed, see http://trac.cython.org/cython_trac/query?group=componentmilestone=0.12.1 == Contributors to this release == * Arfrever Frehtes Taifersar Arahesis * Stefan Behnel * Robert Bradshaw * Lisandro Dalcin * Julien Danjou * Mark Lodato * Dag Sverre Seljebotn Thanks also to the many who've submitted feedback and contributed to discussions on the mailing list. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
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=3458package_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-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Python and Ruby
Nobody nob...@nowhere.com 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 ste...@remove.this.cybersource.com.au 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 python.l...@tim.thechases.com 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 stdin, line 1, in module File /usr/lib/python2.5/smtplib.py, line 46, in module 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 type 'exceptions.AttributeError': '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 st...@remove-this- cybersource.com.au wrote: On Fri, 29 Jan 2010 14:49:06 -0800, Jonathan Gardner wrote: On Jan 28, 3:52 pm, elsa kerensael...@hotmail.com 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 module
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 mrk...@gmail.com 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 type 'exceptions.AttributeError': '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 mrk...@gmail.com 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 pan.2010.02.02.03.28...@remove.this.cybersource.com.au Steven D'Aprano ste...@remove.this.cybersource.com.au 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 r...@panix.com wrote: In article hk82uv$8k...@reader1.panix.com, kj no.em...@please.post 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 foo.h 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 ashish.v...@motorola.com 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 no.em...@please.post wrote: In pan.2010.02.02.03.28...@remove.this.cybersource.com.au Steven D'Aprano ste...@remove.this.cybersource.com.au 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
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=3458package_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 pelok...@gmail.com 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 arno...@googlemail.com wrote: Joan Miller pelok...@gmail.com 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 foo.h 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 foo.h 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 nob...@nowhere.com 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 jeanmic...@sequans.com 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 jeanmic...@sequans.com 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 mailman.1795.1265135424.28905.python-l...@python.org Terry Reedy tjre...@udel.edu 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 jeanmic...@sequans.com wrote: Carl Banks wrote: On Feb 2, 2:49 am, Jean-Michel Pichavant jeanmic...@sequans.com 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 mlm...@comcast.net 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 url: 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 mlm...@comcast.net 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:
doc
stats name=position1 description=Calculation statistics
kind=position
stats name=time description=Timing summary kind=section
string name=timersNote description=Note:This is the note
on calculation times/string
stats name=timers kind=timers
timer name=totaltime description=Total time
elapsed609.081574/elapsed
user2531.972081/user
system65.119100/system
/timer
timer name=partialTimer description=Gravitational Displacement
elapsed1772.011230/elapsed
/timer
stats name=subTimers description=All non-phased time
kind=timers
timer name=subATimer description=Phase time A
elapsed72.418861/elapsed
/timer
timer name=subBTimer description=Phase time B
elapsed28.285192/elapsed
/timer
timer name=spaceMem description=Space memory
elapsed0.000/elapsed
/timer
/stats
timer name=endTime description=End
elapsed607.432373/elapsed
/timer
/stats
/stats
stats name=space description=Space usage summary kind=section
stats name=systemSpace description=System Space
memory name=heapSpace description=Total Space
peak483328/peak
current483328/current
/memory
memory name=spaceResidentSize description=Space resident size
peak4182777856/peak
current4182777856/current
/memory
int name=pageMem1/int
int name=memReclaims1943498/int
int name=memSwaps0/int
/stats
stats name=subsystems kind=memstats
memory name=geoSpace description=Geo-Space
peak1640100156/peak
current411307840/current
/memory
memory name=gridSpace description=Grid-Space
peak709596712/peak
current1406752/current
/memory
memory name=spaceMem description=Space memory
peak737720720/peak
current0/current
/memory
memory name=endTime description=End
peak607.432373/peak
/memory
/stats
memory name=subsystemSpace description=Subsystem space
total
peak5164184694/peak
current2054715622/current
/memory
/stats
/stats
/doc
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
Re: Your impression of for-novice writings on assertions
On Feb 2, 12:54 pm, Alf P. Steinbach al...@start.no 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 xah...@gmail.com 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 foo.h 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 no.em...@please.post 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 w...@idi.ntnu.no 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 nob...@nowhere.com 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 j...@castleamber.com wrote:
Jonathan Gardner jgard...@jonathangardner.net 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 ba...@freeuk.com 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 nob...@nowhere.com 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 jgard...@jonathangardner.net 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: Inmailman.1795.1265135424.28905.python-l...@python.org Terry Reedytjre...@udel.edu 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 jgard...@jonathangardner.net 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 mailman.1551.1264701475.28905.python-l...@python.org, D'Arcy J.M. Cain da...@druid.net 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 jgard...@jonathangardner.net
wrote:
On Feb 1, 6:36 pm, John Bokma j...@castleamber.com wrote:
Jonathan Gardner jgard...@jonathangardner.net 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 goblado...@gmail.com 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 ba...@freeuk.com 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 url: 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 al...@start.no 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 url: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 mrk...@gmail.com 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 type 'exceptions.AttributeError': '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 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'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'. small(I feel so icky now...)/small 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 mailman.1804.1265150872.28905.python-l...@python.org Terry Reedy tjre...@udel.edu writes: On 2/2/2010 2:43 PM, kj wrote: Inmailman.1795.1265135424.28905.python-l...@python.org Terry Reedytjre...@udel.edu 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 magaw...@gmail.com 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 r...@rfk.id.au 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 r...@rfk.id.au 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'. small(I feel so icky now...)/small 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 ste...@remove.this.cybersource.com.au 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 r...@rfk.id.au 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 ste...@remove.this.cybersource.com.au 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 jgard...@jonathangardner.net 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 jgard...@jonathangardner.net writes:
On Feb 1, 6:36 pm, John Bokma j...@castleamber.com 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 jgard...@jonathangardner.net 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 cas...@gmail.com 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 ste...@remove.this.cybersource.com.au writes: On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: Jonathan Gardner jgard...@jonathangardner.net 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 j...@castleamber.com writes: Steven D'Aprano ste...@remove.this.cybersource.com.au writes: On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: Jonathan Gardner jgard...@jonathangardner.net 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 Naglena...@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'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
