PyDev 0.9.8.6 released
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.6 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.6: Major highlights: --- * Added a new 'Pydev project' wizard (Mikko Ohtamaa contribution) -- it is named as Pydev Project instead of Python project because it creates Python and Jython projects. * Added a new 'Pydev module' wizard (Mikko Ohtamaa contribution) -- NOTE: it still needs some work. * Changes in the shell spawning were done, and no hangs should appear when trying to do code-completion anymore (if it still hapens, please report it as a bug -- NOTE: a little delay on the first time code-completion is executed is expected, as this is the time the shell is started). * Other bugfixes (as usual) Cheers, Fabio -- Fabio Zadrozny -- Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
[ANN] astng 0.14
Hi ! I'm pleased to announce the new 0.14 version of astng. This release mainly provides some major internal and api changes to have a richer model and a start for static inference on ast nodes. What's new ? * some major inference improvments and refactoring ! The drawback is the introduction of some non backward compatible change in the API but it's imho much cleaner and powerful now :) * new boolean property .newstyle on Class nodes (implements #10073) * new .import_module method on Module node to help in .resolve refactoring * .instance_attrs has list of assignments to instance attribute dictionary as value instead of one * added missing GenExprIf and GenExprInner nodes, and implements as_string for each generator expression related nodes * specifically catch KeyboardInterrupt to reraise it in some places * fix so that module names are always absolute * fix .resolve on package where a subpackage is imported in the __init__ file * fix a bug regarding construction of Function node from living object with realier version of python 2.4 * fix a NameError on Import and From self_resolve method * fix a bug occuring when building an astng from a living object with a property * lint fixes What is astng ? --- The aim of this module is to provide a common base representation of python source code for projects such as pychecker, pyreverse, pylint... Well, actually the development of this library is essentialy governed by pylint's needs. It extends class defined in the compiler.ast [1] module with some additional methods and attributes. Instance attributes are added by a builder object, which can either generate extended ast (let's call them astng ;) by visiting an existant ast tree or by inspecting living object. Methods are added by monkey patching ast classes. Home page - http://www.logilab.org/projects/astng Download ftp://ftp.logilab.org/pub/astng Mailing list mailto://[EMAIL PROTECTED] LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy and happy new year ! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
ANN: MoinMoin 1.5.0 (advanced wiki engine) released
__ /\/\ ___ (_)_ __ /\/\ ___ (_)_ __ /\ / _ \| | '_ \ /\ / _ \| | '_ \ __ / /\/\ \ (_) | | | | / /\/\ \ (_) | | | | | /| |_ \/\/\___/|_|_| |_\/\/\___/|_|_| |_| |.__) == MoinMoin 1.5.0 advanced wiki engine released == MoinMoin is an easy to use, full-featured and extensible wiki software package written in Python. It can fulfill a wide range of roles, such as a personal notes organizer deployed on a laptop or home web server, a company knowledge base deployed on an intranet, or an Internet server open to individuals sharing the same interests, goals or projects. A wiki is a collaborative hypertext environment with an emphasis on easy manipulation of information. MoinMoin 1.5.0 is the first release on the 1.5 branch bringing you several new features such as the GUI editor, which allows the users to edit pages in a WYSIWYG environment, and many bug fixes. The download page: http://moinmoin.wikiwikiweb.de/MoinMoinDownload Major new features in 1.5 = * The WYSIWYG editor for wiki pages allows you to edit pages without touching the markup. Furthermore, the wiki page is not stored as HTML after editing but kept as wiki markup in order to simplify the editing process for users that cannot or do not want to use the new editor. * AutoAdmin security policy allows users to gain admin permissions on particular pages. * The new authentication system allows to add short methods that check the credentials of the user. This allowed us to add eGroupware single sign on support. * Separation of homepages into a separate wiki (in a farm) and having a single user database is supported. * A DeSpam action to allow mass-reverting of spam attacks. * PackageInstaller support for simplified installation of plugins, themes and page bundles. Note that Python 2.3.0 or newer is required. For a more detailed list of changes, see the CHANGES file in the distribution or http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.5/CHANGES MoinMoin History MoinMoin has been around since year 2000. The codebase was initally started by Jürgen Hermann; it is currently being developed by a growing team. Being originally based on PikiPiki, it has evolved heavily since then (PikiPiki and MoinMoin 0.1 consisted of just one file!). Many large enterprises have been using MoinMoin as a key tool of their intranet, some even use it for their public web page. A large number of Open Source projects use MoinMoin for communication and documentation. Of course there is also many private installations. More Information * Project site: http://moinmoin.wikiwikiweb.de/ * Feature list: http://moinmoin.wikiwikiweb.de/MoinMoinFeatures * Download: http://moinmoin.wikiwikiweb.de/MoinMoinDownload * DesktopEdition: http://moinmoin.wikiwikiweb.de/DesktopEdition * This software is available under the GNU General Public License v2. * Changes: http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.5/CHANGES * Known bugs: * http://moinmoin.wikiwikiweb.de/KnownIssues * http://moinmoin.wikiwikiweb.de/MoinMoinBugs sent by Alexander Schremmer for the MoinMoin team -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
[ANN] logilab-common 0.13
Hi ! I'm pleased to announce the 0.13 new release of the logilab-common package. This release provides some bug fixes and minor enhancements and api changes which shouldn't break backward compatibility, so users are strongly encouraged to update. What's new ? * testlib: ability to skip a test * configuration: - cleaner configuration file generation - refactoring so that we can have more control on file configuration loading using read_config_file and load_config_file instead of load_file_configuration * modutils: fix is_relative to return False when from_file is a file located somewhere in sys.path * compat: make set iterable and support more other set operations... * removed the astng sub-package, since it's now self-distributed as logilab-astng What is logilab-common ? logilab-common is a collection of low-level Python packages and modules, designed to ease: * handling command line options and configuration files * writing interactive command line tools * manipulation files and character strings * interfacing to OmniORB * generating of SQL queries * running unit tests * manipulating tree structures * accessing RDBMS (currently postgreSQL and mysql) * generating text and HTML reports * logging Home page - http://www.logilab.org/projects/common Download ftp://ftp.logilab.org/pub/common Mailing list mailto://[EMAIL PROTECTED] LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy, and happy new year! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
[ANN] APyCoT 0.8
Hi !
I'm pleased to announce the new 0.8 release of the APyCoT package. This
release provides some new minor functionnalities.
What's new ?
* use package's pylintrc if a file named pylintrc is found under
the checked out directory (implements #10177)
* ${TESTDIR} in environment variable declared in the tests .ini file
will be sustitued with the tests execution directory
* run tests with all python versions declared usable in the
__pkginfo__ file
* added a new partial checker status, used by the unittest checker
when all tests have passed but some have been skipped
* minor fix in html rendering of the synthetized_report
What is iAPyCoT ?
-
This package is designed to run tests on a code repository on a
daily basis. It comes with a set of predefined test, essentially for python
packages, and a set of predefined reports to display execution results.
However, it has been designed to be higly extensible, so you could write your
own test or report using the Python language (i.e. this framework is NOT
limited to test Python code !).
Home page
-
http://www.logilab.org/projects/apycot
Download
ftp://ftp.logilab.org/pub/apycot
Mailing list
mailto://[EMAIL PROTECTED]
LOGILAB provides services in the fields of XML techniques and advanced
computing (implementation of intelligent agents, knowledge management,
natural language processing, statistical analysis, data mining, etc.),
and also trainings on Python, XML, UML, Object Oriented design, design
patterns use and other cutting edge topics. To know more about
Logilab, visit http://www.logilab.com/.
Logilab is also a strong supporter of the Free Software movement, and an
active member of the Python and Debian communities. Logilab's open
source projects can be found on http://www.logilab.org/.
Enjoy and happy new year !
--
Sylvain Thénault LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations.html
Re: Help wanted with md2 hash algorithm
Paul Rubin wrote: [EMAIL PROTECTED] writes: I thought I had build a proper implementation in Python. The error you mention can be avoided by studying the C implementation in RFC 1319. BUT: Some of the test vectors failed. That's my problem ;-( And therefore I asked for help. You might check PyCrypt against the test vectors. http://www.amk.ca/python/writing/pycrypt/ Already done before my first posting. But the problem was there. I studied the C sources of MD2 of that package, too. But all test cases failed. -- http://mail.python.org/mailman/listinfo/python-list
Re: string to datetime parser?
beza1e1 [EMAIL PROTECTED] wrote: Is there a library which can parse strings and output a datetime object? It should be as magical as possible and allow things like: 12:30 tomorrow 10.10.2005 02-28-00 28/03/95 And given 10/03/95, is that a date in mid-March, or in early October? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: itertools.izip brokeness
Op 2006-01-10, Bengt Richter schreef [EMAIL PROTECTED]: On 9 Jan 2006 08:19:21 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: Op 2006-01-05, Bengt Richter schreef [EMAIL PROTECTED]: On 5 Jan 2006 15:48:26 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: [...] But you can fix that (only test is what you see ;-) : Maybe, but not with this version. from itertools import repeat, chain, izip it = iter(lambda z=izip(chain([3,5,8],repeat(Bye)), chain([11,22],repeat(Bye))):z.next(), (Bye,Bye)) for t in it: print t ... (3, 11) (5, 22) (8, 'Bye') (Feel free to generalize ;-) The problem with this version is that it will stop if for some reason each iterable contains a 'Bye' at the same place. Now this may seem far fetched at first. But consider that if data is collected from ISTM the job of choosing an appropriate sentinel involves making that not only far fetched but well-nigh impossible ;-) experiments certain values may be missing. This can be indicated by a special Missing Data value in an iterable. But this Missing Data value would also be the prime canidate for a fill parameter when an iterable is exhausted. ISTM that confuses missing data with end of data stream. end of data stream implies missing data. If I'm doing experiments with a number of materials under a number of tempertures and I want to compare how copper, iron and lead behaved then when I compare the results for 400 K and there is no data for lead, I don't care whether that is because the measurement for 400K was somehow lost or unsuable or because they stopped the lead measurements at 350K. It all boils down to no data for lead at 400K, there is no need that the processing unit differentiates beteen the different reasons for the missing data. That difference is only usefull for the loop control. I assumed your choice of terminating sentinel (Bye) would not have that problem ;-) That is true, but what is adequate in one situation doesn't need to be adequate in general. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Spelling mistakes!
Op 2006-01-09, Xavier Morel schreef [EMAIL PROTECTED]: Antoon Pardon wrote: I don't think unit tests are that helpful in this case. Unit tests help you in finding out there is a bug, they don't help that much in tracking down a bug. I for some reason a person is reading over the difference between sumLongName and someLongName and doesn't notice the different spelling in his source a unit test won't be of much help. Since 1- The unit test will obviously fail in this case, telling you in which code unit the issue is Not in general. Several unit tests can fail. And if you have a variable spelled differently, the code unit that fails is not dependant on which occurence was spelled correct and which was spelled wrong. So it is very well possible that the code unit with the issue is the one in which the variable is spelled correctly. 2- Unit Test favor extremely modular coding with very short increments (as a somewhat extreme example, Robert Martin gets nervous if his test suites don't validate the code every 5 minutes, you usually don't write 200 lines and their unit tests in 5 minutes) I have a unit test that takes at leas 2 minutes. If I would validate each five minutes I wouldn't get any work done. We can deduce that unit testing will detect the typo extremely early and that the field of research will span about 5 to 10 lines, making the tracking quite easy to perform. Not necessary. You may have started with misspelling the variable and spelled it correctly in your last edit session. Doing your research in the 5 to 10 lines last edited will then reveal nothing. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: testing units in a specific order?
Op 2006-01-09, Tim Peters schreef [EMAIL PROTECTED]: [Antoon Pardon] I have used unit tests now for a number of project. One thing that I dislike is it that the order in which the tests are done bears no relationship to the order they appear in the source. This makes using unit tests somewhat cumbersome. Is there some way to force the tests being done in a particular order? They're run in alphabetical order, sorting on the test methods' names. For that reason some people name test methods like 'test_001', 'test_002', ..., although unit tests really shouldn't case which order they get run in. Well maybe unit tests shouldn't care (Thats what I think you meant), I care. Some methods are vital for the functionality of other methods. So it the test for the first method fails it is very likely a number of other methods will fail too. However I'm not interrested in the results of those other tests in that case. Having to weed through all the test results in order to check first if the vital methods are working before checking other methods is cumbersome. Having the vital methods tested first and ignore the rest of the results if they fail is much easier. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
[Bengt Richter] What about some semantics like my izip2 in http://groups.google.com/group/comp.lang.python/msg/3e9eb63a1ddb1f46?hl=en (which doesn't even need a separate name, since it would be backwards compatible) Also, what about factoring sequence-related stuff into being methods or attributes of iter instances? And letting iter take multiple sequences or callable/sentinel pairs, which could be a substitute for izip and then some? Methods could be called via a returned iterator before or after the first .next() call, to control various features, such as sentinel testing by 'is' instead of '==' for callable/sentinel pairs, or buffering n steps of lookahead supported by a .peek(n) method defaulting to .peek(1), etc. etc. The point being to have a place to implement universal sequence stuff. ISTM, these cures are worse than the disease ;-) Even if there is little use for continuing in correct code, IWT getting at the state of the iterator in an erroroneous situation would be a benefit. Being able to see the result of the last attempt at gathering tuple elements could help. (I can see reasons for wanting variations of trying all streams vs shortcutting on the first to exhaust though). On the one hand, that seems reasonable. On the other hand, I can't see how to use it without snarling the surrounding code in which case it is probably better to explicitly manage individual iterators within a while loop. Raymond -- http://mail.python.org/mailman/listinfo/python-list
[ANN] IPython 0.7.0
Hi all, After a long hiatus (0.6.15 was out in June of 2005), I'm glad to announce the release of IPython 0.7.0, with lots of new features. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. 4. A shell for interactive usage of threaded graphical toolkits. IPython has support for interactive, non-blocking control of GTK, Qt and WX applications via special threading flags. The normal Python shell can only do this for Tkinter applications. WHERE to get it? IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided: - source downloads (.tar.gz) - RPMs (for Python 2.3 and 2.4, built under Fedora Core 3). - Python Eggs (http://peak.telecommunity.com/DevCenter/PythonEggs). - a native win32 installer for both Python 2.3 and 2.4. Fedora users should note that IPython is now officially part of the Extras repository, so they can get the update from there as well (though it may lag by a few days). Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Norbert Tretkowski, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. A lot of new features have gone into this release, the bulk of which were driven by user feedback and requests, and more importantly by patches from IPython users. I greatly appreciate these contributions, and hope they will continue in the future. In particular, thanks to Vivian de Smedt, Jorgen Stenarsson and Ville Vainio, who contributed large patches with much of the new significant functionality. I've tried to provide credit in the notes below and the project's ChangeLog, please let me know if I've accidentally ommitted you. Many thanks to Enthought for their continued hosting support for IPython. Release notes - *** WARNING: compatibility changes *** - IPython now requires at least Python 2.3. If you can't upgrade from 2.2, you'll need to continue using IPython 0.6.15. *** End warning. As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. The highlights of this release follow. - Wildcard patterns in searches, supported by the %psearch magic, as well as the '?' operator. Type psearch? for the full details. Extremely useful, thanks to Jörgen Stenarson. - Major improvements to the pdb mode. It now has tab-completion, syntax highlighting and better stack handling. Thanks to Vivian De Smedt for this work (double-points given that pdb has a well-deserved reputation for being very unpleasant to work with). - Support for input with empty lines. If you have auto-indent on, this means that you need to either hit enter _twice_, or add/remove a space to your last blank line, to indicate you're done entering input. These changes also allow us to provide copy/paste of code with blank lines. - Support for pasting multiline input even with autoindent on. The code will look wrong on screen, but it will be stored and executed correctly internally. - TAB on an otherwise empty line actually inserts a tab. Convenient for indenting (for those who don't use autoindent). - Significant improvements for all multithreaded versions of ipython. Now, if your threaded code raises exceptions, instead of seeing a crash report, a normal (colored, verbose, etc.) exception is printed. Additionally, if you have pdb on, it will activate in your threaded code. Very nice for interactively debugging GUI programs. - Many fixes to embedded ipython, including proper handling of globals and tab completion. - New -t and -o options to %logstart, to respectively put timestamps in your logs, and to also log all output (tagged as #[Out]#). The default log name is now ipython_log.py, to better reflect that logs remain valid Python source. - Lightweight persistence mechanism via %store. IPython had always had %save, to write out a group of input lines directly to a file. Now, its %store companion stores persistently (associated with your profile, and auto-loaded at startup) not just source, but any python variable which can be pickled. Thanks to Matt Wilkie for the request, and ville for the patches. - Macros (created with %macro) can now be edited with %edit (just say '%edit macroname'). This, coupled with the ability to store
Re: Failing unittest Test cases
Scott David Daniels wrote: There has been a bit of discussion about a way of providing test cases in a test suite that _should_ work but don't. One of the rules has been the test suite should be runnable and silent at every checkin. Recently there was a checkin of a test that _should_ work but doesn't. The discussion got around to means of indicating such tests (because the effort of creating a test should be captured) without disturbing the development flow. There is just one situation that I can think of where I would use this, and that is the case where some underlying library has a bug. I would add a test that succeeds when the bug is present and fails when the bug is not present, i.e. it is repaired. That way you get a notification automatically when a new version of the library no longer contains the bug, so you know you can remove your workarounds for that bug. However, I've never used a decorator or anything special for that because I never felt the need for it, a regular testcase like this also works for me: class SomeThirdPartyLibraryTest(unittest.TestCase): def testThirdPartyLibraryCannotComputeSquareOfZero(self): self.assertEqual(-1, tplibrary.square(0), 'They finally fixed that bug in tplibrary.square') Doesn't it defy the purpose of unittests to give them a easy switch so that programmers can turn them off whenever they want to? Cheers, Frank -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt calling an external app?
gregarican wrote: What's the easiest and cleanest way of having PyQt bring up an external application? You can also go the Qt way and use QProcess. This also gives you cross-platform communication and process killing capabilities which are pretty hard to obtain (see the mess in Python with popen[1234]/subprocess). You also get nice signals from the process which interact well in a Qt environment. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
[Raymond Hettinger] I am evaluating a request for an alternate version of itertools.izip() that has a None fill-in feature like the built-in map function: map(None, 'abc', '12345') # demonstrate map's None fill-in feature [Paul Rubin] I think finding different ways to write it was an entertaining exercise but it's too limited in usefulness to become a standard feature. Makes sense. I do think some idiom ought to develop to allow checking whether an iterator is empty, without consuming an item. Here's an idea: introduce something like iterator = check_empty(iterator) There are so many varieties of iterator that it's probably not workable to alter the iterator API for all of the them. In any case, a broad API change like this would need its own PEP. There are some obvious problems with the above: 1) the new iterator should support all of the old one's attributes, not just inherit its operations 2) In the case where the old iterator is already buffered, the constructor should just peek at the lookahead instead of making a new object. That means that checking an iterator multiple times won't burn more and more memory. Maybe there is some way of doing the above with metaclasses but I've never been able to wrap my head around those. Metaclasses are unlikely to be of help because there are so many, unrelated kinds of iterator -- most do not inherit from a common parent. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting Python Installs from the Windows Registry
Great, I'll work with this. Thanks Fuzzyman http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't import Tkinter module.
slomo wrote: I'm working on linux Fedora Core 3 with Python 2.3. I can't from Tkinter import * . And see only No modlue named Tkiner error. Of course I have tk/tcl 8.4. They works perfectly. Certainly, I don't have Tkinter module for Python. What should I do for it as I'm not a root? as root you could do: yum install tkinter Without root, you will have to build python + tkinter yourself from the source (available from www.python.org) Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'd say breaking that is a bad thing. But if you don't break that, then having x == y raise an exception for user classes seems wrong. The comparison should be False unless they are the same object - which is exactly what equality based on id gives us. Seconded. All hell would break loose if Python didn't allow == for heterogenous types, $DEITY only knows how many types I relied on it. Please don't let it go in Py3k. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
Raymond Hettinger [EMAIL PROTECTED] writes: iterator = check_empty(iterator) There are so many varieties of iterator that it's probably not workable to alter the iterator API for all of the them. In any case, a broad API change like this would need its own PEP. The hope was that it wouldn't be an API change, but rather just a new function dropped into the existing library, that could wrap any existing iterator without having to change or break anything that's already been written. Maybe the resulting iterator couldn't support every operation, or maybe it could have a __getattr__ that delegates everything except next to the wrapped iterator, or something. The obvious implementation methods that I can see are very kludgy but maybe something better is feasible. I defer to your knowledge about this. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to create a script that list itself ?
Dave Hansen wrote: Stealing from the old C chestnut: s=s=%c%s%c;print s%%(34,s,34);print s%(34,s,34) Or a bit shorter: s='s=%s;print s%%`s`';print s%`s` -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Scott David Daniels [EMAIL PROTECTED] writes: Recently there was a checkin of a test that _should_ work but doesn't. The discussion got around to means of indicating such tests (because the effort of creating a test should be captured) without disturbing the development flow. Do you mean shouldn't work but does? Anyway I don't understand the question. What's wrong with using assertRaises if you want to check that a test raises a particular exception? -- http://mail.python.org/mailman/listinfo/python-list
Re: Real-world use cases for map's None fill-in feature?
Raymond Hettinger wrote:
Alternately, the need can be met with existing tools by pre-padding the
iterator with enough extra values to fill any holes:
it = chain(iterable, repeat('', group_size-1))
result = izip_longest(*[it]*group_size)
Both approaches require a certain meaure of inventiveness, rely on
advacned tricks, and forgo readability to gain the raw speed and
conciseness afforded by a clever use of itertools. They are also a
challenge to review, test, modify, read, or explain to others.
Is this the author of itertools becoming its most articulate opponent? What
use is this collection of small functions sharing an underlying concept if
you are not supposed to combine them to your heart's content? You probably
cannot pull off some of those tricks until you have good working knowledge
of the iterator protocol, but that is becoming increasingly important to
understand all Python code.
In contrast, a simple generator is trivially easy to create and read,
albiet less concise and not as speedy:
it = iter(iterable)
while 1:
row = tuple(islice(it, group_size))
if len(row) == group_size:
yield row
else:
if row:
yield row + ('',) * (group_size - len(row))
break
The generator version is plain, simple, boring, and uninspirational.
I Can't argue with that :-) But nobody spotted the bug within a day; so
dumbing down the code didn't pay off. Furthermore, simple code like above
is often inlined and therefore harder to test and an impediment to
modification. Once you put the logic into a separate function/generator it
doesn't really matter which version you use. You can't get the
chain/repeat/izip variant to meet your (changing) requirements? Throw it
away and just keep the (modified) test suite.
A newbie, by the way, would have /written/ neither. The it = iter(iterable)
voodoo isn't obvious and the barrier to switch from lst[:group_size] to
islice(it, group_size) to /improve/ one's is code high. I expect to see an
inlined list-based solution. The two versions are both part of a learning
experience and both worth the effort.
Regarding the thread's topic, I have no use cases for a map(None, ...)-like
izip_longest(), but occasionally I would prefer izip() to throw a
ValueError if its iterable arguments do not have the same length.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Scott David Daniels wrote: There has been a bit of discussion about a way of providing test cases in a test suite that should work but don't. One of the rules has been the test suite should be runnable and silent at every checkin. Recently there was a checkin of a test that should work but doesn't. The discussion got around to means of indicating such tests (because the effort of creating a test should be captured) without disturbing the development flow. The following code demonstrates a decorator that might be used to aid this process. Any comments, additions, deletions? Marking a unittest as should fail in the test suite seems just wrong to me, whatever the implementation details may be. If at all, I would apply a I know these tests to fail, don't bother me with the messages for now filter further down the chain, in the TestRunner maybe. Perhaps the code for platform-specific failures could be generalized? Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Paul Rubin wrote: Recently there was a checkin of a test that _should_ work but doesn't. The discussion got around to means of indicating such tests (because the effort of creating a test should be captured) without disturbing the development flow. Do you mean shouldn't work but does? no, he means exactly what he said: support for expected failures makes it possible to add test cases for open bugs to the test suite, without 1) new bugs getting lost in the noise, and 2) having to re- write the test once you've gotten around to fix the bug. Anyway I don't understand the question. it's a process thing. tests for confirmed bugs should live in the test suite, not in the bug tracker. as scott wrote, the effort of creating a test should be captured. (it's also one of those things where people who have used this in real life find it hard to believe that others don't even want to under- stand why it's a good thing; similar to indentation-based structure, static typing, not treating characters as bytes, etc). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: email modules and attachments that aren't there
Hello, main_msg['Content-type'] = 'Multipart/mixed' Would it be the 'Content-Type' header? I've no expertise in this, but doesn't 'multipart' mean 'has attachments'? Brilliant, thank you. A swift test on the number of attachments and changing the header suitably does the job. Thank you for your help, Russell -- The Duck Quacks: http://www-users.york.ac.uk/~rb502/ - Homepage http://www-users.york.ac.uk/~rb502/blog/quack.shtml - Blog http://www.flickr.com/photos/lsnduck/ - Photos -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Scott David Daniels wrote: There has been a bit of discussion about a way of providing test cases in a test suite that _should_ work but don't. One of the rules has been the test suite should be runnable and silent at every checkin. Recently there was a checkin of a test that _should_ work but doesn't. The discussion got around to means of indicating such tests (because the effort of creating a test should be captured) without disturbing the development flow. I like the concept. It would be useful when someone raises an issue which can be tested for easily but for which the fix is non-trivial (or has side effects) so the issue gets shelved. With this decorator you can add the failing unit test and then 6 months later when an apparently unrelated bug fix actually also fixes the original one you get told 'The thrumble doesn't yet gsnort(see issue 1234)' and know you should now go and update that issue. It also means you have scope in an open source project to accept an issue and incorporate a failing unit test for it before there is an acceptable patch. This shifts the act of accepting a bug from putting it onto some nebulous list across to actually recognising in the code that there is a problem. Having a record of the failing issues actually in the code would also helps to tie together bug fixes across different development branches. Possible enhancements: add another argument for associated issue tracker id (I know you could put it in the string, but a separate argument would encourage the programmer to realise that every broken test should have an associated tracker entry), although I suppose since some unbroken tests will also have associated issues this might just be a separate decorator. add some easyish way to generate a report of broken tests. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode Pythonwin / win32 / console?
Martin v. Löwis schrieb: Robert wrote: I'm using Pythonwin and py2.3 (py2.4). I did not come clear with this: I want to use win32-fuctions like win32ui.MessageBox, listctrl.InsertItem . to get unicode strings on the screen - best results according to the platform/language settings (mainly XP Home, W2K, ...). Not sure what your question is - is there even a question in this paragraph? (notice I didn't understand the term to come clear with) Also unicode strings should be displayed as nice as possible at the console with normal print-s to stdout (on varying platforms, different windows/countries and linux, ...; I py2exe/cxfreeze apps) ... Any hints how to do this and make it as complete and automated as possible? No need to do anything - it should work out of the box. hmm...? never got any non-questionable results: PythonWin 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond ([EMAIL PROTECTED]) - see 'Help/About PythonWin' for further copyright information. import win32ui,glob s=glob.glob(u'/devel/test/*')[-2] s u'/devel/test\\\u041f\u043e\u0448\u0443\u043a.txt' win32ui.MessageBox(s) Traceback (most recent call last): File interactive input, line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode characters in position 12-16: ordinal not in range(128) print s /devel/test\?.txt [on a WinXP Home - German; same with py2.3, win98, ... ] The Windows Explorer displays correct cyrillic letters for this file name. win32ui.MessageBox(s) seems to try ascii codec by default. But mbcs/latin-1 (?) encoded 8bit strings like 'aousäöüß' ( =='aous\\xe4\\xf6\\xfc\\xdf' ) work (on this machine). Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Implementing Tuples with Named Items
Bryan wrote: in the python cookbook 2nd edition, section 6.7 (page 250-251), there a problem for implementing tuples with named items. i'm having trouble understanding how one of commands work and hope someone here can explain what exactly is going on. without copying all the code here, here is the gist of the problem: from operator import itemgetter class supertup(tuple): def __new__(cls, *args): return tuple.__new__(cls, args) setattr(supertup, 'x', property(itemgetter(0))) t = supertup(2, 4, 6) t.x 2 i understand what itemgetter does, i = itemgetter(0) i((2, 3, 4)) 2 i((4, 8, 12)) 4 i understand what property does, and i understand what setattr does. i tested this problem myself and it works, but i can't understand how t.x evaluates to 2 in this case. how does itemgetter (and property) know what tuple to use? in my itemgetter sample, the tuple is passed to itemgetter so it's obvious to see what's going on. but in the supertup example, it isn't obvious to me. Perhaps it helps to see the intermediate steps between a standard property definition and your setattr() example: class supertup(tuple): ... def getx(self): return self[0] ... x = property(getx) ... gety = itemgetter(1) ... y = property(gety) ... z = property(itemgetter(2)) ... supertup.t = property(itemgetter(3)) setattr(supertup, u, property(itemgetter(4))) t = supertup(range(5)) t.u, t.t, t.z, t.y, t.x (4, 3, 2, 1, 0) class T: def method(self): pass and class T: pass def method(self): pass T.method = method are both creating a class 'T' with a method 'method'. setattr() is only needed if you don't know the attribute's name at compile time -- a method is just and attribute of a class object. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: csv format to DBase III format
Peter Otten wrote:
William wrote:
Peter Otten wrote:
[EMAIL PROTECTED] wrote:
I need to transfer csv format file to DBase III format file.
How do i do it in Python language?
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/362715
I create a dbf file, it can be opened by Excel but it cannot be opened
by Access. Where is the error in my script.
No idea, but here's some brainstorming.
f = open('test.dbf','w')
First make sure that you open the file in binary mode 'wb'.
If you have an application around that can generate dbfs you could compare a
manually created file with the python-generated one. Have you tried the dbf
with no records? If that is opened without error, you could successively
add records until you find the culprit. Finally, if Excel and Access
disagree about the dbf's validity, the Access import filter could be
broken. Are there other filters for the Dbase family (Foxpro, Clipper)? Try
one of them.
Peter
I have no idea too. I use Foxpro to open the file, but it is failure.
The warning message
is as follows
Either the table record count does not match the actual records in the
table, or the file size on the disk does not match the expected file
size from the table header.
Anybody have any idea?
William
--
http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Fredrik Lundh [EMAIL PROTECTED] writes: no, he means exactly what he said: support for expected failures makes it possible to add test cases for open bugs to the test suite, without 1) new bugs getting lost in the noise, and 2) having to re- write the test once you've gotten around to fix the bug. Oh I see, good idea. But in that case maybe the decorator shouldn't be attached to the test like that. Rather, the test failures should be filtered in the test runner as someone suggested, or the filtering could even integrated with the bug database somehow. -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Peter Otten wrote: Marking a unittest as should fail in the test suite seems just wrong to me, whatever the implementation details may be. If at all, I would apply a I know these tests to fail, don't bother me with the messages for now filter further down the chain, in the TestRunner maybe. Perhaps the code for platform-specific failures could be generalized? It isn't marking the test as should fail it is marking it as should pass, but currently doesn't which is a very different thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: email modules and attachments that aren't there
Hello,
main_msg['Content-type'] = 'Multipart/mixed'
Would it be the 'Content-Type' header? I've no expertise in this, but
doesn't 'multipart' mean 'has attachments'?
Brilliant, thank you. A swift test on the number of attachments and
changing the header suitably does the job.
That isn't quite all there is to it, the e-mail construction needs a
slight change as well. Roughly working code below.
Ta,
Russell
Code:
def sendEmail(msg_to, msg_from, msg_subject, message, attachments=[]):
main_msg = email.Message.Message()
main_msg['To'] = ', '.join(msg_to)
main_msg['From'] = msg_from
main_msg['Subject'] = msg_subject
main_msg['Date'] = email.Utils.formatdate(localtime=1)
main_msg['Message-ID'] = email.Utils.make_msgid()
main_msg['Mime-version'] = '1.0'
main_msg.preamble = 'Mime message\n'
main_msg.epilogue = ''
body_encoded = quopri.encodestring(message, 1)
if len(attachments) 0:
main_msg['Content-type'] = 'Multipart/mixed'
body_msg = email.Message.Message()
body_msg.add_header('Content-type', 'text/plain')
body_msg.add_header('Content-transfer-encoding',
'quoted-printable')
body_msg.set_payload(body_encoded)
main_msg.attach(body_msg)
for attachment in attachments:
content_type, ignored = mimetypes.guess_type(attachment)
if content_type == None:
content_type = 'application/octet-stream'
contents_encoded = cStringIO.StringIO()
attach_file = open(attachment, 'rb')
main_type = content_type[:content_type.find('/')]
if main_type == 'text':
cte = 'quoted-printable'
quopri.encode(attach_file, contents_encoded, 1)
else:
cte = 'base64'
base64.encode(attach_file, contents_encoded)
attach_file.close()
sub_msg = email.Message.Message()
sub_msg.add_header('Content-type', content_type, name=attachment)
sub_msg.add_header('Content-transfer-encoding', cte)
sub_msg.set_payload(contents_encoded.getvalue())
main_msg.attach(sub_msg)
else:
main_msg['Content-type'] = 'text/plain'
main_msg['Content-transfer-encoding'] = 'quoted-printable'
main_msg.set_payload(body_encoded)
smtp = smtplib.SMTP('server')
smtpfail = smtp.sendmail(msg_from, ', '.join(msg_to),
main_msg.as_string())
smtp.quit()
--
http://mail.python.org/mailman/listinfo/python-list
Re: email modules and attachments that aren't there
Russell Bungay wrote:
for attachment in attachments:
snip contents of for loop
sub_msg = email.Message.Message()
sub_msg.add_header('Content-type', content_type, name=attachment)
sub_msg.add_header('Content-transfer-encoding', cte)
sub_msg.set_payload(contents_encoded.getvalue())
main_msg.attach(sub_msg)
These lines should of course be within the for, not outside it. Apologies.
Russell
--
http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Paul Rubin wrote: no, he means exactly what he said: support for expected failures makes it possible to add test cases for open bugs to the test suite, without 1) new bugs getting lost in the noise, and 2) having to re- write the test once you've gotten around to fix the bug. Oh I see, good idea. But in that case maybe the decorator shouldn't be attached to the test like that. Rather, the test failures should be filtered in the test runner as someone suggested, or the filtering could even integrated with the bug database somehow. separate filter lists or connections between the bug database and the code base introduces unnecessary couplings, and complicates things for the developers (increased risk for checkin conflicts, mismatch be- tween the code in a developer's sandbox and the official bug status, etc). this is Python; annotations belong in the annotated code, not in some external resource. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Marshaling unicode WDDX
Ok. but how I suppose to use them. I am currently using marshaller indirectly via wddx.dump(). Anyway, thanks :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Duncan Booth wrote: Peter Otten wrote: Marking a unittest as should fail in the test suite seems just wrong to me, whatever the implementation details may be. If at all, I would apply a I know these tests to fail, don't bother me with the messages for now filter further down the chain, in the TestRunner maybe. Perhaps the code for platform-specific failures could be generalized? It isn't marking the test as should fail it is marking it as should pass, but currently doesn't which is a very different thing. You're right of course. I still think the currently doesn't pass marker doesn't belong into the test source. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Scott David Daniels about marking expected failures: snip I am +1, I have wanted this feature for a long time. FWIW, I am also +1 to run the tests in the code order. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Printing Python Postscript
Hello! After a Opengl 2 Postscript conversion, I want to print my ps files to a plotter. My intents are to read istantaneous characteristics of the plotter, for example the kind of paper it has at a moment, ecc. Is there any python module/extension to interface my program to the printer (something like a Print Manager) and to handle the printer? I'm founding some library, but I want to know if there is something of stable, good for me. Certainly I would try not to use Ghostview or another external tools. Thanks, also if you don't answer! Marco Bonifazi www.marcobonifazi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: [EMAIL PROTECTED] writes: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Maybe that is just a wrong implementation of the in operator. One may agree on a protocol for the in operator to catch the TypeError when it tests for equality and treating the raised exception the same as the two elements not being equal. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'm not that sure about the intuitively. The author of the Enum class didn't seem to find it that intuitive to just name one counter example. IMO x == y turning up false when uncomparable is just as intuitive as x y turning up false when uncomparable but a lot of people don't seem to agree with the latter. My impression is that what is intuitive may vary wildly here. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. I think such cases can be troublesome too for containers and the in operator. IMO some more thinking about this is needed before deciding this would be a good idea or not. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Real-world use cases for map's None fill-in feature?
[Raymond]
Both approaches require a certain measure of inventiveness, rely on
advanced tricks, and forgo readability to gain the raw speed and
conciseness afforded by a clever use of itertools. They are also a
challenge to review, test, modify, read, or explain to others.
[Peter Otten]
Is this the author of itertools becoming its most articulate opponent? What
use is this collection of small functions sharing an underlying concept if
you are not supposed to combine them to your heart's content? You probably
cannot pull off some of those tricks until you have good working knowledge
of the iterator protocol, but that is becoming increasingly important to
understand all Python code.
I'm happy with the module -- it has been well received and is in
widespread use. The components were designed to be useful both
individually and in combination.
OTOH, I sometimes cringe at code reminiscent of APL:
it = chain(iterable, repeat('', group_size-1))
result = izip(*[it]*group_size)
The code is understandable IF you're conversant with all the component
idioms; however, if you're the slightest bit rusty, the meaning of the
code is not obvious. Too much of the looping logic is implicit (1D
padded input reshaped and truncated to a 2D iterator of tuples); the
style is not purely functional (relying on side-effects from multiple
calls to the same iterator); there are two distinct meanings for the
star operator; and it is unlikely that a most people remember the
precedence rules for whether *[it] expands before the [it]*group_size
repeats. All in all, it cannot be claimed to be a masterpiece of
clarity. That being said, if speed was essential, I would use it every
time (as a separate helper function and never as in-line code).
Of course, the main point of the post was that Duncan's use case was
readily solved with existing tools and did not demonstrate a need for
izip_longest(). His original code was almost there -- it just needed
to use chain() instead of list concatenation.
Regarding the thread's topic, I have no use cases for a map(None, ...)-like
izip_longest(), but occasionally I would prefer izip() to throw a
ValueError if its iterable arguments do not have the same length.
The Standard ML authors agree. Their library offers both alternatives
(with and without an exception for unequal inputs):
http://www.standardml.org/Basis/list-pair.html#SIG:LIST_PAIR.zipEq:VAL
Thanks for the input,
Raymond
--
http://mail.python.org/mailman/listinfo/python-list
Re: - E04 - Leadership! Google, Guido van Rossum, PSF
Hi Alex, On Mon, 9 Jan 2006, Alex Martelli wrote: 50%, yes (the other 50% must come from private contributions, that's a EU rule for research projects). It used to be thought that some of the EU money could be used to help pay for sprint participants' travel expenses, but apparently something has gone wrong on that score (probably some EU administrative requirement) -- I didn't ever see any of the travel-expense-help money that was promised to me on one occasion, so I had to swallow that cost myself. This is not the whole truth. We have some procedure now for funding travel costs, although it's admittedly very bureaucratic :-( Anyway, independently of this, there are some people we are happy to see come back again and again to PyPy sprints even though we know their budget is extremely limited. We have always arranged things for them to minimize the costs. It's nothing like a congress where you have to pay XXX/day for having water and cake brought to the tables by the staff at 10am. I can certainly say that attending a PyPy sprint is not expensive at all; I'd expect the major problem to be rather to find a week's free time for it. On the bureaucratic side: Alex, we *have* a procedure at this point, and we have been trying to contact you several time in the past months -- with no success as far as I know, so I'll try via comp.lang.python this time :-) If you still feel like seeing your money back in exchange for some papers to fill and sign, please show up... A bientot, Armin -- http://mail.python.org/mailman/listinfo/python-list
Re: - E04 - Leadership! Google, Guido van Rossum, PSF
Hi Alex, On Mon, 9 Jan 2006, Alex Martelli wrote: 50%, yes (the other 50% must come from private contributions, that's a EU rule for research projects). It used to be thought that some of the EU money could be used to help pay for sprint participants' travel expenses, but apparently something has gone wrong on that score (probably some EU administrative requirement) -- I didn't ever see any of the travel-expense-help money that was promised to me on one occasion, so I had to swallow that cost myself. This is not the whole truth. We have some procedure now for funding travel costs, although it's admittedly very bureaucratic :-( Anyway, independently of this, there are some people we are happy to see come back again and again to PyPy sprints even though we know their budget is extremely limited. We have always arranged things for them to minimize the costs. It's nothing like a congress where you have to pay XXX/day for having water and cake brought to the tables by the staff at 10am. I can certainly say that attending a PyPy sprint is not expensive at all; I'd expect the major problem to be rather to find a week's free time for it. On the bureaucratic side: Alex, we *have* a procedure at this point, and we have been trying to contact you several time in the past months -- with no success as far as I know, so I'll try via comp.lang.python this time :-) If you still feel like seeing your money back in exchange for some papers to fill and sign, please show up... A bientot, Armin -- http://mail.python.org/mailman/listinfo/python-list
Re: Calling foreign functions from Python? ctypes?
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: Thomas Heller wrote: As the author, I would be happy to see ctypes included with the standard Python build. I'm sure you know the magical incantation to get that to happen ... 1. Propose it on python-dev. 2. Commit to maintain it in the python core (or alternatively, propose to use the ElementTree maintenance method). 3. Get it accepted by Guido. 4. Do it. If a library isn't put forward for inclusion by the *author*, it won't be included - even if it's obviously best-of-breed. This was the sticking point for ElementTree (until the author found out what was going on and happily put it forward). I have done 1. I commit myself to 2. I promise to do 3., if someone convinces Guido to accept it (or whoever has the power to accept it). This is my response to Martin v. Löwis, who wrote: I don't have such a plan. To my knowledge, ctypes has never been contributed to Python, either, so its author apparently has no plan, either. It has been proposed to include it in core Python, but Guido didn't accept it. The thread starts here: http://mail.python.org/pipermail/python-dev/2004-January/thread.html#41814 And Guido's last word was this (see the end of the message): http://mail.python.org/pipermail/python-dev/2004-January/041856.html Thomas -- http://mail.python.org/mailman/listinfo/python-list
PyDev 0.9.8.6 released
Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.6 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.6: Major highlights: --- * Added a new 'Pydev project' wizard (Mikko Ohtamaa contribution) -- it is named as Pydev Project instead of Python project because it creates Python and Jython projects. * Added a new 'Pydev module' wizard (Mikko Ohtamaa contribution) -- NOTE: it still needs some work. * Changes in the shell spawning were done, and no hangs should appear when trying to do code-completion anymore (if it still hapens, please report it as a bug -- NOTE: a little delay on the first time code-completion is executed is expected, as this is the time the shell is started). * Other bugfixes (as usual) Cheers, Fabio -- Fabio Zadrozny -- Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Maybe that is just a wrong implementation of the in operator. That's what I said just below: You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Apology Re: Is 'everything' a refrence or isn't it?
Alex Martelli wrote: Ben Sizer [EMAIL PROTECTED] wrote: ... assignment semantics that differ from languages such as C++ and Java, not the calling mechanism. In C++, assignment means copying a value. In Python, assignment means reassigning a reference. And in Java, it means just the same as in Python (with some unfortunate exceptions, in Java, for elementary types such as int -- but for all normal types, the meaning of assignment and parameter passing is just the same in Java as in Python). Considering that Java may have become the language most used for first courses in programming, it's unfortunate to propagate disinformation about its assignment semantics differing from Python's -- it will confuse people who know Java, and there are many of those. Yes, my mistake - I forgot that Java reseats object references rather than copying object values. (I'm a C++ person at heart.) Personally I think this is a reason why Java is a poor language to teach beginners, as it's stuck between low level semantics from C and high level semantics like those of Python. It doesn't provide a very consistent view, meaning you're bound to get confused no matter what second language you start to learn. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
AW: Calling foreign functions from Python? ctypes?
I read the whol email thread carefully and could not find any sentence by Guido, which states that he does not accept ctypes for the standard library. He just declined to rewrite winreg. Did I miss something? Cya, Gerald -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thomas Heller Gesendet: Dienstag, 10. Januar 2006 12:07 An: python-list@python.org Betreff: Re: Calling foreign functions from Python? ctypes? Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: Thomas Heller wrote: As the author, I would be happy to see ctypes included with the standard Python build. I'm sure you know the magical incantation to get that to happen ... 1. Propose it on python-dev. 2. Commit to maintain it in the python core (or alternatively, propose to use the ElementTree maintenance method). 3. Get it accepted by Guido. 4. Do it. If a library isn't put forward for inclusion by the *author*, it won't be included - even if it's obviously best-of-breed. This was the sticking point for ElementTree (until the author found out what was going on and happily put it forward). I have done 1. I commit myself to 2. I promise to do 3., if someone convinces Guido to accept it (or whoever has the power to accept it). This is my response to Martin v. Löwis, who wrote: I don't have such a plan. To my knowledge, ctypes has never been contributed to Python, either, so its author apparently has no plan, either. It has been proposed to include it in core Python, but Guido didn't accept it. The thread starts here: http://mail.python.org/pipermail/python-dev/2004-January/thread.html#41814 And Guido's last word was this (see the end of the message): http://mail.python.org/pipermail/python-dev/2004-January/041856.html Thomas -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
syntax error
Hi Everyone, I am new here but I am pretty good at python programming but I am not exert. I have been away from programming for about a year and now I am programming in python again in combination with IDL. I came across a error that puzzles me and I need some help. It is pretty simple error but I suspect that the problem is not what is python says it is. While parsing a module my python reported a synthax error that, to me, seemed perfectly ok: Traceback (most recent call last): File /local_disk/opt/MSG_PostProc/scr/sheldon_cmsaf_remap.py, line 2, in ? from msgpp_config import * File /local_disk/opt/MSG_PostProc/cfg/msgpp_config.py, line 73 from smhi_safnwc_legends import * ^ SyntaxError: invalid syntax Now I know that there is no synthax error with that line of code. I have also checked for indentations errors. I think that the error is something else. Can anyone point me in the right direction? What triggers such erroneous errors in Python? Sincerely, Sheldon -- http://mail.python.org/mailman/listinfo/python-list
try: except never:
I'd like an 'except exception which is never raised' statement Is there a defined way to do that, for Python 2.2 and above? 'except None:' works for now, but I don't know if that's safe: for ex in ZeroDivisionError, None: try: 1/0 except ex: print Ignored first exception. I could just use except ZeroDivisionError: if not first iteration: raise print Ignored first exception. but the variant above gets a bit neater. -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax error
Sheldon wrote: SyntaxError: invalid syntax Now I know that there is no synthax error with that line of code. I have also checked for indentations errors. I think that the error is something else. Can anyone point me in the right direction? What triggers such erroneous errors in Python? Being a newbie I'm still finding my way around this lot but I've found that when this happens it's usually something on the preceeding line that's wrong. -- Rod -- http://mail.python.org/mailman/listinfo/python-list
Re: try: except never:
Hallvard B Furuseth [EMAIL PROTECTED] writes: 'except None:' works for now, but I don't know if that's safe: for ex in ZeroDivisionError, None: try: 1/0 except ex: print Ignored first exception. class NeverRaised(Exception): pass for ex in ZeroDivisionError, NeverRaised: ... -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax error
Sheldon wrote: I am new here but I am pretty good at python programming but I am not exert. I have been away from programming for about a year and now I am programming in python again in combination with IDL. I came across a error that puzzles me and I need some help. It is pretty simple error but I suspect that the problem is not what is python says it is. While parsing a module my python reported a synthax error that, to me, seemed perfectly ok: Traceback (most recent call last): File /local_disk/opt/MSG_PostProc/scr/sheldon_cmsaf_remap.py, line 2, in ? from msgpp_config import * File /local_disk/opt/MSG_PostProc/cfg/msgpp_config.py, line 73 from smhi_safnwc_legends import * ^ SyntaxError: invalid syntax Now I know that there is no synthax error with that line of code. I have also checked for indentations errors. I think that the error is something else. Can anyone point me in the right direction? What triggers such erroneous errors in Python? Python 2.4.1 contained a bug that could result in spurious syntax errors for relatively large files that uses PEP 263-style coding directives [1]. what Python version are you using ? /F 1) http://www.python.org/peps/pep-0263.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. It is broken in the context of the current python behaviour. In a different context with different behaviour of containers such behaviour may very well be the most intuitive. We are now talking about python3k and so such we should be open to the possibility that what is broken in current python may very well be desirable behaviour for what python will evolve into. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. If you take the first choice you are right that comparing for equality is never meaningless, but so is using the other comparisons. If two objects are not comparable then we just have that a b, a ==b and a b are all false. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? Well not with the in operator but with the index method of lists which seems related enough. If the in operator returns true one can use index to find out an element in the container that compares equal. Now normally it wouldn't make a difference whether you would make further comparisons against the original object or against the object in the list. But in this case it can make a difference and it isn't obvious what one should do. IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax error
Hi Rod, This sounds very interesting. I am checking the previous lines and will get back to you. Thanks, Sheldon -- http://mail.python.org/mailman/listinfo/python-list
Re: try: except never:
Paul Rubin writes: Hallvard B Furuseth [EMAIL PROTECTED] writes: 'except None:' works for now, but I don't know if that's safe: for ex in ZeroDivisionError, None: try: 1/0 except ex: print Ignored first exception. class NeverRaised(Exception): pass for ex in ZeroDivisionError, NeverRaised: Heh. Simple enough. Unless some obstinate person raises it anyway... -- Hallvard -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax error
Hi Rod, You were right. The error was on the previous line. I will remember that. Thanks for your help! Sheldon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really, id({}) id([]).
He also said that default equality comparison will continue to be
identity-based. This means that x == y will never raise an exception,
as is the situation is now. Here's his reason:
Let me construct a hypothetical example: suppose we represent a car
and its parts as objects. Let's say each wheel is an object. Each
wheel is unique and we don't have equivalency classes for them.
However, it would be useful to construct sets of wheels (e.g. the set
of wheels currently on my car that have never had a flat tire). Python
sets use hashing just like dicts. The original hash() and __eq__
implementation would work exactly right for this purpose, and it seems
silly to have to add it to every object type that could possibly be
used as a set member (especially since this means that if a third
party library creates objects for you that don't implement __hash__
you'd have a hard time of adding it).
Now, I don't think it should be so. My reason is basically explicit is
better than implicit - I think that the == operator should be reserved
for value-based comparison, and raise an exception if the two objects
can't be meaningfully compared by value. If you want to check if two
objects are the same, you can always do x is y. If you want to create
a set of objects based on their identity (that is, two different
objects with the same value are considered different elements), you
have two options:
I often want to be able to ask, is one object equal to another, where
they *might* be of the same type or notr.
If they aren't of the same type, then the answer to :
a == b
is obviously False. Otherwise I have to wrap the test in a
``try...except`` block or compare type (and possibly then compare
value). Both of which are more verbose.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mysterious non-module A.sys
Robin Becker wrote: I have a package A containing a null __init__.py and a simple module B.py C:\codecat A\B.py import sys print __file__ print sys.modules.keys() C:\codepython -cimport A.B A\B.py ['copy_reg', 'A.B', 'locale', '__main__', 'site', '__builtin__', 'encodings', 'os.path', 'A.sys', 'encodings.codecs', 'ntpath', 'UserDict', 'encodings.exceptions', 'nt', 'A', 'stat', 'zipimport', 'warnings', 'encodings.types', '_codecs', 'encodings.cp1252', 'sys', 'codecs', 'types', '_locale', 'signal', 'linecache', 'encodings.aliases', 'exceptions', 'os'] C:\code where does A.sys come from? http://www.python.org/doc/essays/packages.html Dummy Entries in sys.modules When using packages, you may occasionally find spurious entries in sys.modules, e.g. sys.modules['Sound.Effects.string'] could be found with the value None. This is an indirection entry created because some submodule in the Sound.Effects package imported the top-level string module. Its purpose is an important optimization: because the import statement cannot tell whether a local or global module is wanted, and because the rules state that a local module (in the same package) hides a global module with the same name, the import statement must search the package's search path before looking for a (possibly already imported) global module. Since searching the package's path is a relatively expensive operation, and importing an already imported module is supposed to be cheap (in the order of one or two dictionary lookups) an optimization is in order. The dummy entry avoids searching the package's path when the same global module is imported from the second time by a submodule of the same package. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Fuzzyman schreef [EMAIL PROTECTED]:
On 9 Jan 2006 14:40:45 -0800, [EMAIL PROTECTED] wrote:
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really, id({}) id([]).
He also said that default equality comparison will continue to be
identity-based. This means that x == y will never raise an exception,
as is the situation is now. Here's his reason:
Let me construct a hypothetical example: suppose we represent a car
and its parts as objects. Let's say each wheel is an object. Each
wheel is unique and we don't have equivalency classes for them.
However, it would be useful to construct sets of wheels (e.g. the set
of wheels currently on my car that have never had a flat tire). Python
sets use hashing just like dicts. The original hash() and __eq__
implementation would work exactly right for this purpose, and it seems
silly to have to add it to every object type that could possibly be
used as a set member (especially since this means that if a third
party library creates objects for you that don't implement __hash__
you'd have a hard time of adding it).
Now, I don't think it should be so. My reason is basically explicit is
better than implicit - I think that the == operator should be reserved
for value-based comparison, and raise an exception if the two objects
can't be meaningfully compared by value. If you want to check if two
objects are the same, you can always do x is y. If you want to create
a set of objects based on their identity (that is, two different
objects with the same value are considered different elements), you
have two options:
I often want to be able to ask, is one object equal to another, where
they *might* be of the same type or notr.
If they aren't of the same type, then the answer to :
a == b
is obviously False. Otherwise I have to wrap the test in a
``try...except`` block or compare type (and possibly then compare
value). Both of which are more verbose.
If we are going to stick to one equal comparator then there will
always be cases that seem to be more verbose than needed. In the
case where you consider it an error if you are working with objects
of different classes you now have to expicitely test for unequal
types and raise an exception explicitly which is also more verbose.
IMO if they aren't of the same type then the answer to:
a b
is just as obviously False as
a == b
Yet how things are proposed now, the first will throw an exception
and the latter will return False.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: try: except never:
Hallvard B Furuseth [EMAIL PROTECTED] writes: class NeverRaised(Exception): pass for ex in ZeroDivisionError, NeverRaised: Heh. Simple enough. Unless some obstinate person raises it anyway... Hmm, ok, how's this?: def NeverRaised(): class blorp(Exception): pass return blorp for ex in ZeroDivisionError, NeverRaised(): ... -- http://mail.python.org/mailman/listinfo/python-list
Encoding - unicode
Hi there, Currently I have a file with germanic names which are, unfortunately in this format: B\xf6genschutz As well as being mixed with those who actually have the correct character's in them. What I am trying to do is convert the characters in the above format to the correct format in a text file. The below 5 lines of code work fine, so it changes the static line of text correctly, but when it reads lines in from the file, and i strip the endline off, it doesn't conver the character's properly. It just keeps them as they are when printed and outputted to the screen. outfile = open(Output.py, 'w') ingermanfile = open(GermanNames.txt, 'r') line = B\xf6genschutz print line.decode(iso-8859-1) raw_input(Yeah) while 1: line = ingermanfile.readline() if not(line): break try: print line templine = line[:-1] temp = templine.decode(iso-8859-1) print ' + templine + ' outfile.write(templine + \n) except: raw_input(Here we are!) outfile.write(line) pass -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt calling an external app?
Giovanni Bajo wrote: You can also go the Qt way and use QProcess. This also gives you cross-platform communication and process killing capabilities which are pretty hard to obtain (see the mess in Python with popen[1234]/subprocess). You also get nice signals from the process which interact well in a Qt environment. -- Giovanni Bajo Good point. I don't think that this particular class is available with Qt 2.3.0, which is what I am using for my Sharp Zaurus and Win32 implementations of this app. Once I move up to the world of Qt 4 I will definitely look into this as an option for certain things. My next quest will be rewriting this app (again) so that it will run on Windows Mobile PDA's using Python and Tkinter for the GUI. Since all of the data pushes/pulls relies on XMLRPC it shouldn't be too daunting. Just need to present the data nicely :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: syntax error
Hi Fredrik, I am using python 2.3.3 I am checking now the previous lines for errors. Thanks, Sheldon -- http://mail.python.org/mailman/listinfo/python-list
XMLBooster 2.10.1 supports Python
* XMLBooster 2.10.1 supports Python * XMLBooster (http://www.xmlbooster.com) version 2.10.1 can generate application-specific XML parsers to be used from within Python. The parsers and the resulting data structures can be accessed by Python code through a comprehensive interface, while the actual parser is generated in C, thereby providing the best of both worlds: top-knotch performance by using optimized code generation in C, and the flexibility and productivity of Python, accessing your document using ad hoc classes rather then generic DOM trees. The interface between C and Python is based by SWIG, but extended with specific additions so that the underlying C structure can be used as is by Python developers, low-level technicalities being taken into account automatically. For instance, linked lists as supported by the XMLBooster's C code generator are published as plain Python lists so that they can be used together with quantifiers or filters. The objects generated by SWIG to access XMLBooster-generated data structures are just facades: they hold no data. They just provide a convenient access to the underlying C structure. Since these facades are created on demand only, this means that one can use these generated parsers to deal with huge XML instances, much larger than what a generic DOM-based parser would allow. The performance and memory footprint gains get even more impressive when only a small part of the XML document is to be accessed from within the Python application. -- http://mail.python.org/mailman/listinfo/python-list
Mysterious non-module A.sys
I have a package A containing a null __init__.py and a simple module B.py C:\codecat A\B.py import sys print __file__ print sys.modules.keys() C:\codepython -cimport A.B A\B.py ['copy_reg', 'A.B', 'locale', '__main__', 'site', '__builtin__', 'encodings', 'os.path', 'A.sys', 'encodings.codecs', 'ntpath', 'UserDict', 'encodings.exceptions', 'nt', 'A', 'stat', 'zipimport', 'warnings', 'encodings.types', '_codecs', 'encodings.cp1252', 'sys', 'codecs', 'types', '_locale', 'signal', 'linecache', 'encodings.aliases', 'exceptions', 'os'] C:\code where does A.sys come from? I tried an experiment and it seems that it's the import statement in B.py so if I changed that to import sys,socket I also get A.socket so I assume it's the import within import that causes these strange modules to appear. Strangely, attempts to import A.sys fail and its value in sys.modules is None. What is the entry for? -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]: On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. That a b returns false doesn't imply that a and b can be ranked. take sets. set([1,2]) and set([1,3)) can't be ranked but set([1,2]) set([1,3)) returns False just as set([1,2]) set([1,3)) does. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. But we don't say the latter. What we do say is that one is 'not greater than' and 'not lesser than' (and 'not equal to') the other. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: try: except never:
Paul Rubin wrote:
Hallvard B Furuseth [EMAIL PROTECTED] writes:
class NeverRaised(Exception): pass
for ex in ZeroDivisionError, NeverRaised:
Heh. Simple enough. Unless some obstinate person raises it anyway...
Hmm, ok, how's this?:
def NeverRaised():
class blorp(Exception): pass
return blorp
for ex in ZeroDivisionError, NeverRaised():
...
Or you can create an unraisable exception:
\
class NeverRaised(Exception):
def __init__(self, *args):
raise RuntimeError('NeverRaised should never be raised')
\
try:
raise NeverRaised
except NeverRaised:
print caught it
Traceback (most recent call last):
File pyshell#47, line 4, in __init__
raise RuntimeError('NeverRaised should never be raised')
RuntimeError: NeverRaised should never be raised
--
http://mail.python.org/mailman/listinfo/python-list
Client side web programming
Hi, Well the trouble is that my orkut scrapbook is flooded. So I reckoned that I'd write some sort of a script to delete the 14800 or so scraps. Now the big problem is that I don't really have too much knowledge about web programming. I have a rough idea about HTTP, HTTPS, cookies etc. but I don't really know the specifics. Question 1: Orkut seems to use a cookie to keep track of who I am. How long will this cookie be valid? Supposing I login using Mozilla and then get hold of this cookie, then use my Python script and send the same cookie whilst send a POST request to delete the entry, will orkut be fooled? Question 2: How do I send a specific cookie along with my request? The whole documentation for urllib2 is rather general and seems to assume thorough knowledge of how those protocols work. Question 3: Is there a simpler way? Question 4: Pointers to further information? Thanks, Pramod -- http://mail.python.org/mailman/listinfo/python-list
Re: Failing unittest Test cases
Peter Otten [EMAIL PROTECTED] wrote: You're right of course. I still think the currently doesn't pass marker doesn't belong into the test source. The agile people would say that if a test doesn't pass, you make fixing it your top priority. In an environment like that, there's no such thing as a test that currently doesn't pass. But, real life is not so kind. These days, I'm working on a largish system (I honestly don't know how many lines of code, but full builds take about 8 hours). A fairly common scenario is some unit test fails in a high level part of the system, and we track it down to a problem in one of the lower levels. It's a different group that maintains that bit of code. We understand the problem, and know we're going to fix it before the next release, but that's not going to happen today, or tomorrow, or maybe even next week. So, what do you do? The world can't come to a screeching halt for the next couple of weeks while we're waiting for the other group to fix the problem. What we typically do is just comment out the offending unit test. If the developer who does that is on the ball, a PR (problem report) gets opened too, to track the need to re-instate the test, but sometimes that doesn't happen. A better solution would be a way to mark the test known to fail because of xyz. That way it continues to show up on every build report (so it's not forgotten about), but doesn't break the build. -- http://mail.python.org/mailman/listinfo/python-list
Re: Removing Duplicate entries in a file...
Thanx Mike, My problem solved !! I loaded the entire file contnets into list and my job was a piece of cake after that. Srikar -- http://mail.python.org/mailman/listinfo/python-list
Re: Mysterious non-module A.sys
Fredrik Lundh wrote: .. where does A.sys come from? http://www.python.org/doc/essays/packages.html Dummy Entries in sys.modules ... /F ... thanks -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list
Re: Client side web programming
Pramod Subramanyan asked aboyt urllib2: Look at this article: http://www.voidspace.org.uk/python/articles/urllib2.shtml Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficient mechanism for str.startswith on a set.
Brian Cole [EMAIL PROTECTED] writes: This is obviously the least efficient manner to do this as I'll always be iterating over the entire 'strs'. I know I could make a binary tree out of 'strs' but that's a little more work that don't have time to do today. I know there should be something out there if I just ask nicely enough. This may be overkill but it's the right approach in principle: http://osteele.com/software/python/fsa/ -- http://mail.python.org/mailman/listinfo/python-list
[ANN] astng 0.14
Hi ! I'm pleased to announce the new 0.14 version of astng. This release mainly provides some major internal and api changes to have a richer model and a start for static inference on ast nodes. What's new ? * some major inference improvments and refactoring ! The drawback is the introduction of some non backward compatible change in the API but it's imho much cleaner and powerful now :) * new boolean property .newstyle on Class nodes (implements #10073) * new .import_module method on Module node to help in .resolve refactoring * .instance_attrs has list of assignments to instance attribute dictionary as value instead of one * added missing GenExprIf and GenExprInner nodes, and implements as_string for each generator expression related nodes * specifically catch KeyboardInterrupt to reraise it in some places * fix so that module names are always absolute * fix .resolve on package where a subpackage is imported in the __init__ file * fix a bug regarding construction of Function node from living object with realier version of python 2.4 * fix a NameError on Import and From self_resolve method * fix a bug occuring when building an astng from a living object with a property * lint fixes What is astng ? --- The aim of this module is to provide a common base representation of python source code for projects such as pychecker, pyreverse, pylint... Well, actually the development of this library is essentialy governed by pylint's needs. It extends class defined in the compiler.ast [1] module with some additional methods and attributes. Instance attributes are added by a builder object, which can either generate extended ast (let's call them astng ;) by visiting an existant ast tree or by inspecting living object. Methods are added by monkey patching ast classes. Home page - http://www.logilab.org/projects/astng Download ftp://ftp.logilab.org/pub/astng Mailing list mailto://[EMAIL PROTECTED] LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy and happy new year ! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
[ANN] PyLint 0.9
Hi ! I'm very pleased to announce the new 0.9 release of PyLint. This release provides a lot of bug fixes and some new checks and other minor changes. This release depends on the latest astng and logilab-common release (i.e. 0.14 and 0.13 respectivly), so install them before this one. The good news is that the new astng inference capabilities should allow to add powerful checks to pylint in a new future :o) What's new ? 2006-01-10 -- 0.9.0 * a lot of updates to follow astng 0.14 API changes, so install logilab-astng 0.14 or greater before using this version of pylint * checker number 10 ! newstyle will search for problems regarding old style / new style classes usage problems (rely on astng 0.14 new style detection feature) * new 'load-plugins' options to load additional pylint plugins (usable from the command line or from a configuration file) (implements #10031) * check if a pylintrc file exists in the current working directory before using the one specified in the PYLINTRC environment variable or the default ~/.pylintrc or /etc/pylintrc * fixed W0706 (Identifier used to raise an exception is assigned...) false positive and reraising a catched exception instance * fixed E0611 (No name get in module blabla) false positive when accessing to a class'__dict__ * fixed some E0203 (access to member before its definition) false positive * fixed E0214 (metaclass method frist argument should be mcs) false positive with staticmethod used on a metaclass * fixed packaging which was missing the test/regrtest_data directory * W0212 (method could be a function) has been reclassified in the REFACTOR category as R0201, and is no more considerer when a method overrides an abstract method from an ancestor class * include module name in W0401 (wildcard import), as suggested by Amaury * when using the '--parseable', path are written relative to the current working directory if in a sub-directory of it (#9789) * 'pylint --version' shows logilab-astng and logilab-common versions * fixed pylint.el to handle space in file names * misc lint style fixes What is pylint ? Pylint is a python tool that checks if a module satisfy a coding standard. Pylint can be seen as another pychecker since nearly all tests you can do with pychecker can also be done with Pylint. But Pylint offers some more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented, and much more (see http://www.logilab.org/projects/pylint/ for the complete check list). The big advantage with Pylint is that it is highly configurable, customizable, and you can easily write a small plugin to add a personal feature. The usage it quite simple : $ pylint mypackage.mymodule This command will output all the errors and warnings related to the tested code (here : mypackage.mymodule), will dump a little summary at the end, and will give a mark to the tested code. Pylint is free software distributed under the GNU Public Licence. Home page - http://www.logilab.org/projects/pylint Download ftp://ftp.logilab.org/pub/pylint Mailing list mailto://[EMAIL PROTECTED] Enjoy and happy new year ! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficient mechanism for str.startswith on a set.
Brian Cole wrote: I need to iterate through a file, checking whether each line 'startswith()' a string that belongs to a set. Normally, the most efficient way I would do this would be: strs=set(['foo','bar']) for line in file: if line.strip() in strs: print line However, for this case I need to do a startswith like this: for line in file: for s in strs: if line.startswith(s): print line This is obviously the least efficient manner to do this as I'll always be iterating over the entire 'strs'. I know I could make a binary tree out of 'strs' but that's a little more work that don't have time to do today. I know there should be something out there if I just ask nicely enough. the RE approach used in this MultiReplace class can be quite efficient: http://effbot.org/zone/python-replace.htm e.g. strs.sort() # lexical order strs.reverse() # use longest match first pattern = string.join(map(re.escape, strs), |) match = re.compile(pattern).match for line in file: if match(line): print line a less general solution would be to check line[:x] against a dictionary, where x is max(len(s) for s in strs), and use a fallback test if the test fails (which up- dates the dictionary). this only works well if x is relatively small, the files are relatively regular and not too large, and most lines match. /F -- http://mail.python.org/mailman/listinfo/python-list
[ANN] logilab-common 0.13
Hi ! I'm pleased to announce the 0.13 new release of the logilab-common package. This release provides some bug fixes and minor enhancements and api changes which shouldn't break backward compatibility, so users are strongly encouraged to update. What's new ? * testlib: ability to skip a test * configuration: - cleaner configuration file generation - refactoring so that we can have more control on file configuration loading using read_config_file and load_config_file instead of load_file_configuration * modutils: fix is_relative to return False when from_file is a file located somewhere in sys.path * compat: make set iterable and support more other set operations... * removed the astng sub-package, since it's now self-distributed as logilab-astng What is logilab-common ? logilab-common is a collection of low-level Python packages and modules, designed to ease: * handling command line options and configuration files * writing interactive command line tools * manipulation files and character strings * interfacing to OmniORB * generating of SQL queries * running unit tests * manipulating tree structures * accessing RDBMS (currently postgreSQL and mysql) * generating text and HTML reports * logging Home page - http://www.logilab.org/projects/common Download ftp://ftp.logilab.org/pub/common Mailing list mailto://[EMAIL PROTECTED] LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy, and happy new year! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
[ANN] APyCoT 0.8
Hi !
I'm pleased to announce the new 0.8 release of the APyCoT package. This
release provides some new minor functionnalities.
What's new ?
* use package's pylintrc if a file named pylintrc is found under
the checked out directory (implements #10177)
* ${TESTDIR} in environment variable declared in the tests .ini file
will be sustitued with the tests execution directory
* run tests with all python versions declared usable in the
__pkginfo__ file
* added a new partial checker status, used by the unittest checker
when all tests have passed but some have been skipped
* minor fix in html rendering of the synthetized_report
What is iAPyCoT ?
-
This package is designed to run tests on a code repository on a
daily basis. It comes with a set of predefined test, essentially for python
packages, and a set of predefined reports to display execution results.
However, it has been designed to be higly extensible, so you could write your
own test or report using the Python language (i.e. this framework is NOT
limited to test Python code !).
Home page
-
http://www.logilab.org/projects/apycot
Download
ftp://ftp.logilab.org/pub/apycot
Mailing list
mailto://[EMAIL PROTECTED]
LOGILAB provides services in the fields of XML techniques and advanced
computing (implementation of intelligent agents, knowledge management,
natural language processing, statistical analysis, data mining, etc.),
and also trainings on Python, XML, UML, Object Oriented design, design
patterns use and other cutting edge topics. To know more about
Logilab, visit http://www.logilab.com/.
Logilab is also a strong supporter of the Free Software movement, and an
active member of the Python and Debian communities. Logilab's open
source projects can be found on http://www.logilab.org/.
Enjoy and happy new year !
--
Sylvain Thénault LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] devtools 0.8
Hi ! I'm pleased to announce the new 0.8 release of the devtools package. This release provides some bug fixes and major changes into the debian package generation. What's new ? * debianize: * updated to handle site-python installation with architecture independant package (implements #10119) * consider the optional debian_uploader variable in package information * fix .examples files generation with debianize * fix templates: control.standard-version is now 3.6.2, updated FSF address in debian licenses files * fix package type detection in preparedistrib (fix #9917) What is devtools ? -- Set of tools which aims to help the developpement process, including : * standard for zope and python packages * tools to check and build source and/or debian packages * python coverage tool * cvs utilities Home page - http://www.logilab.org/projects/devtools Download ftp://ftp.logilab.org/pub/devtools Mailing list mailto://[EMAIL PROTECTED] LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy and happy new year ! -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org -- http://mail.python.org/mailman/listinfo/python-list
Python and location of .so files?
Hello, On FC4, I've generated an .so file from C++ which I want to use from python. It works when I copy it into /usr/lib/python2.4/site-packages. (I.e., say I have hello.so in that directory, then from the python prompt I can 'import hello', and the code works fine). The problem is that the said directory requires su - so I'd rather python load my .so from a different user-privilege directory (when I type 'import hello'). Is there some way to tell python to use a different directory? Many thanks for considering this question. Also, it's possible that this question belongs in a different forum, and if so, I'd appreciate if you'd tell me where. Thanks, Efrat -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
[Raymond Hettinger] ... I scanned the docs for Haskell, SML, and Perl and found that the norm for map() and zip() is to truncate to the shortest input or raise an exception for unequal input lengths. ... Also, I'm curious as to whether someone has seen a zip fill-in feature employed to good effect in some other programming language, perhaps LISP or somesuch? FYI, Common Lisp's `pairlis` function requires that its first two arguments be lists of the same length. It's a strain to compare to Python's zip() though, as the _intended_ use of `pairlis` is to add new pairs to a Lisp association list. For that reason, `pairlis` accepts an optional third argument; if present, this should be an association list, and pairs from zipping the first two arguments are prepended to it. Also for this reason, the _order_ in which pairs are taken from the first two arguments isn't defined(!). http://www.lispworks.com/documentation/HyperSpec/Body/f_pairli.htm#pairlis For its intended special-purpose use, it wouldn't make sense to allow arguments of different lengths. -- http://mail.python.org/mailman/listinfo/python-list
Efficient mechanism for str.startswith on a set.
I need to iterate through a file, checking whether each line 'startswith()' a string that belongs to a set. Normally, the most efficient way I would do this would be: strs=set(['foo','bar']) for line in file: if line.strip() in strs: print line However, for this case I need to do a startswith like this: for line in file: for s in strs: if line.startswith(s): print line This is obviously the least efficient manner to do this as I'll always be iterating over the entire 'strs'. I know I could make a binary tree out of 'strs' but that's a little more work that don't have time to do today. I know there should be something out there if I just ask nicely enough. Thanks ahead of time. -Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon wrote: Op 2006-01-10, Peter Decker schreef [EMAIL PROTECTED]: I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. That a b returns false doesn't imply that a and b can be ranked. take sets. set([1,2]) and set([1,3)) can't be ranked but set([1,2]) set([1,3)) returns False just as set([1,2]) set([1,3)) does. Breaking my resolution already, but you're ignoring the fact that the set type uses the '' and '' operators from a set-theoretic, not number-theoretic point of view. Saying set(1,3) is greater than set(1,2) is meaningless (and not false), because the mathematical basis of the operator in this context is superset -- set(1,3) is a superset of set(1,2) is well-defined and false. Set uses '' and '' because the superset and subset symbols aren't on the keyboard. In languages that allow operator overloading, there are always some well-defined cases where the operator is the simplest, clearest notation yet the operator has a meaning very distinct from the arithmetical operation. As another example, Pyparsing uses '' to load a Forward declaration, for recursive grammars -- this obviously has nothing to do with bit-shifting. Of course, cases like these two are fairly textbook examples for the argument that operator overloading is unclear; Python accepts the occasional ambiguity and allows (indeed encourages, to a reasonable degree) operator overloading for conciseness and expressiveness. To reply to your other argument, Antoon: Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. [snip] I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). I personally feel that the use cases for this other comparison (===?) are very restricted. In fact, your example itself isn't even a use-case for this operator, because integer/float/decimal have well-defined equality comparisons already (that explicitly account for different types) -- the implicit not is implies !=, if __eq__ isn't defined behaviour isn't triggered. The use-case for a === operator would seem to be restricted to when program behaviour is determined soley by a not equalling b. If a wrong object is referenced by b, then the program might do a Bad Thing, because it expects b to be something else... except that the error would be caught later anyway -- probably by calling b.method() or somesuch. In fact, even in more esoteric cases the behaviour of == as-is is useful; in the itertools.izip_longest discussion, this behaviour is implicitly used in the sentinel-stopping method (izip(chain(iter,sent),chain(iter,sent),...,stop=(sent,sent,sent,...)), to badly mangle the syntax). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and location of .so files?
On Tue, 2006-01-10 at 09:42, Efrat Regev wrote: Hello, On FC4, I've generated an .so file from C++ which I want to use from python. It works when I copy it into /usr/lib/python2.4/site-packages. (I.e., say I have hello.so in that directory, then from the python prompt I can 'import hello', and the code works fine). The problem is that the said directory requires su - so I'd rather python load my .so from a different user-privilege directory (when I type 'import hello'). Is there some way to tell python to use a different directory? Yes. See http://docs.python.org/tut/node8.html#SECTION00811 for information on Python's module search path. Hope this helps, Carsten. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Peter Decker wrote: On 10 Jan 2006 13:33:20 GMT, Antoon Pardon [EMAIL PROTECTED] wrote: IMO if they aren't of the same type then the answer to: a b is just as obviously False as a == b Yet how things are proposed now, the first will throw an exception and the latter will return False. I don't see the two comparisons as equivalent at all. If two things are different, it does not follow that they can be ranked. If we have two objects, such as a spark plug and a cam shaft, it is one thing to say that the two are not the same object; it is quite another to say that one is 'greater than' or 'less than' the other. I agree. If a and b are of incomparable types, then a != b is True but a b is meaningless. All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Regex help needed
Hi all, I am using python to drive another tool using pexpect. The values which I get back I would like to automatically put into a list if there is more than one return value. They provide me a way to see that the data is in set by parenthesising it. This is all generated as I said using pexpect - Here is how I use it.. child = pexpect.spawn( _buildCadenceExe(), timeout=timeout) child.sendline(somefunction()) child.expect( ) data=child.before Given this data can take on several shapes: Single return value -- THIS IS THE ONE I CAN'T GET TO WORK.. data = 'somefunction()\r\n@(#)$CDS: icfb.exe version 5.1.0 05/22/2005 23:36 (cicln01) $\r\n' Multiple return value data = 'somefunction()\r\n(. ~ /eda/ic_5.10.41.500.1.18/tools.lnx86/dfII/samples/techfile)\r\n' It may take up several lines... data = 'somefunction()\r\n(. ~ \r\n/eda/ic_5.10.41.500.1.18/tools.lnx86/dfII/samples/techfile\r\nfoo)\r\n' So if you're still reading this I want to parse out data. Here are the rules... - Line 1 ALWAYS is the calling function whatever is there (except \r\n) should be kept as original - Anything may occur inside the quotations - I don't care what's in there per se but it must be maintained. - Parenthesed items I want to be pushed into a list. I haven't run into a case where you have nested paren's but that not to say it won't happen... So here is my code.. Pardon my hack job.. import os,re def main(data=None): # Get rid of the annoying \r's dat=data.split(\r) data=.join(dat) # Remove the first line - that is the original call dat = data.split(\n) original=dat[0] del dat[0] print Original, original # Now join all of the remaining lines retl=.join(dat) # self.logger.debug(Original = \'%s\' % original) try: # Get rid of the parenthesis parmatcher = re.compile( r'\(([^()]*)\)' ) parmatch = parmatcher.search(retl) # Get rid of the first and last quotes qrmatcher = re.compile( r'\([^()]*)\' ) qrmatch = qrmatcher.search(parmatch.group(1)) # Split the items qmatch=re.compile(r'\\s+\') results = qmatch.split(qrmatch.group(1)) except: qrmatcher = re.compile( r'\([^()]*)\' ) qrmatch = qrmatcher.search(retl) # Split the items qmatch=re.compile(r'\\s+\') results = qmatch.split(qrmatch.group(1)) print Orig, original, Results, results return original,results # General run.. if __name__ == '__main__': # data = 'someFunction\r\n test foo\r\n' # data = 'someFunction\r\n test foo\r\n' data = 'getVersion()\r\n@(#)$CDS: icfb.exe version 5.1.0 05/22/2005 23:36 (cicln01) $\r\n' # data = 'someFunction\r\n (test test1 foo aasdfasdf\r\n newline test2)\r\n' main(data) CAN SOMEONE PLEASE CLEAN THIS UP? -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
On 10 Jan 2006 00:47:36 -0800, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Bengt Richter]
What about some semantics like my izip2 in
http://groups.google.com/group/comp.lang.python/msg/3e9eb63a1ddb1f46?hl=en
(which doesn't even need a separate name, since it would be backwards
compatible)
Also, what about factoring sequence-related stuff into being methods or
attributes
of iter instances? And letting iter take multiple sequences or
callable/sentinel pairs,
which could be a substitute for izip and then some? Methods could be called
via a returned
iterator before or after the first .next() call, to control various
features, such as
sentinel testing by 'is' instead of '==' for callable/sentinel pairs, or
buffering n
steps of lookahead supported by a .peek(n) method defaulting to .peek(1),
etc. etc.
The point being to have a place to implement universal sequence stuff.
ISTM, these cures are worse than the disease ;-)
Are you reacting to my turgidly rambling post, or to
from ut.izip2 import izip2 as izip
it = izip('abc','12','ABCD')
for t in it: print t
...
('a', '1', 'A')
('b', '2', 'B')
Then after a backwards-compatible izip, if the iterator has
been bound, it can be used to continue, with sentinel sustitution:
for t in it.rest('sentinel'): print t
...
('c', 'sentinel', 'C')
('sentinel', 'sentinel', 'D')
or optionally in sentinel substitution mode from the start:
for t in izip('abc','12','ABCD').rest('sentinel'): print t
...
('a', '1', 'A')
('b', '2', 'B')
('c', 'sentinel', 'C')
('sentinel', 'sentinel', 'D')
Usage-wise, this seems not too diseased to me, so I guess I want to make sure
this is what you were reacting to ;-)
(Implementation was just to hack together a working demo. I'm sure it can be
improved upon ;-)
Even if there is little use for continuing in correct code, IWT getting
at the state of the iterator in an erroroneous situation would be a benefit.
Being able to see the result of the last attempt at gathering tuple elements
could help. (I can see reasons for wanting variations of trying all streams
vs shortcutting on the first to exhaust though).
On the one hand, that seems reasonable. On the other hand, I can't see
how to use it without snarling the surrounding code in which case it is
probably better to explicitly manage individual iterators within a
while loop.
The above would seem to allow separation of concerns. I.e., if you care why
a normal iteration terminated, you can test after the fact. I.e., if all
sequences
were the same length, the .rest() iterator will be empty. And if you don't care
at
all about possible data, you can just try: it.rest().next() and catch
StopIteration
to check.
BTW, is there any rule against passing information with StopIteration?
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
Re: AW: Calling foreign functions from Python? ctypes?
Gerald Klix [EMAIL PROTECTED] writes: I read the whol email thread carefully and could not find any sentence by Guido, which states that he does not accept ctypes for the standard library. He just declined to rewrite winreg. Did I miss something? Maybe I misinterpreted what he wrote myself. Ok, I'll propose on python-dev to include ctypes into core python. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL implementation
arkestra wrote: The error message is -- Syntax error and it highlights the last else statement. You've got incorrect indentation, at least judging by what I see in my newsreader (Thunderbird), which clearly shows the else indented more than the corresponding if. Next time, please cut and paste the *actual* error message instead of retyping and paraphrasing. That will get you a faster answer and save us lots of annoying guessing. -- http://mail.python.org/mailman/listinfo/python-list
urllib.urlopen and https question
Hi, I'm new to python. I've been handed the job of modifying a script we have here at work that pulls content from a zope site, to create static html. They wanted a check to make sure the database is up, while pulling, to avoid errors. I got it pretty much working how I want without any problems. It's actually an error check I'm having a problem with. Usernames and passwords change I'm using urlib.urlopen to open a connection to a https url using the format of https://username:[EMAIL PROTECTED] This works great. However, if I put in the wrong username, the python script prompts for user validation, rather than giving an error. The script is not interactive, will be run by cron. So I can't just let it hang. I'm trying to figure out if there is a way to catch that prompt and error out within the python script, rather that writing an expect wrapper for it. The less interpeters I have to use, the better for my cpu. -- http://mail.python.org/mailman/listinfo/python-list
Re: - Requesting Comments for Process Definition and Presentation
Gerard Flanagan wrote: Ilias Lazaridis wrote: Ilias Lazaridis wrote: I would like to ask for feedback on the Process Definition and Presentation. snip Your feedback is _very_ important to me. snip ...The prices for our services start at 250,- €. There is a spiritual issue here which I don't think you appreciate! Please clarify. Do you mean the Asking/retrieving free feedback, whilst offering payed services? I'll send you some spelling corrections if I get a chance. Please contact me with private email. Here's some links (Google 'Software Compliance'): http://www.fastcorporateservices.com/fast/projects/textandlinkslist.asp?site=1SiteSect=8 http://www.pcprofile.com/aboutus.htm Very Intresting links. All the best Gerard . -- http://lazaridis.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Client side web programming
And this one for cookie handling: http://www.voidspace.org.uk/python/articles/cookielib.shtml All the best, Fuzzyman -- http://mail.python.org/mailman/listinfo/python-list
Re: Sockets on Windows and Mac
rodmc wrote: I am currently importing the socket library when I write the programs, I have had no problems with it on my PC at work, but the Mac at home steadfastly refuses to work. One rule about asking for help in forums like this is to provide adequate background detail about your environment. Generally that includes version numbers of things. What versions of Python are you trying to work with? Note that the code you posted, from that tutorial, is out of date and needs to be fixed for recent versions of Python, where the argument to .bind() is a single tuple, not two separate arguments. Anyway, next time please post snippets of your actual code, with the error tracebacks *cut and pasted* right out of your terminal window, so that you don't waste our time by making us guess what you're actually doing. That way you'll get quick and accurate assistance and keep everyone helping you happy. :-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and location of .so files?
Carsten Haese wrote: On Tue, 2006-01-10 at 09:42, Efrat Regev wrote: Hello, On FC4, I've generated an .so file from C++ which I want to use from python. It works when I copy it into /usr/lib/python2.4/site-packages. (I.e., say I have hello.so in that directory, then from the python prompt I can 'import hello', and the code works fine). The problem is that the said directory requires su - so I'd rather python load my .so from a different user-privilege directory (when I type 'import hello'). Is there some way to tell python to use a different directory? Yes. See http://docs.python.org/tut/node8.html#SECTION00811 for information on Python's module search path. Hope this helps, Carsten. Perfect. Thank you very much! -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib.urlopen and https question
From the docs for urllib: When performing basic authentication, a FancyURLopener instance calls its prompt_user_passwd() method. The default implementation asks the users for the required information on the controlling terminal. A subclass may override this method to support more appropriate behavior if needed. Cheers Rich. -- http://mail.python.org/mailman/listinfo/python-list
Re: Get path of a class
Florian Lindner wrote: Hello, how can I get the path of a class. I managed to do it with c.__module__ + . + c.__name__ but I'm sure there is a better way. Please define what you mean by path (and how you hope to make use of this information). Generally a module has a path (i.e. a location where it can be loaded from the file system) but classes are merely created by class statements within a module. There is no one-to-one match with files, and in fact no requirement that a class even be traceable directly to statements in a source file. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. The behavior proposed for Py3k *is* the practical route. It gives a reasonable behavior, and one that leads to simple implemenations for container operations. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? BTW, the case you're arguing for is *different* from the case the OP proposed. By my reading, he wanted equality testing to throw an exception for two objects unless a comparison was explicitly coded. So that even a == a could cause an exception. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Comparators - including equality comparators - can already throw exceptions. The enum case proved that. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? Again - give us real use cases. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. Floats *are* a discrete type. The equality *relationship* is what's fuzzy. There are lots of non-transitive relationships around. I don't find them wierd at all. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? Well not with the in operator but with the index method of lists which seems related enough. The index method of list is already a bit fuzzy. If the in operator returns true one can use index to find out an element in the container that compares equal. Now normally it wouldn't make a difference whether you would make further comparisons against the original object or against the object in the list. But in this case it can make a difference and it isn't obvious what one should do. That's because in this case there's no on right answer. What you should do will depend on what you are trying to accomplish. That's the normal state of affairs when programming. IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). That's an argument for a more *precise* equality operator. That's certainly worth considering, but has nothing to do with whether or not it makes sense for an equality comparison to throw an exception. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
There are so many varieties of iterator that it's probably not workable to alter the iterator API for all of the them. i always wondered if it can be implemented: there are iterators which has length: i = iter([1,2,3]) len(i) 3 now isn't there a way to make this length inheritible? eg. generators could have length in this case: g = (x for x in [1,2,3]) # len(g) == len([1,2,3]) == 3 of course in special cases length would remain undefined: f = (x for x in [1,2,3] if x2) # len(f) == ? IMHO there are special cases when this is useful: L=list(it) here if it has length, then list creation can be more effective (required memory is known in advance) nsz -- http://mail.python.org/mailman/listinfo/python-list
Re: Do you have real-world use cases for map's None fill-in feature?
There are so many varieties of iterator that it's probably not workable to alter the iterator API for all of the them. i always wondered if it can be implemented: there are iterators which has length: i = iter([1,2,3]) len(i) 3 now isn't there a way to make this length inheritible? eg. generators could have length in this case: g = (x for x in [1,2,3]) # len(g) == len([1,2,3]) == 3 of course in special cases length would remain undefined: f = (x for x in [1,2,3] if x2) # len(f) == ? IMHO there are special cases when this is useful: L=list(it) here if it has length, then list creation can be more effective (required memory is known in advance) nsz -- http://mail.python.org/mailman/listinfo/python-list
