[issue4661] email.parser: impossible to read messages encoded in a different encoding
Changes by Tony Meyer anadelonb...@users.sourceforge.net: -- nosy: +anadelonbrin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4661 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue845560] imaplib: traceback from _checkquote with empty string
Tony Meyer anadelonb...@users.sourceforge.net added the comment: Why does the patch being very small make it more trouble? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue845560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Pyzor 0.5 Released
The Pyzor team is pleased to announce release 0.5 of Pyzor. The previous release was made in September of 2002, so it has obviously been a while! With this release, we have aimed to resolve all the outstanding reported bugs and incorporate submitted patches (many of which are also from some time ago). The hope is that this, along with the recent improvements to the public Pyzor server, revitalises the Pyzor project. We are aiming to release the next version of Pyzor, which will include new features, around the end of June (2009!). If you'd like to have input into that release, please subscribe to the pyzor-users mailing list, or monitor the SourceForge tickets for the Pyzor project. We are very keen to have as much input from the user-base as possible. The majority of the improvements in the 0.5 release were submitted from the Debian Pyzor package. Many thanks to them for pushing these back 'upstream' - if you have any improvements that you are running locally, please consider doing the same and contributing these as patches to the main Pyzor package (open a ticket on the SourceForge site). Main changes include: * Man pages for pyzor and pyzord. * Changing back to signals for database locking, rather than threads. It is likely that signals will be removed again in the future, but the existing threading changes caused problems. * Basic checks on the results of discover. * Extended mbox support throughout the library. * Better handling on unknown encodings. * Added a --log option to log to a file. * Better handling of command-line options. * Improved error handling. You can get the release (via the 'download' link on the left), as well as information about the mailing lists and other news, at: http://pyzor.org Enjoy the new release and your reduced spam mail :) As always, thanks to everyone involved in this release! Tony. (on behalf of the Pyzor team) --- What is Pyzor? --- Pyzor is a collaborative, networked system to detect and block spam using identifying digests of messages. Pyzor initially started out to be merely a Python implementation of Razor, but due to the protocol and the fact that Razor's server is not Open Source or software libre, Frank Tobin decided to implement Pyzor with a new protocol and release the entire system as Open Source and software libre. Since the entire system is released under the GPL, people are free to host their own independent servers, although there is a well-maintained public server available (public.pyzor.org), which anyone is welcome to use. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
[issue1054967] bdist_deb - Debian packager
Changes by Tony Meyer anadelonb...@users.sourceforge.net: -- nosy: +anadelonbrin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1054967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1161031] Neverending warnings from asyncore
Tony Meyer anadelonb...@users.sourceforge.net added the comment: None of my arguments have really changed since 2.4. I still believe that this is a poor choice of default behaviour (and if it is meant to be overridden to be useable, then 'pass' or 'raise NotYetImplementedError' would be a better choice). However, my impression is that nothing I say will convince you of that, so I'll give up on that. It would have been interesting to hear from Andrew the reason for the code. However, this is definitely a documentation bug (as outlined previously), and so should be fixed, not closed. I can provide a patch if it stands a chance of being accepted. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: One class per file?
[HCB] The book Code Complete recommends that you put only one class in a source file, which seems a bit extreme for me. IMO this is a misunderstanding (by the author). In Python, a file is not equivalent to a class, it is equivalent to a module. A module might contain a single class or many, just as a class might contain a single method or many. You can tell that files are not classes, because you have have variables, methods, etc at the module level, outside of class definitions. If all of the module's functionality is in a single class, then of course the file only contains one class. If the module's functionality is split over many classes (or no classes at all), then the file will not contain exactly one class. Rigidly putting every class in a separate file would mean that the next level higher than classes wouldn't be modules, it would be packages. [Roy Smith] Consider this. You're slogging through some code in a large project trying to debug a problem when you come upon the line (in pseudo-code): foo = SomeClass::SomeFunction(bar) You want to go look at the source for SomeClass. What file do you open to find it? If you follow the one class per file rule, the answer is easy; it's in SomeClass.xxx! Alternatively, most IDEs will let you go to the source very simply. If you don't have that facility available, then you just do import X;print X.__file__. Cheers, Tony -- http://mail.python.org/mailman/listinfo/python-list
Re: Regex doesn't support MULTILINE?
I'm trying to extract information from a web page using the Re module, but it doesn't seem to support MULTILINE: [...] Do I need to add something else to have Re work as intended? I believe you are looking for DOTALL, not MULTILINE. From the documentation: M MULTILINE When specified, the pattern character ^ matches at the beginning of the string and at the beginning of each line (immediately following each newline); and the pattern character $ matches at the end of the string and at the end of each line (immediately preceding each newline). By default, ^ matches only at the beginning of the string, and $ only at the end of the string and immediately before the newline (if any) at the end of the string. S DOTALL Make the . special character match any character at all, including a newline; without this flag, . will match anything except a newline. If you do a lot of working with regular expressions, then I highly recommend Kodos (http://kodos.sourceforge.net) as a tool for interactively figuring out issues. Cheers, Tony Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.5.1 broken os.stat module
On Jun 1, 9:16 am, Joe Salmeri [EMAIL PROTECTED] wrote: I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some unexpected behavior that appears to be a bug in the os.stat module. Have you read this thread? http://groups.google.com/group/comp.lang.python/browse_thread/thread/890eef2197c6f045/5466283a8253cafb?lnk=gstq=getmtimernum=3#5466283a8253cafb I suspect that it explains your problem. Cheers, Tony -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessing iTunes with Python via the Windows SDK
On May 24, 4:23 pm, Denrael [EMAIL PROTECTED] wrote: I've been playing with the iTunes sdk on windows, and have come across a strange problem. With the following code: import win32com.client iTunes = win32com.client.gencache.EnsureDispatch(iTunes.Application) curr = iTunes.CurrentTrack name = curr.Name skipped = curr.SkippedCount [...] I get an error indicating that SkippedCount isn't a valid attribute: [...] The object you get back from iTunes.CurrentTrack (the traceback shows this) is an IITTrack. If you check the iTunes SDK, you'll see that IITTrack objects don't have a SkippedCount attribute - IITFileOrCDTrack objects do (from memory, this excludes things like radio links). You need to conver the IITrack object to a IITFileOrCDTrack object (assuming that it is one); you can do this with win32com.client.CastTo, as follows: import win32com.client iTunes = win32com.client.gencache.EnsureDispatch(iTunes.Application) curr = win32com.client.CastTo(iTunes.CurrentTrack, IITFileOrCDTrack) name = curr.Name skipped = curr.SkippedCount skipdate = curr.SkippedDate print name print skipped print skipdate Cheers, Tony -- http://mail.python.org/mailman/listinfo/python-list
Re: getmtime differs between Py2.5 and Py2.4
On May 8, 10:15 am, Martin v. Löwis [EMAIL PROTECTED] wrote:
that you are mistaken: There is NO difference between the outcome
of os.path.getmtime between Py2.5 and Py2.4. It always did return
UTC, and always will.
In revision 42230, you checked in a change to posixmodule.c with the
following code comment:
/* The CRT of Windows has a number of flaws wrt. its stat()
implementation:
- time stamps are restricted to second resolution
- file modification times suffer from forth-and-back
conversions between
UTC and local time
Therefore, we implement our own stat, based on the Win32 API
directly.
*/
(See
http://svn.python.org/view/python/trunk/Modules/posixmodule.c?rev=42230view=log
)
Different results are indeed obtained, as others have demonstrated
(other than the irrelevant float/int distinction). The following C
sample program illustrates:
C:\a d:\temp.txt
Time modified : Thu Feb 08 10:08:44 2007
Time modified : 02/07/2007 22:08:44 UTC
Time modified : 02/08/2007 11:08:44 Local
C:\c:\python24\python -c import os;import time;print
time.ctime(os.path.getmtime('temp.txt'))
Thu Feb 08 10:08:44 2007
C:\c:\python25\python -c import os;import time;print
time.ctime(os.path.getmtime('temp.txt'))
Thu Feb 08 11:08:44 2007
(My local time is UTC-12).
This doesn't happen with every file:
C:\c:\python24\python -c import os;import time;print
time.ctime(os.path.getmtime('temp2.txt'))
Tue May 08 16:59:22 2007
C:\c:\python25\python -c import os;import time;print
time.ctime(os.path.getmtime('temp2.txt'))
Tue May 08 16:59:22 2007
C:\a d:\temp2.txt
Time modified : Tue May 08 16:59:22 2007
Time modified : 05/08/2007 04:59:22 UTC
Time modified : 05/08/2007 16:59:22 Local
A key fact here, I believe, is that in February (when temp.txt was
last modified), my local time was UTC-11. I expect this is the
suffering that your comment in posixmodule.c refers to (it looks to me
like Python 2.5 is correct).
Cheers,
Tony
---
#include time.h
#include sys/types.h
#include sys/stat.h
#include stdio.h
#include windows.h
int main( int argc, char **argv )
{
WIN32_FILE_ATTRIBUTE_DATA lpFileInformation;
SYSTEMTIME stUTC, stLocal;
struct __stat64 buf;
int result;
/* Python 2.4 style */
result = _stat64( argv[1], buf );
if( result != 0 )
perror( Problem getting information );
else
printf( Time modified : %s, _ctime64( buf.st_mtime ) );
/* Python 2.5+ */
GetFileAttributesEx(argv[1], GetFileExInfoStandard,
lpFileInformation);
FileTimeToSystemTime(lpFileInformation.ftLastWriteTime, stUTC);
printf(Time modified : %02d/%02d/%d %02d:%02d:%02d UTC\n,
stUTC.wMonth, stUTC.wDay, stUTC.wYear,
stUTC.wHour, stUTC.wMinute, stUTC.wSecond);
SystemTimeToTzSpecificLocalTime(NULL, stUTC, stLocal);
printf(Time modified : %02d/%02d/%d %02d:%02d:%02d Local\n,
stLocal.wMonth, stLocal.wDay, stLocal.wYear,
stLocal.wHour, stLocal.wMinute, stLocal.wSecond);
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to upgrade python from 2.4.3 to 2.4.4 ?
At the moment SourceForge is only listing one (UK) mirror for mingw, and that seems to be down. I'm guessing something is broken, since I know it used to be much more widely available. Only one mirror (Kent) is available for any project. It's been like this for nearly a day now, although the site status still hasn't changed from online. There are about 50 open tickets open about it (one would think that people that are able to find the sf.net tickets would be able to check for duplicates first...). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: howto py2exe/py2app for self updating application
I'm creating a GUI program with wxPython which will be distributed for Mac and Windows. [...] The program should be able to update itself [...] By default, py2exe puts all the .pyc files used in a zip file. The simplest way to do this it let py2exe do what it normally does. Code all of the .py files as you would when running from source (i.e. you'll never explicitly use zipimport). To update, you then: 1. Download the new .pyc files. 2. Expand (use ZipFile) the existing py2exe zip. 3. Replace the old .pyc files with the new ones. 4. Rezip (use ZipFile) the .pyc files. 5. Replace the old py2xe zip with the one containing the new files. 6. Restart the program. This works (I use a more sophisticated version of this) well with py2exe. I haven't used py2app at all, but if it works much like py2exe, then all of the above still applies (certainly the steps are platform-agnostic). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: email package 4.0a2
[Barry Warsaw] I'm happy to announce the release of the email 4.0a2 standalone package. [Konrad Hinsen] My interpretation of the above paragraph is that it will be impossible to write Python code using the email module (and possibly other evolving modules) that works with both Python 2.4 and Python 2.6. No, that's not correct. try: from email import message except ImportError: # Compat with 2.4 and earlier from email import Message as message (etc) Note also that 2.5 won't be out until late this year; 2.6 will probably be something like mid 2008. That's a long time after 2.4 (or 2.3, or 2.2). If you want to support something like 10 years of versions, there will be difficulties doing that. You can always bundle up the email package separately (this is extremely easy), however, so that users have email 4.0 and Python 2.2. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2006-01-01 through 2006-01-15
to specify the order through an ordered dictionary. Guido explained that he didn't feel that it mattered, as long as the patch also allows comments to be preserved; his preference was for everything (ordering, blank lines, and comments) to be preserved. Tony Meyer point out some examples_ of previous_ `python-dev discussion`_ about how ConfigParser should be modified, and that SpamBayes_ includes a ConfigParser subclass that allows 'surgical' editing of files. .. _submitted a patch: http://python.org/sf/1399309 .. _another open patch: http://python.org/sf/1371075 .. _previous: http://mail.python.org/pipermail/python-dev/2004-October/049454.html .. _python-dev discussion: http://mail.python.org/pipermail/python-dev/2004-October/049527.html .. _examples: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518 .. _SpamBayes: http://spambayes.org Contributing thread: - `ConfigParser to save with order http://mail.python.org/pipermail/python-dev/2006-January/059480.html`__ [TAM] --- Patches for the logging package --- Shane Hathaway asked about the process for submitting patches for the logging package. Vinay Sajip is the primary maintainer, and accepts patches (compatible with Python 1.5.2) through sourceforge as normal, though personal emails are appropriate if you are worried about spending time on a patch that is not accepted. There was a brief followup discussion about how to get the logging package to interact nicely with external log rotation tools, including the possible creation of a ``reopen()`` function for files, but the thread trailed off without any solid conclusion on this issue. Contributing thread: - `Logging enhancements http://mail.python.org/pipermail/python-dev/2006-January/059566.html`__ [SJB] -- os.path.getmtime() bugs on Windows -- Christian Tismer noted that if, in a single interactive session on Windows, create a file, get its os.path.getmtime(), change your time zone, and get its os.path.getmtime() again, the time stamps are different. He asked whether there was a way to circumvent the problem, or if a patch could be created. Tim Peters gave him a `reference to a CodeProject page` that discusses the problem. Martin v. Löwis has meant to work on a patch for several years; his plan is to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly - this would also have the advantage that subsecond time-stamps can be exposed. This patch would need to be implemented twice; once for Win9X (ANSI file names) and once for NT+ (unicode file names). .. _reference to a CodeProject page: http://www.codeproject.com/datetime/dstbugs.asp Contributing thread: - `os.path.getmtime on Windows http://mail.python.org/pipermail/python-dev/2006-January/059741.html`__ [TAM] Generating Python-ast.c and Python-ast.h Python-ast.c and Python-ast.h are generated automatically from Parser/asdl_c.py and then checked into Subversion. However, a ``make distclean`` removes these files, and if you do not have a 2.2+ version of Python available, they cannot be regenerated. The best solution seemed to be to alter ``make distclean`` to not remove Python-ast.c and Python-ast.h as they only need to be regenerated when the AST definition changes, which is rather infrequent. Contributing thread: - `[Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c http://mail.python.org/pipermail/python-dev/2006-January/059356.html`__ [SJB] - Allowing dict subclasses for exec globals - Currently, the ``exec`` statement allows the locals expression (the second expression after ``in``) to be any mapping type. The globals expression (the first expression after ``in``) should be a dict object, but Python does not currently raise an exception if you use a dict subclass, though it will not call any overridden methods correctly. `Crutcher Dunnavant presented a patch`_ that allows the globals expression to be a dictionary subclass such that overridden methods are called properly. Because it gives Python new capabilities, if the patch is accepted, it will not become part of Python until 2.5. .. _Crutcher Dunnavant presented a patch: http://www.python.org/sf/1402289 Contributing thread: - `[PATCH] Fix dictionary subclass semantics when used as global dictionaries http://mail.python.org/pipermail/python-dev/2006-January/059625.html`__ [SJB] -- Finding an appropriate recursion limit -- Python limits the depth of the function call stack. Too low a limit, and some functions fail needlessly. Too high a limit, and some programs get a segmentation fault instead of an exception. There is no easy
python-dev Summary for 2006-01-01 through 2006-01-15
to specify the order through an ordered dictionary. Guido explained that he didn't feel that it mattered, as long as the patch also allows comments to be preserved; his preference was for everything (ordering, blank lines, and comments) to be preserved. Tony Meyer point out some examples_ of previous_ `python-dev discussion`_ about how ConfigParser should be modified, and that SpamBayes_ includes a ConfigParser subclass that allows 'surgical' editing of files. .. _submitted a patch: http://python.org/sf/1399309 .. _another open patch: http://python.org/sf/1371075 .. _previous: http://mail.python.org/pipermail/python-dev/2004-October/049454.html .. _python-dev discussion: http://mail.python.org/pipermail/python-dev/2004-October/049527.html .. _examples: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518 .. _SpamBayes: http://spambayes.org Contributing thread: - `ConfigParser to save with order http://mail.python.org/pipermail/python-dev/2006-January/059480.html`__ [TAM] --- Patches for the logging package --- Shane Hathaway asked about the process for submitting patches for the logging package. Vinay Sajip is the primary maintainer, and accepts patches (compatible with Python 1.5.2) through sourceforge as normal, though personal emails are appropriate if you are worried about spending time on a patch that is not accepted. There was a brief followup discussion about how to get the logging package to interact nicely with external log rotation tools, including the possible creation of a ``reopen()`` function for files, but the thread trailed off without any solid conclusion on this issue. Contributing thread: - `Logging enhancements http://mail.python.org/pipermail/python-dev/2006-January/059566.html`__ [SJB] -- os.path.getmtime() bugs on Windows -- Christian Tismer noted that if, in a single interactive session on Windows, create a file, get its os.path.getmtime(), change your time zone, and get its os.path.getmtime() again, the time stamps are different. He asked whether there was a way to circumvent the problem, or if a patch could be created. Tim Peters gave him a `reference to a CodeProject page` that discusses the problem. Martin v. Löwis has meant to work on a patch for several years; his plan is to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly - this would also have the advantage that subsecond time-stamps can be exposed. This patch would need to be implemented twice; once for Win9X (ANSI file names) and once for NT+ (unicode file names). .. _reference to a CodeProject page: http://www.codeproject.com/datetime/dstbugs.asp Contributing thread: - `os.path.getmtime on Windows http://mail.python.org/pipermail/python-dev/2006-January/059741.html`__ [TAM] Generating Python-ast.c and Python-ast.h Python-ast.c and Python-ast.h are generated automatically from Parser/asdl_c.py and then checked into Subversion. However, a ``make distclean`` removes these files, and if you do not have a 2.2+ version of Python available, they cannot be regenerated. The best solution seemed to be to alter ``make distclean`` to not remove Python-ast.c and Python-ast.h as they only need to be regenerated when the AST definition changes, which is rather infrequent. Contributing thread: - `[Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c http://mail.python.org/pipermail/python-dev/2006-January/059356.html`__ [SJB] - Allowing dict subclasses for exec globals - Currently, the ``exec`` statement allows the locals expression (the second expression after ``in``) to be any mapping type. The globals expression (the first expression after ``in``) should be a dict object, but Python does not currently raise an exception if you use a dict subclass, though it will not call any overridden methods correctly. `Crutcher Dunnavant presented a patch`_ that allows the globals expression to be a dictionary subclass such that overridden methods are called properly. Because it gives Python new capabilities, if the patch is accepted, it will not become part of Python until 2.5. .. _Crutcher Dunnavant presented a patch: http://www.python.org/sf/1402289 Contributing thread: - `[PATCH] Fix dictionary subclass semantics when used as global dictionaries http://mail.python.org/pipermail/python-dev/2006-January/059625.html`__ [SJB] -- Finding an appropriate recursion limit -- Python limits the depth of the function call stack. Too low a limit, and some functions fail needlessly. Too high a limit, and some programs get a segmentation fault instead of an exception. There is no easy
Re: beta.python.org content
- The logo does indeed resemble a cross. How about rotating it at 45 deg to make it look like an x? Or give it a circular shape? Please note that there are no religious motives in this remark :) -1. Then what are the motives? A rotated cross looks a lot less clean. Take a look at the crosses at http://en.wikipedia.org/wiki/ Cross - the only ones it vaguely resembles are the Greek cross and the Red Cross. It certainly doesn't resemble the Christian (longer upright section) cross, and as the article says, the cross is one of the oldest symbols in existance. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website?
But sheesh, if I objected to every picture of the moon I see (or pictures that vaguely resemble a moon), I would be in a very sad state. But you see Terry, the point is not that it is just a picture. And let's not forget that as far as we know the moon has always been a natural part of all human life on this earth before and after Islam, and even for those who never heard of Islam. And so the moon is not a Muslim monopoly. Perhaps you're not aware of this, but the 'plus' shape existed before Christianity, too. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-12-01 through 2005-12-15
/058817.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from December 01, 2005 through December 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 9th summary written by the python-dev summary gathering of Steve Bethard and Tony Meyer (more on its way). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-11-01_2005-11-15.html .. _original text file: http://www.python.org/dev/summary/2005-12-01_2005-12-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
python-dev Summary for 2005-12-16 through 2005-12-31
/2005-December/058923.html`__ [Jim Jewett] - Local socket timeouts - If you want your network client to eventually give up on failed connections, you need to set a timeout - but you have to do that at the socket level, instead of in the library that you're actually using. (There are other problems with the current method too, such as being too global, or not quite acting as expected.) It was agreed that people should be able to handle timeout settings from the networking library that they actually use, but I don't think there are patches yet. Contributing thread: - `timeout options in high-level networking modules http://mail.python.org/pipermail/python-dev/2005-December/058996.html`__ [Jim Jewett] Deferred Threads - `Build failure and problem on Windows http://mail.python.org/pipermail/python-dev/2005-December/058918.html`__ === Skipped Threads === - `PEP 8 updates/clarifications, function/method style http://mail.python.org/pipermail/python-dev/2005-December/058835.html`__ - `DRAFT: python-dev summary for 2005-11-16 to 2005-11-31 http://mail.python.org/pipermail/python-dev/2005-December/058869.html`__ - `[Python-checkins] commit of r41497 -python/trunk/Lib/test http://mail.python.org/pipermail/python-dev/2005-December/058871.html`__ - `fresh checkout won't build http://mail.python.org/pipermail/python-dev/2005-December/058876.html`__ - `fixing log messages http://mail.python.org/pipermail/python-dev/2005-December/058883.html`__ - `(no subject) http://mail.python.org/pipermail/python-dev/2005-December/058916.html`__ - `os.startfile with optional second parameter http://mail.python.org/pipermail/python-dev/2005-December/058919.html`__ - `[OT] Fwd: a new python port: iPod http://mail.python.org/pipermail/python-dev/2005-December/058920.html`__ - `Patch to make unittest.TestCase easier to subclass http://mail.python.org/pipermail/python-dev/2005-December/058995.html`__ - `Patch reviews amp; request for patch review http://mail.python.org/pipermail/python-dev/2005-December/059027.html`__ - `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-December/059031.html`__ - `A few questions about setobject http://mail.python.org/pipermail/python-dev/2005-December/059091.html`__ - `Small any/all enhancement http://mail.python.org/pipermail/python-dev/2005-December/059127.html`__ - `floating point literals don't work in non-US locale in 2.5 http://mail.python.org/pipermail/python-dev/2005-December/059176.html`__ - `JOB OPENING: Implementor for Python and Search http://mail.python.org/pipermail/python-dev/2005-December/059183.html`__ - `PyCon TX 2006: Early-bird registration ends Dec. 31! http://mail.python.org/pipermail/python-dev/2005-December/059195.html`__ - `set.copy documentation string http://mail.python.org/pipermail/python-dev/2005-December/059222.html`__ - `Bug in Py_InitModule4 http://mail.python.org/pipermail/python-dev/2005-December/059272.html`__ - `floating point literals don't work in non-USlocale in 2.5 http://mail.python.org/pipermail/python-dev/2005-December/059290.html`__ - `slight inconsistency in svn checkin email subject lines http://mail.python.org/pipermail/python-dev/2005-December/059335.html`__ - `Gaming on Sunday (Jan 1) http://mail.python.org/pipermail/python-dev/2005-December/059339.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from December 16, 2005 through December 31, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 10th summary written by the python-dev summary duopoly of Steve Bethard and Tony Meyer (back to back!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev
python-dev Summary for 2005-12-01 through 2005-12-15
/058817.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from December 01, 2005 through December 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 9th summary written by the python-dev summary gathering of Steve Bethard and Tony Meyer (more on its way). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-11-01_2005-11-15.html .. _original text file: http://www.python.org/dev/summary/2005-12-01_2005-12-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -- http://mail.python.org/mailman/listinfo/python-list
Re: another docs problem - imp
[EMAIL PROTECTED] Another Python docs problem... I was trying to use imp.find_module(). [...] I saw not a hint of this in the docs. In fact they seem to say that the first (unworking) form *should* work. Bye bye about two hours altogether... I thought I would post this and hopefully help someone else in the future (since I noticed an unanswered posting here from Mar 2005 about the same problem.) Why not submit a bug report/patch for the documentation? Documentation patches are fine in plain text (the maintainers will take care of the necessary markup) and a submitted report will get attended to, even it if takes a while - a post here is more-than- likely to be missed by those that maintain the documentation. It would take about the same amount of time as a post... =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-11-16 through 2005-11-30
for 2005-09-16 to 2005-09-30 http://mail.python.org/pipermail/python-dev/2005-November/058178.html`__ - `DRAFT: python-dev Summary for 2005-10-01 to 2005-10-15 http://mail.python.org/pipermail/python-dev/2005-November/058179.html`__ - `DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31 http://mail.python.org/pipermail/python-dev/2005-November/058180.html`__ - `Coroutines (PEP 342) http://mail.python.org/pipermail/python-dev/2005-November/058192.html`__ - `Enjoy a week without me http://mail.python.org/pipermail/python-dev/2005-November/058209.html`__ - `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-November/058210.html`__ - `How to stay almost backwards compatible with all these new cool features http://mail.python.org/pipermail/python-dev/2005-November/058211.html`__ - `test_cmd_line on Windows http://mail.python.org/pipermail/python-dev/2005-November/058271.html`__ - `Fwd: [Python-checkins] commit of r41497 - python/trunk/Lib/test http://mail.python.org/pipermail/python-dev/2005-November/058272.html`__ - `[Python-checkins] commit of r41497 -python/trunk/Lib/test http://mail.python.org/pipermail/python-dev/2005-November/058275.html`__ - `DRAFT: python-dev Summary for 2005-11-01 through 2005-11-15 http://mail.python.org/pipermail/python-dev/2005-November/058281.html`__ - `something is wrong with test___all__ http://mail.python.org/pipermail/python-dev/2005-November/058292.html`__ - `PEP 302, PEP 338 and imp.getloader (was Re: a Python interface for the AST (WAS: DRAFT: python-dev...) http://mail.python.org/pipermail/python-dev/2005-November/058300.html`__ - `registering unicode codecs http://mail.python.org/pipermail/python-dev/2005-November/058324.html`__ - `reference leaks http://mail.python.org/pipermail/python-dev/2005-November/058330.html`__ - `Bug bz2.BZ2File(...).seek(0,2) + patch http://mail.python.org/pipermail/python-dev/2005-November/058334.html`__ - `Python 3 http://mail.python.org/pipermail/python-dev/2005-November/058346.html`__ - `For Python 3k, drop default/implicit hash, and comparison http://mail.python.org/pipermail/python-dev/2005-November/058349.html`__ - `Bug day this Sunday? http://mail.python.org/pipermail/python-dev/2005-November/058367.html`__ - `Short-circuiting iterators http://mail.python.org/pipermail/python-dev/2005-November/058423.html`__ - `Standalone email package in the sandbox http://mail.python.org/pipermail/python-dev/2005-November/058431.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from November 16, 2005 through November 30, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 8th summary written by the python-dev summary contingent of Steve Bethard and Tony Meyer (happy holidays!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)
Well, I was running Python-2.4.1 so I upgraded to 2.4.2 and guess what? The docs still reference the old Howto. Perhaps you meant to say will be fixed in 2.5 rather than has been fixed? No, I meant has been fixed. A fixed version hasn't been released, but that doesn't make it any less fixed. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)
Among the treasures available in The Wiki is the current copy of the Sorting min-howto: http://www.amk.ca/python/howto/sorting/sorting.html Why is this a treasure when it is way out of date? Note that the updated version of this is at: http://wiki.python.org/ moin/HowTo/Sorting =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)
Among the treasures available in The Wiki is the current copy of the Sorting min-howto: http://www.amk.ca/python/howto/sorting/sorting.html Why is this a treasure when it is way out of date? Note that the updated version of this is at: http://wiki.python.org/ moin/HowTo/Sorting http://wiki.python.org/... Read the message more carefully. Mail wrapped the URL - if you put it back together, it'll be there. To make it easy, try: http://wiki.python.org/moin/HowTo/Sorting http://tinyurl.com/bkwf7 [...] Maybe I should Goole python.org What was the google syntax to limit the search to one site? I forgot. It's site:, but even if you just left that out and used 'wiki.python.org sorting how to', the first link is the one you're after. Laziness is no excuse. Wikis suck. Update the damn docs. The documentation *has* been updated. If you read the Python 2.5 documentation (build it, or wait for Python 2.5 to be released), you'll see that it points to the Wiki. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)
It's site:, but even if you just left that out and used 'wiki.python.org sorting how to', the first link is the one you're after. Laziness is no excuse. You miss my point. Having outdated documentaion distributed with Python is the problem. Have some newer stuff out on some wiki is nice but does not fix the problem. I know people don't like writing and updating docs. But that doesn't turn bad documentation in good. Wikis suck. Update the damn docs. The documentation *has* been updated. If you read the Python 2.5 documentation (build it, or wait for Python 2.5 to be released), you'll see that it points to the Wiki. You're complaining about something that has been fixed. The documentation was out of date, and that has been corrected. If you really must complain about something (in the interests of a foolish 'balance'), then pick something that hasn't been fixed. Note that having the core information in the documentation and additional information like how-tos in a wiki means that keeping it up-to-date isn't tied to a release. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Bitching about the documentation...
But, the standard responce of don't complain, fix it yourself is bogus too. There are plenty of people on this list willing to sing python's praises, for balance, there should be people willing to openly point out python's flaws. This makes no sense. If you want to complain about Python, try a Perl list. Why would a list dedicated to discussion about/help with a language need complaints about the language? You might want to consider the difference between complaining and constructive criticism and suggestions, and which are likely to get better responses. Documentation is certainly one of them. FWIW, I have found Python's documentation to generally be excellent. And I was correcting a posting that explicitly said there was exceptionaly good information in that Howto. That was just plain wrong. It is exceptionally good information. The version that was at that link is somewhat dated (but still excellent for anyone using older versions of Python, or for those that need to remain compatible with older versions, and there are a lot of those people around), but the updated version is also excellent. I'm sure amk will either update his page to point to the new one or update the content at some point. The point is that you're much more likely to improve things if you politely point out a problem and suggest a solution than simply make a complaint. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
os.rename copies when old is in-use - is this deliberate?
On Windows, if I do os.rename(old, new) where old is a file that is in-use (e.g. python itself, or a dll that is loaded), I would expect that an error would be raised (e.g. as when os.remove is called with an in-use file). However, what happens is that a copy of the file is made, and the old file still exists. For example: C:\c:\python24\python.exe Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os import sys sys.executable 'c:\\python24\\python.exe' os.rename(sys.executable, d:\\python24.exe) ^Z D:\dir c:\python24\p*.exe Volume in drive C is ACER Volume Serial Number is 320D-180E Directory of c:\python24 28/09/2005 12:41 p.m. 4,608 python.exe 28/09/2005 12:41 p.m. 5,120 pythonw.exe 2 File(s) 9,728 bytes 0 Dir(s) 16,018,685,952 bytes free C:\dir d:\p*24.exe Volume in drive D is DATA Volume Serial Number is 4019-78E0 Directory of d:\ 28/09/2005 12:41 p.m. 4,608 python24.exe 1 File(s) 4,608 bytes 0 Dir(s) 15,362,207,744 bytes free Is this the intended behaviour? The documentation doesn't give any indication that it is (so unless I'm missing something, this is at least a documentation bug). Any insight appreciated :) (I do know that I can work around it by doing a remove after the rename, if the file exists). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: os.rename copies when old is in-use - is this deliberate?
[Tony Meyer] Is this the intended behaviour? [Martin v. Löwis] Sort-of. os.rename invokes the C library's rename, and does whatever this does. It is expected that most platform's C libraries do what the documentation says rename does, but platforms may vary in their implementation of the C library, and from one compiler version to the other. [snip links to Microsoft documentation, which don't cover the in-use case] Thanks for that. In your opinion, would a documentation patch that explained that this would occur on Windows (after the existing note about the Windows rename not being atomic) be acceptable? (The Windows platform C library for Python 2.4+ is in msvcrt71.dll, right? Does that mean that behaviour will be consistent across Windows versions, or could 9x/NT/XP/etc all behave differently?) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-10-01 through 2005-10-15
:- `Why does __getitem__ slot of builtin call sequence methods first? http://mail.python.org/pipermail/python-dev/2005-October/056901.html `__[SJB]Deferred Threads- `Early PEP draft (For Python 3000?) http://mail.python.org/pipermail/python-dev/2005-October/057251.html `__- `Pythonic concurrency - offtopic http://mail.python.org/pipermail/python-dev/2005-October/057294.html`__=== Skipped Threads===- `PEP 350: Codetags http://mail.python.org/pipermail/python-dev/2005-October/056894.html `__- `Active Objects in Python http://mail.python.org/pipermail/python-dev/2005-October/056896.html`__- `IDLE development http://mail.python.org/pipermail/python-dev/2005-October/056907.html`__- `Help needed with MSI permissions http://mail.python.org/pipermail/python-dev/2005-October/056908.html`__- `C API doc fix http://mail.python.org/pipermail/python-dev/2005-October/056910.html `__- `Static builds on Windows (continued) http://mail.python.org/pipermail/python-dev/2005-October/056976.html`__ - `Removing the block stack (was Re: PEP 343 and __with__) http://mail.python.org/pipermail/python-dev/2005-October/057001.html`__ - `Removing the block stack http://mail.python.org/pipermail/python-dev/2005-October/057008.html`__- `Lexical analysis and NEWLINE tokens http://mail.python.org/pipermail/python-dev/2005-October/057014.html`__- `PyObject_Init documentation http://mail.python.org/pipermail/python-dev/2005-October/057039.html`__- `Sourceforge CVS access http://mail.python.org/pipermail/python-dev/2005-October/057051.html `__- `__doc__ behavior in class definitions http://mail.python.org/pipermail/python-dev/2005-October/057066.html`__ - `Sandboxed Threads in Python http://mail.python.org/pipermail/python-dev/2005-October/057082.html`__- `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-October/057092.html`__- `test_cmd_line failure on Kubuntu 5.10 with GCC 4.0 http://mail.python.org/pipermail/python-dev/2005-October/057094.html`__- `defaultproperty (was: Re: RFC: readproperty) http://mail.python.org/pipermail/python-dev/2005-October/057120.html `__- `async IO and helper threads http://mail.python.org/pipermail/python-dev/2005-October/057121.html`__- `defaultproperty http://mail.python.org/pipermail/python-dev/2005-October/057129.html`__- `Fwd: defaultproperty http://mail.python.org/pipermail/python-dev/2005-October/057131.html`__- `C.E.R. Thoughts http://mail.python.org/pipermail/python-dev/2005-October/057137.html `__- `problem with genexp http://mail.python.org/pipermail/python-dev/2005-October/057175.html`__- `Python-Dev Digest, Vol 27, Issue 44 http://mail.python.org/pipermail/python-dev/2005-October/057207.html`__- `Europeans attention please! http://mail.python.org/pipermail/python-dev/2005-October/057233.html`__EpilogueThis is a summary of traffic on the `python-dev mailing list`_ fromOctober 01, 2005 through October 15, 2005. It is intended to inform the wider Python community of on-goingdevelopments on the list on a semi-monthly basis. An archive_ ofprevious summaries is available online.An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce fornew summaries (or through their email gateways of python-list orpython-announce, respectively, as found at http://mail.python.org).This is the 5th summary written by the python-dev summary taskforce ofSteve Bethard and Tony Meyer (thanks Steve!).To contact us, please send email:- Steve Bethard ( steven.bethard at gmail.com)- Tony Meyer (tony.meyer at gmail.com)Do *not* post to comp.lang.python if you wish to reach us.The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summaryhelpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even asmall donation with a credit card, check, or by PayPal helps. Commenting on TopicsTo comment on anything mentioned here, just post to`comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you arediscussing. All python-dev members are interested in seeing ideasdiscussed by the community, so don't hesitate to take a stance onsomething. And if all of this really interests you then get involved and join `python-dev`_!-How to Read the Summaries-The in-development version of the documentation for Python can befound at http://www.python.org/dev/doc/devel/ and should be used whenlooking up any documentation for new code; otherwise use the currentdocumentation as found at http://docs.python.org/ . PEPs (PythonEnhancement Proposals) are located at http://www.python.org/peps/ .To view files
python-dev Summary for 2005-09-01 to 2005-09-15
`__ - `Wanting to learn http://mail.python.org/pipermail/python-dev/2005- September/056350.html`__ - `Python code.interact() and UTF-8 locale http://mail.python.org/ pipermail/python-dev/2005-September/056361.html`__ - `pygettext() without newlines (Was: Re: Replacement for print in Python 3.0) http://mail.python.org/pipermail/python-dev/2005- September/056368.html`__ - `Python 3 executable name (was: Re: PEP 3000 and iterators) http:// mail.python.org/pipermail/python-dev/2005-September/056369.html`__ - `Python 3 executable name http://mail.python.org/pipermail/python- dev/2005-September/056371.html`__ - `Skiping searching throw dictionaries of mro() members. http:// mail.python.org/pipermail/python-dev/2005-September/056403.html`__ - `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 http://mail.python.org/pipermail/python-dev/2005- September/056405.html`__ - `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3 http://mail.python.org/pipermail/ python-dev/2005-September/056406.html`__ - `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 http:// mail.python.org/pipermail/python-dev/2005-September/056419.html`__ - `Variant of removing GIL. http://mail.python.org/pipermail/python- dev/2005-September/056423.html`__ - `Compatibility between Python 2.3.x and Python 2.4.x http:// mail.python.org/pipermail/python-dev/2005-September/056431.html`__ - `Example for property violates Python is not a one pass compiler http://mail.python.org/pipermail/python-dev/2005-September/ 056190.html`__ - `python optimization http://mail.python.org/pipermail/python-dev/ 2005-September/056425.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2005 through September 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 3rd summary written by the python-dev summary pairing of Steve Bethard and Tony Meyer (Tempus Fugit!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/ python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org
python-dev Summary for 2005-09-01 to 2005-09-15
`__ - `Wanting to learn http://mail.python.org/pipermail/python-dev/2005- September/056350.html`__ - `Python code.interact() and UTF-8 locale http://mail.python.org/ pipermail/python-dev/2005-September/056361.html`__ - `pygettext() without newlines (Was: Re: Replacement for print in Python 3.0) http://mail.python.org/pipermail/python-dev/2005- September/056368.html`__ - `Python 3 executable name (was: Re: PEP 3000 and iterators) http:// mail.python.org/pipermail/python-dev/2005-September/056369.html`__ - `Python 3 executable name http://mail.python.org/pipermail/python- dev/2005-September/056371.html`__ - `Skiping searching throw dictionaries of mro() members. http:// mail.python.org/pipermail/python-dev/2005-September/056403.html`__ - `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 http://mail.python.org/pipermail/python-dev/2005- September/056405.html`__ - `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3 http://mail.python.org/pipermail/ python-dev/2005-September/056406.html`__ - `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 http:// mail.python.org/pipermail/python-dev/2005-September/056419.html`__ - `Variant of removing GIL. http://mail.python.org/pipermail/python- dev/2005-September/056423.html`__ - `Compatibility between Python 2.3.x and Python 2.4.x http:// mail.python.org/pipermail/python-dev/2005-September/056431.html`__ - `Example for property violates Python is not a one pass compiler http://mail.python.org/pipermail/python-dev/2005-September/ 056190.html`__ - `python optimization http://mail.python.org/pipermail/python-dev/ 2005-September/056425.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2005 through September 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 3rd summary written by the python-dev summary pairing of Steve Bethard and Tony Meyer (Tempus Fugit!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/ python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org
Re: [OT] Re: output from external commands
On 25/10/2005, at 3:36 PM, Steven Bethard wrote: I wouldn't fret too much about a sharp remark from Fredrik Lundh. They're pretty much all that way. ;) [...] It takes a little training to get used to him, but if you can look past the nasty bite, he's really a valuable resource around here. +1 QOTW :) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: A Moronicity of Guido van Rossum
On 30/09/2005, at 10:56 PM, Gerrit Holl wrote: Tony Meyer wrote: X-Spambayes-Classification: ham; 0.048 X-Spambayes-Evidence: '*H*': 0.90; '*S*': 0.00; 'bug.': 0.07; 'flagged': 0.07; i'd: 0.08; 'bayes': 0.09; 'from:addr:ihug.co.nz': 0.09; 'really,': 0.09; 'cc:no real name:2**0': 0.14; 'from:addr:t-meyer': 0.16; 'from:name:tony meyer': 0.16; 'obvious,': 0.16; 'spambayes': 0.16; 'subject:Guido': 0.16; 'trolling,': 0.16; 'regret': 0.82; 'lee,': 0.91; 'viagra': 0.91; 'mailings': 0.93; 'probability': 0.93 This is a feature, not a bug. It's the same feature that means that messages talking about spam on the spambayes mailing list, or the legitimate mail I get about viagra wink, get through to me. True. However, most mail to this mailinglist has less than 0.001 spam probability. As you can see, this one had 0.048 - a vast score, almost enough to put it in my unsure box. It seems to be just not hammy enough. It's interesting to see that no none of the foul language words used by Xah Lee ever occurs in any spam I receive - spam is not that stupid. Unless I'm misreading things, that's *my* message that scored 0.048 (the from:addr:ihug.co.nz, from:name:tony meyer, and spambayes tokens make it seem that way)... =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: A Moronicity of Guido van Rossum
On 30/09/2005, at 9:50 AM, Delaney, Timothy (Tim) wrote: You have to admit though, he's remarkably good at getting past Spambayes. Despite classifying *every* Xah Lee post as spam, he still manages to get most of his posts classified as 0% or 1% spam. I can't believe that people are using c.l.p trolls as justification in their push to add white/black-listing to spambayes now wink. I expect that if you look at the clues for such messages, you'll find that any 'Xah Lee' clues are swamped by lots of 'c.l.p message' clues. A big problem with filtering mailing lists at the user end (rather than before the post is accepted) is that the mailing software adds so many strongly-correlated clues. It's made worse because he uses so many words that you'd expect to find in legitimate c.l.p messages. To fight this sort of message, I think spambayes would have to be able to understand the context more. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: A Moronicity of Guido van Rossum
I know nobody wants to do add white/black-listing, so we can do it probabilistically. In case it is not obvious, mailings with the words jargon or moron and their derrivatives should be flagged as 99.9% probability for Moronicity Xha Lee, Jargonizer, spam. If spam bayes can't figure this out, then either it is not properly implemented or Bayes himself was out to lunch. I knew I'd regret my response wink. The problem here isn't getting an appropriately spammy score for particular tokens, like Xah's name. The problem is that the classifier has to taken into account the entire message, and the hammy clues outweigh the spammy ones (not unexpected, really, considering that other than all the trolling, the messages are reasonably on-topic). This is a feature, not a bug. It's the same feature that means that messages talking about spam on the spambayes mailing list, or the legitimate mail I get about viagra wink, get through to me. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
On 28/09/2005, at 11:05 PM, Simon Brunning wrote: On 9/28/05, could ildg [EMAIL PROTECTED] wrote: Python is wonderful except that it has no real private and protected properties and methods. Every py object has dict so that you can easily find what fields and methods an obj has, this is very convenient, but because of this, py is very hard to support real private and protected? My convention, attributes with names prefixed with a single underscore are private. There's nothing to stop anyone using these, but, well, if you take the back off the radio, the warranty is void. I'm not sure why I haven't seen this mentioned yet, but a leading double-underscore does really make a member private: class f(object): ... def __init__(self): ... self.__f = 1 ... a = f() a.__f Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'f' object has no attribute '__f' dir(a) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', '_f__f'] As you see, it's there in the dict, but it's obfuscated - but that's all that other languages do anyway. Anyone that takes advantage of that to get hold of members like this should have a very good reason for doing so. Just think of a single leading underscore as protected, and double leading underscores as private, and you'll be fine. As Simon said, people can still access these, but the consenting adults rule applies. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
On 28/09/2005, at 11:54 PM, Paul Rubin wrote: Tony Meyer [EMAIL PROTECTED] writes: I'm not sure why I haven't seen this mentioned yet, but a leading double-underscore does really make a member private:... As you see, it's there in the dict, but it's obfuscated - but that's all that other languages do anyway. No, that's false: [snip] I didn't say *all* other languages, and I meant many other languages, although that's not clear from what I wrote. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
On 28/09/2005, at 11:55 PM, Simon Brunning wrote: On 9/28/05, Tony Meyer [EMAIL PROTECTED] wrote: I'm not sure why I haven't seen this mentioned yet, but a leading double-underscore does really make a member private: I thought about it, but I didn't mention it in the end because this feature (name mangling) isn't intended as a mechanism for making things private - it's intended to prevent namespace clashes when doing multiple inheritance. That's not what the documentation says: 9.6 Private Variables There is limited support for class-private identifiers. [...] Name mangling is intended to give classes an easy way to define ``private'' instance variables and methods, [...] http://docs.python.org/tut/node11.html =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: Will python never intend to support private, protected and public?
On 29/09/2005, at 3:45 AM, Fredrik Lundh wrote: Tony Meyer wrote: I thought about it, but I didn't mention it in the end because this feature (name mangling) isn't intended as a mechanism for making things private - it's intended to prevent namespace clashes when doing multiple inheritance. There is limited support for class-private identifiers. [...] Name mangling is intended to give classes an easy way to define ``private'' instance variables and methods, [...] the sentence you're quoting the first part of continues: without having to worry about instance variables defined by derived classes That elaborates on the intent, it doesn't change it. The sentence clearly says that the intent is to easily define private variables, whereas Simon said that it the intent was not to provide a mechanism for making variables private. and the paragraph later says: Note that the mangling rules are designed mostly to avoid accidents That's explaining why you can still access the variables if you want to, not saying that this feature isn't meant to be used to indicate that a variable is private. and both sentences are from the *tutorial*, which doesn't exactly qualify as a design document. A tutorial should not encourage users to use a feature in the wrong way, though. If leading underscore(s) were not meant to indicate privateness, then the tutorial should not state that - this is where a large proportion of users learn Python; it's nonsensical to teach them something that's incorrect. if you want more rationale, here's the post that led to the current design: http://groups.google.com/group/comp.lang.python/msg/e79f875059d9a2ba In my version, private data has it's own scope, so that name clashes will not occur if a private with the same name is used in a subclass. see the rest of that thread for more about the history of __. Disagreeing with someone who actually took part in the discussion may not be a sensible idea but... It's pretty clear to me from that thread that using a single/double underscore with variables *is* intended to indicate that the variable is private in some fashion. As Guido pointed out: '*leading* underscore has a long tradition (in the C world, anyway, but we don't really want to ignore that here) of meaning internal use (of some kind)' http://groups.google.com/group/comp.lang.python/msg/edecfde2141f642b The name mangling lets one use private variables without having to worry about name clashes, but the purpose of the leading underscore (s) is to indicate that the variable is private private seems to be useful because it offers a form of data hiding that's currently absent in Python http://groups.google.com/group/comp.lang.python/msg/593533b57662438f as many people in that thread indicated that they were doing before this was proposed as an addition. The OP wanted to know how to use private (and protected) variables in Python. Even the FAQ has this answer: 'Variables with double leading underscore are mangled to provide a simple but effective way to define class private variables. [...] This doesn't guarantee privacy: an outside user can still deliberately access the _classname__spam attribute, and private values are visible in the object's __dict__. http://www.python.org/doc/faq/programming.html#i-try-to-use-spam-and- i-get-an-error-about-someclassname-spam Which is basically what I said in my reply to the OP. If this isn't the intent, then there's a lot of incorrect documentation, and a lot of incorrect c.l.p answers to this question in the past*. =Tony.Meyer * Well, there are no doubt a lot of incorrect c.l.p answers to any question :). But anyway... -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 350: Codetags
On 27/09/2005, at 12:21 PM, Paul Rubin wrote: Neil Hodgson [EMAIL PROTECTED] writes: The PEP system allows for the documentation of a convention as an Informational PEP. Documenting conventions is useful. If the preferred method of doing something is consistent enough that it can be codified as a convention in a PEP, it should be implemented in the compiler, so it becomes a language feature, not a convention. Does this mean that you think that PEP 8 (Python Code Style Guide) should be enforced by the compiler? So that (e.g) lines that are too long just don't compile? I really doubt you'll find much agreement for this (the compiler should enforce it) position. The 'fewer conventions are better' position might enjoy more support, but doesn't strike me as particularly Pythonic (e.g. compare whitespace in Python and C). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: py2app without a mac?
I don't want to require the users to have python installed so I don't think distutils would work here. Recent versions of OS X include Python - there's a pretty good chance that the users have Python already, so you could possibly use distutils after all. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: To the python-list moderator
What still puzzles me is why the spamblocker that embargoed me and others did not catch such obvious spam as Subject: Re: The penis is way too delicate for masturbation (and occasional others like this). I know nothing about how spambayes is setup for python-list, but my guess would be that these messages are too short to have sufficient spammy clues to get out of the unsure range. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: SpamBayes wins PCW Editors Choice Award for anti-spam software.
While it may not adequately credit the implementation language, Was this it the PCW article or SpamBayes? If the latter, please let spambayes-dev@python.org know how you think Python should be more appropriately credited; we are certainly trying to do this. (Python is mentioned all over the website, the Python Powered logo is integrated into what passes for a SpamBayes logo, and all donations to the project go to the PSF). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: SpamBayes wins PCW Editors Choice Award for anti-spam software.
IMHO, there is a great opportunity here for the python community: [...] Surely that's worth a simple team name, for mnemonic purposes if nothing else. Something different or unusual, like one of my favourites, Legion of the Bouncy Castle, who are a group of Java cryptography dudes Is there really anything to be gained by referring to the SpamBayes development team via some cryptic name? You can call use the SDT if you like. Should the Python developers likewise get some cryptic name? =Tony.Meyer Plug: If anyone really wants to help SpamBayes, please contribute! http://sf.net/projects/spambayes has plenty of bugs/feature requests to work on, or you can read http://spambayes.org/faq.html#i-m-not-a-programmer-but-want-to-help-out-wha t-can-i-do for non-programming help ideas. -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-08-01 through 2005-08-15
/2005-August/055069.html`__ - `__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code) http://mail.python.org/pipermail/python-dev/2005-August/055093.html`__ - `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-August/055110.html`__ - `PEP 342 Implementation http://mail.python.org/pipermail/python-dev/2005-August/055151.html`__ - `String exceptions in Python source http://mail.python.org/pipermail/python-dev/2005-August/055155.html`__ - `[ python-Patches-790710 ] breakpoint command lists in pdb http://mail.python.org/pipermail/python-dev/2005-August/055157.html`__ - `[C++-sig] GCC version compatibility http://mail.python.org/pipermail/python-dev/2005-August/055219.html`__ - `PyTuple_Pack added references undocumented http://mail.python.org/pipermail/python-dev/2005-August/055232.html`__ - `PEP-- Context Managment variant http://mail.python.org/pipermail/python-dev/2005-August/055271.html`__ - `Sourceforge CVS down? http://mail.python.org/pipermail/python-dev/2005-August/055307.html`__ - `PSF grant / contacts http://mail.python.org/pipermail/python-dev/2005-August/055311.html`__ - `Python + Ping http://mail.python.org/pipermail/python-dev/2005-August/055319.html`__ - `Terminology for PEP 343 http://mail.python.org/pipermail/python-dev/2005-August/055347.html`__ - `dev listinfo page (was: Re: Python + Ping) http://mail.python.org/pipermail/python-dev/2005-August/055348.html`__ - `set.remove feature/bug http://mail.python.org/pipermail/python-dev/2005-August/055352.html`__ - `Extension to dl module to allow passing strings from native function http://mail.python.org/pipermail/python-dev/2005-August/055363.html`__ - `build problems on macosx (CVS HEAD) http://mail.python.org/pipermail/python-dev/2005-August/055385.html`__ - `request for code review - hashlib - patch #1121611 http://mail.python.org/pipermail/python-dev/2005-August/055410.html`__ - `python-dev Summary for 2005-07-16 through 2005-07-31 [draft] http://mail.python.org/pipermail/python-dev/2005-August/055411.html`__ - `string_join overrides TypeError exception thrown in generator http://mail.python.org/pipermail/python-dev/2005-August/055414.html`__ - `implementation of copy standard lib http://mail.python.org/pipermail/python-dev/2005-August/055450.html`__ - `xml.parsers.expat no userdata in callback functions http://mail.python.org/pipermail/python-dev/2005-August/055362.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2005 through August 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). Tim Lesher has had to bow out from the summaries for now; many thanks to him for the contributions he made over the last few months. This is the 1st summary written by the python-dev summary confederacy of Steve Bethard and Tony Meyer (Thanks Tim!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using
python-dev Summary for 2005-08-01 through 2005-08-15
/2005-August/055069.html`__ - `__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code) http://mail.python.org/pipermail/python-dev/2005-August/055093.html`__ - `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-August/055110.html`__ - `PEP 342 Implementation http://mail.python.org/pipermail/python-dev/2005-August/055151.html`__ - `String exceptions in Python source http://mail.python.org/pipermail/python-dev/2005-August/055155.html`__ - `[ python-Patches-790710 ] breakpoint command lists in pdb http://mail.python.org/pipermail/python-dev/2005-August/055157.html`__ - `[C++-sig] GCC version compatibility http://mail.python.org/pipermail/python-dev/2005-August/055219.html`__ - `PyTuple_Pack added references undocumented http://mail.python.org/pipermail/python-dev/2005-August/055232.html`__ - `PEP-- Context Managment variant http://mail.python.org/pipermail/python-dev/2005-August/055271.html`__ - `Sourceforge CVS down? http://mail.python.org/pipermail/python-dev/2005-August/055307.html`__ - `PSF grant / contacts http://mail.python.org/pipermail/python-dev/2005-August/055311.html`__ - `Python + Ping http://mail.python.org/pipermail/python-dev/2005-August/055319.html`__ - `Terminology for PEP 343 http://mail.python.org/pipermail/python-dev/2005-August/055347.html`__ - `dev listinfo page (was: Re: Python + Ping) http://mail.python.org/pipermail/python-dev/2005-August/055348.html`__ - `set.remove feature/bug http://mail.python.org/pipermail/python-dev/2005-August/055352.html`__ - `Extension to dl module to allow passing strings from native function http://mail.python.org/pipermail/python-dev/2005-August/055363.html`__ - `build problems on macosx (CVS HEAD) http://mail.python.org/pipermail/python-dev/2005-August/055385.html`__ - `request for code review - hashlib - patch #1121611 http://mail.python.org/pipermail/python-dev/2005-August/055410.html`__ - `python-dev Summary for 2005-07-16 through 2005-07-31 [draft] http://mail.python.org/pipermail/python-dev/2005-August/055411.html`__ - `string_join overrides TypeError exception thrown in generator http://mail.python.org/pipermail/python-dev/2005-August/055414.html`__ - `implementation of copy standard lib http://mail.python.org/pipermail/python-dev/2005-August/055450.html`__ - `xml.parsers.expat no userdata in callback functions http://mail.python.org/pipermail/python-dev/2005-August/055362.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2005 through August 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). Tim Lesher has had to bow out from the summaries for now; many thanks to him for the contributions he made over the last few months. This is the 1st summary written by the python-dev summary confederacy of Steve Bethard and Tony Meyer (Thanks Tim!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using
python-dev Summary for 2005-07-16 through 2005-07-31
`__ - Docstrings and the Official Documentation - A new `bug report`_ pointed out that the docstring help for cgi.escape was not as detailed as that in the full documentation, prompting Skip Montanaro to ask whether this should be the case or not. Several reasons were outlined why docstrings should be more of a quick reference card than a textbook (i.e. maintain the status quo). Tim Peters suggested that tools to extract text from the full documentation would be a more sensible method of making the textbook available from help()/pydoc; if anyone is interested, then this would probably be the best way to start implementing this. .. _bug report: http://python.org/sf/1243553 Contributing thread: - `should doc string content == documentation content? http://mail.python.org/pipermail/python-dev/2005-July/054928.html`__ --- Syntax suggestion: while: --- Martin Blais suggested while: as a syntactic shortcut for while True:. The suggestion was shot down pretty quickly; not only is while: less explicit than while True:, but it introduces readability problems for the apparently large number of people who, when reading while:, immediately think while what? Contributing thread: - `while: http://mail.python.org/pipermail/python-dev/2005-July/054914.html`__ -- Sets in Python 2.5 -- In Python 2.4, there is no C API for the built-in set type; you must use PyObject_Call(), etc. as you would in accessing other Python objects. However, in Python 2.5, Raymond Hettinger plans to introduce a C API along with a new implementation of the set type that uses its own data structure instead of forwarding everything to dicts. Contributing thread: - `C api for built-in type set? http://mail.python.org/pipermail/python-dev/2005-July/054940.html`__ === Skipped Threads === - `Some RFE for review http://mail.python.org/pipermail/python-dev/2005-July/054896.html`__ - `python/dist/src/Doc/lib emailutil.tex,1.11,1.12 http://mail.python.org/pipermail/python-dev/2005-July/054902.html`__ - `read only files http://mail.python.org/pipermail/python-dev/2005-July/054907.html`__ - `builtin filter function http://mail.python.org/pipermail/python-dev/2005-July/054909.html`__ - `Weekly Python Patch/Bug Summary http://mail.python.org/pipermail/python-dev/2005-July/054921.html`__ - `Information request; Keywords: compiler compiler, EBNF, python, ISO 14977 http://mail.python.org/pipermail/python-dev/2005-July/054925.html`__ - `installation of python on a Zaurus http://mail.python.org/pipermail/python-dev/2005-July/054937.html`__ - `python-dev summary for 2005-07-01 to 2005-07-15 [draft] http://mail.python.org/pipermail/python-dev/2005-July/054948.html`__ - `math.fabs redundant? http://mail.python.org/pipermail/python-dev/2005-July/054991.html`__ = Skipped Threads (covered in the previous summary) = - `'With' context documentation draft (was Re: Terminology for PEP 343 http://mail.python.org/pipermail/python-dev/2005-July/054891.html`__ - `Adding the 'path' module (was Re: Some RFE for review) http://mail.python.org/pipermail/python-dev/2005-July/054894.html`__ - `[C++-sig] GCC version compatibility http://mail.python.org/pipermail/python-dev/2005-July/054895.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from July 16, 2005 through July 31, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 8th summary written by the python-dev summary cabal of Steve Bethard, Tim Lesher, and Tony Meyer. To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tim Lesher (tlesher at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject
RE: rfc822 module bug?
[rfc822 module bug] Date: Tue,26 Jul 2005 13:14:27 GMT +0200 It seems to be correct¹, but parsedate_tz is not able to decode it, it is confused by the absence of a space after the ,. [...] I think I'll submit this bug on the Python web-site. Please don't. The rfc822 module is deprecated from Python 2.3 in favour of the email package. This bug does not exist in the email package (at least in Python 2.4). For example: import rfc822 rfc822.parsedate_tz(Tue, 26 Jul 2005 13:14:27 GMT +0200) (2005, 7, 26, 13, 14, 27, 0, 1, 0, 0) rfc822.parsedate_tz(Tue,26 Jul 2005 13:14:27 GMT +0200) import email import email.Utils email.Utils.parsedate_tz(Tue, 26 Jul 2005 13:14:27 GMT +0200) (2005, 7, 26, 13, 14, 27, 0, 1, 0, 0) email.Utils.parsedate_tz(Tue,26 Jul 2005 13:14:27 GMT +0200) (2005, 7, 26, 13, 14, 27, 0, 1, 0, 0) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Yes, I read and understood it. Saying Don't read this if you don't want to be offended doesn't make an offensive statement inoffensive. No, but it makes complaining that it was offensive pointless. I grant that Python is much easier to learn than other programming languages; students can pick up the basics rapidly. Once the basics are mastered and mentoring is over, reliance on guess and intuition is not a substitute for documentation, or for reading the code if documentation is not available. Working with paths *is* the basics, especially since another strength of Python is as a form of shell script. However, if the intention here is to create something different from Jason's original module, create something different and call it by another name than path; don't attempt to guess what Jason really meant. It is not Pythonic to guess. I believe the intent here is to add an OO path object to the standard library. If the intent was to add Jason's path module to the standard library, then there would be no room for discussion about how it was. No doubt Reinhold can clarify the intent here. Certainly there will be times when what is suitable for a third-party module is not suitable for a standard library module. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Is classic Macintosh OS still supported on Python? No. At least, AFAIK, there is no intent to produce packages of new Python versions for Mac pre OS X. Old versions of Python still work, of course, but whatever version of Path makes it into Python (if any) is extremely unlikely to be supported on pre OS X Mac. I agree with all that you said, however :) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
I agree. It's yuck. So don't use it. If it were that simple, I wouldn't have bothered bringing it up. I really do believe this is a case of There should be one-- and preferably only one --obvious way to do it (as well as Explicit is better than implicit and Readability counts). If it's there, people will use it, and that means that people will have to know about it to understand that it means join and not divide (as some will expect). They'll to choose whether to use it (be explicit) or not, where the only one obvious way would remove the need for the choice. One could argue that since Although practicality beats purity and Although that way may not be obvious at first unless you're Dutch also apply here, although the latter will require Guido's answer, of course. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
While people are loathe to admit it, many stereotypes have some basis in fact. The problem is when people extend that to generalize about others (especially in a negative way). The intent was to use the basis-in-fact stereotype without having to explain in detail the factual basis, which didn't seem particularly useful, nor necessary. I suppose that was wrong. Since *I* am a Windows user and developer, if it was insulting, I was also insulting myself. For one person, at least, it seems that I needed to explain everything in as much detail as you did. Thanks for doing it for me :) [...] That being said, there is a big difference between a Windows *user* and a Windows *developer*. I doubt many Windows *users* will be writing Python code. Python is a great language for beginners (look at the tutor list). The language should be kept as easy as possible for beginners to use, while not limiting what experts can do (something to this effect was even said on python-dev recently). Lacking this __div__ hack doesn't limit experts, and does make it more difficult for beginners. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. There is a programmer who doesn't instantly recognise '/' as a directory separator. I teach programming. The above is true. I think that the statement any programmer would instantly recognise '/' as division (and associate it therewith) is much more likely to be true. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
We're talking at this point about how Path should work, not whether it's preferable to os.path.join, even though that was really the point of Reinhard's original post. That's not what I'm talking about. I'm talking about whether __div__ should be a shortcut to joinwith, or whether users should be forced to use joinwith explicitly. So far, there have been various statements that look like +0 for __div__, but no-one with a +1. (And I've said this a couple of times now, which really is just trolling for a +1 from someone). It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. (Those who are offended by sweeping generalisations should ignore this next bit) I think it's also worth considering that Windows users are more clueless than users of posix systems. The readability of __div__ comes from familiarity with posix filesystems; for a Windows user, \ would be the natural character. So we're making things more readable for users that are already more likely figure things out, and less readable for users that have trouble figuring things out. I can live with the latter, but as *someone who has used the path module already* I can only say that you might want to try it for a few months before condemning the approach using / as being unacceptable. 1. ISTM that standard library modules should be as readable as possible, even for those that don't use them. If I'm reading the source for module X and it uses a Path object, then it should be pretty straightforward to understand what is happening without also having to read the Path source/docs. This (readability without knowing the language/standard libraries) is a huge benefit of using Python. 2. If I did use the Path module, then I wouldn't use __div__, because it looks less readable to me. I suppose I might find that I got annoyed typing joinpath, but I doubt it. Also, because I have followed this PEP, I know that __div__ means joinwith, so if I read code that used path, I would understand it - it's too late for me to try reading code as a 'fresh' user and see if it confuses me or not. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
(Those who are offended by sweeping generalisations should ignore this next bit) [...generalisation bit snipped...] This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Sigh. I guess you didn't read or understand the first sentence? This (readability without knowing the language/standard libraries) is a huge benefit of using Python. It's overrated. It must be macho to say I learned Python without reading books. No it is not. Have you used Python as pseudocode when teaching people how to program? Many people have. That's just one example. Then that's your right, but don't try to take / away from people who use it and like it. People can subclass Path and add it if they really want it. They can use Jason's original module. My position is that the PEP without this use of __div__ is (a) better as a standard module, and (b) improves the chance of the PEP being accepted. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. So far there seem to have been a few +0s, but no +1s... What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) In what way is this much better? To me, this is much worse, because it is not at all clear what it means (a *huge* benefit of using Python is that you can read the code just like pseudocode). It is immediately clear from the second example that you are joining two things together. The first one, you could be joining, or you could be dividing. Compare: my_directory_string_object / somesiblingfileiknowisthere and my_directory_path_object / somesiblingfileiknowisthere These look the same, but one will raise a TypeError, and the other will result in a joined Path. How do I tell which is which when reading source, without explicitly saying that I'm using a Path object? __div__ is actually very convenient to build / a / very / very / long / path Would you really choose this: p = Path() / build / a / very / very / long / path Over this: p = Path(os.path.join(build, a, very, very, long, path)) ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Which is better (clearer, more concise) than either of the others, IMO. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[using __div__ to mean join] I'm not too happy with it, too, but do we have alternatives? As paths are strings, we can hardly override the '+' operator, so there's not much operators left. Of course, one can use joinwith() if he doesn't like '/'. My argument is that the alternative is to not provide an operator for this, and to force people to use the appropriate join function (joinwith, I gather). Not everything needs to have an operator! (In Python, at least wink). Consider the 'discussion' regarding '@' and decorators. It's pretty clear that the Python community really isn't in favour of overloading characters with a lot of different meanings, and would much prefer being explicit (explicit is better than implicit, and all that). (Guido disagreed in this particular case, of course, but I believe that is an exception). I don't speak for python-dev or know for sure, but I suspect that the PEP would have a greater chance of acceptance (the goal, I presume) if this __div__ hackery wasn't in it. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
Well, I actually had some correspondence with Jason on this very subject a year or so ago: [...] Obviously, I don't know how much weight Jason's original ideas have on the prepped-for-syslib module, but it does support what other people have been saying: that the Path should behave like a string where a string is expected. Was that the whole email? It certainly adds weight to '+' having the normal string behaviour, but it didn't really say anything about why '/' should be a shortcut for join. Do you know if Jason had any reasoning for this other than laziness wink? =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Ten Essential Development Practices
[Robert Kern] Sure, and I can find programming advice in the Old Testament, too, if I try hard enough [...] Proverbs 28:14 JPS Happy is the man that feareth alway; but he that hardeneth his heart shall fall into evil. Obviously an exhortation to not ignore raised exceptions with except: pass. +1 QOTW. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: [path-PEP] Path inherits from basestring again
[...] Open issues: [...] What about path * 4? If you keep the current join meaning of __div__, then assigning any sort of multiplication meaning to __mul__ would not be a good idea, IMO. It's natural to expect that __div__ and __mul__ are opposites. I suppose this means that you could make __mul__ mean split (and f(*tuple) does do splitting of a sort), but I don't know what splitting by 4 would mean, necessarily. Do people really like using __div__ to mean join? On the python-dev discussion, Just van Rossum spoke out against it, but there weren't (IIRC) any other comments, either pro or con. I'm -1, myself. Apart from TIOOTDI, it doesn't seem a natural use for the '/' character. I suppose that it looks nice, when one is used to posix paths, but not everyone is, and I'm sure that more people would expect some sort of division (the exact opposite!) than join. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Do a Python beginners e-mail list exist?
1. I don't want to post banal questions about Python to main Python list. Does a banal Python questions list or a Python beginners list exist? Yes: http://mail.python.org/mailman/listinfo/tutor There are plenty of people there that will be glad to help! =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
Everyone complaining about Eclipse in this thread needs to go try 3.1. The interface is much much much more responsive. The problem with Eclipse, IMO, is Java. I've tried 3.1 on a WinXP machine and, like just about any Java program, it's incredibly slow and a real pain to use. On a (similarly spec'd) Mac OS X Tiger machine, it runs nice and smoothly and is reasonably nice to use. I'd happily recommend that Mac users try Eclipse, but never a Windows (Python) programmer. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
Your first sentence contradicts the rest of your post; how is Java the problem if it runs nice on a Mac and is sluggish on Windows ? Because any Java program on (any version of) Windows (in my experience) is sluggish, and this is not true (again, in my experience) for Java programs on a Mac. There is a vast difference between the various JREs; whereas every platform I've used a cPython interpreter on has given reasonably constant performance (which is to be expected, with a C implementation). At best this may say something about the difference in perfomance between the two JREs (assuming that most Windows and Mac users of Eclipse have similar experience with yours). Which was my point. From what I've seen of this thread, people aren't saying which platform they are using Eclipse on - I have a suspicion that the JRE that people are using significantly effects the resulting opinion of Eclipse. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Thoughts on Guido's ITC audio interview
Java as a term means different things to different people, Agreed. Python is similar in this respect - it's common to refer to cPython here as Python, for example. but I expect most would think of the core language and its standard library first and the JRE/JVM second. So saying the problem of X is Java when you really mean the problem of X in platform Y is Sun's JVM in Y is kinda misleading. Obviously I wouldn't agree :) The discussion here is about Java from a user's POV, not a programmer (because we are using a Java application to program in Python), and from the user's POV, the JRE/JVM is what is important, not the language. Much the same as a programmer who is using an IDE written in Python to program in some other language would really only care about how the Python VM performs. Disclaimer: I am neither Java's not Eclipse's advocate; I'll choose python over Java any day, but let's put the blame where it is due. If there isn't a good VM for the OS that the vast majority of computers use, then the language has a problem, IMO. Having a great language spec is one thing, but it's not really much use without a good implementation. It would be interesting to know which JRE the Eclipse advocates are using, and which the people that dislike Eclipse are using... =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Modules for inclusion in standard library?
Do you have any other good and valued Python modules that you would think are bug-free, mature (that includes a long release distance) and useful enough to be granted a place in the stdlib? First of all, numeric/numarray, obviously! There has been recent discussion about this. Check the python-dev list archives I think. Or the python-dev summaries, of course wink. The most recent one to discuss this was this one, I believe: http://www.python.org/dev/summary/2005-02-01_2005-02-14.html#clarification- sought-about-including-a-multidimensional-array-object-into-python-core =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Tracing down segfault
[Tony Meyer] I have (unfortunately) a Python program that I can consistently (in a reproducible way) segfault. [Tim Peters] The _best_ thing to do next is to rebuild Python, and as many other packages as possible, in debug mode. [...] It's especially useful to rebuild Python that way. Many asserts are enabled then, and all of Python's memory allocations go thru a special debug allocator then with gimmicks to try and catch out-of-bounds stores, double frees, and use of free()'d memory. I wondered if that might help. I really ought to get around to doing a debug build someday, I guess. It just doesn't seem like the easiest thing to do on Windows without the MS tools (although I do recall various c.l.p messages indicating that the required patches were around somewhere). Luckily (see below), I managed to avoid it this time. You didn't mention which version of any of these you're using, or the OS in use. Playing historical odds, and assuming relatively recent versions of all, wx is the best guess. Sorry (although your guesses were pretty good; just as well you pop up everywhere I post to help me out 0.5 wink). Windows XP SP2, Python 2.3.5 or 2.4.1, ZODB 3.4.0, wxPython 2.6.1.0. After taking 24 hours off, I figured out that I could reasonably easily run the code without using anything that imported wx, and, sure enough, the segfault doesn't occur. Good in that it's much less code to look at, but bad in that I didn't write any of the code that uses wx... [Tony, suspecting threading to be the cause] It's unlikely to be the true cause. Apart from some new-in-2.4 thread-local storage gimmicks, all of the threading module is written in Python too. NULL pointers are a (depressingly common) C problem. Oh well. I was working on a few things at once, and it's possible that I only noticed it after adding the new threading code. So only a single thread is running at the time the segfault occurs? As far I know, yes. At least, all the threads that I created I have called join() on without any timeout. Is Python also in the process of tearing itself down (i.e., is the program trying to exit?). Yes, the program is trying to exit. It's after the a call is made to wx.GetApp().ExitMainLoop() (but a print statement after that does print). If I run with python -v, it dies before any of the # clear statements get printed out. I'm not sure what runs between those :( [Later] The 24 hours off helped me think much more clearly. Once I had narrowed it down to wx (and stopped worrying about all the threading code) I managed to find a line of Python that commenting out would get rid of the segfault and uncommenting would return the segfault. FWIW, I believe what was happening is that there was a wx.TaskBarIcon class that, when the Exit menu item was chosen, would call an exit function of the main frame of the wx application. That exit function called Destroy() on the TaskBarIcon class - and it was this call that caused the segfault. I presume that the problem was that the TaskBarIcon class was waiting for that exit function to be finished, and didn't appreciate being Destroy()d while it was waiting. Many thanks for the help! (Like the recent ZODB problem, the help was somewhat lateral - here, pointing me away from the threads). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Tracing down segfault
I have (unfortunately) a Python program that I can consistently (in a reproducible way) segfault. However, I've got somewhat used to Python's very nice habit of protecting me from segfaults and raising exceptions instead, and am having trouble tracking down the problem. The problem that occurs looks something like this: Program received signal SIGSEGV, Segmentation fault. 0x00a502aa in ?? () (gdb) bt #0 0x00a502aa in ?? () Cannot access memory at address 0x0 Which looks something like accessing a NULL pointer to me. The problem is finding the code that is causing this, so I can work around it (or fix it). Unfortunately, the script uses ZEO, ZODB, threading.Threads, and wx (my code is pure Python, though), and I'm having trouble creating a simple version that isolates the problem (I'm pretty sure it started happening when I switched from thread to threading, but I'm not sure why that would be causing a problem; I am join()ing all threads before this happens). Does anyone have any advice for tracking this down? Thanks! Tony Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: inactive Spambayes w/ Outlook
I had installed spambayes with outlook 2003 a while ago and it worked great. Then I did who know what it stopped working. If Peter's link doesn't help, I suggest you try the spambayes mailing list: http://mail.python.org/mailman/listinfo/spambayes =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: What are OOP's Jargons and Complexities?
[Paul Rubin] Strong typing means there [are] a lot of variables whose names are in ALL CAPS. +1 QOTW. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Checking for a full house
def removeAll(element, num2Rem, list): l = list[:] for num in range(0, num2Rem): l.remove(element) return l def isfullHouse(roll): for die in range(1,7): if roll.count(die)==3: l = removeAll(die, 3, roll) if l[0]==l[1]: return 1 return 0 My questions is this: is there a better way to do this? A way that's more natural to python, or just more efficient perhaps? This is an alternative that doesn't muck about making a second list: def isfullHouse(roll): has_pair = False has_triple = False for die in xrange(1,7): if has_pair and has_triple: return True count = roll.count(die) if count 3: return False # easy out; can't have four/five and full house if count == 2: has_pair = True elif count == 3: has_triple = True return False If you want it in one line (and have Python 2.4): def isfullHouse(roll): return len(set(roll)) != 2 If you create a set from the list, it will remove duplicates. If there are 3,4, or 5 different numbers, then you don't have a triplet. (I assume that [1,1,1,1,1] isn't a full house, or this answer is wrong, since that will have the length be 1). (These are both untested). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Checking for a full house
[Tony Meyer] def isfullHouse(roll): return len(set(roll)) != 2 [Robert Kern] [1, 1, 1, 1, 2] is not a full house. Opps. I did say it was untested (that should have been == not !=, too). What about: def isfullHouse(roll): return len(set(roll)) == 2 and roll.count(min(roll)) != 1 and roll.count(max(roll)) != 1 Although your solution looks a lot nicer than this (though it may use more memory, and might be slower). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: problem uploading ZIP file tp PyPI
setup.py sdist --format=zip Try without the --format arg. The code is being too paranoid. Result: (A) produces a zip file with only minor differences (presumably a timestamp): Oh, so even without --format, a ZIP source dist file is produced anyway? If this is the case, please file a bug against PyPI. How is this a bug? sdist is meant to produce a zip file on Windows if --format isn't used. If upload overrides this for some reason, then the documentation should say so (and, IMO, it would be a mistake for that to be the case). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: problem uploading ZIP file tp PyPI
setup.py sdist --format=zip Try without the --format arg. The code is being too paranoid. Oh, so even without --format, a ZIP source dist file is produced anyway? If this is the case, please file a bug against PyPI. How is this a bug? sdist is meant to produce a zip file on Windows if --format isn't used. If upload overrides this for some reason, then the documentation should say so (and, IMO, it would be a mistake for that to be the case). It's a bug against PyPI, not distutils. Did you mean that the bug is that PyPI won't accept a zipped source distribution? To me, your message read like it was saying that (distutils) producing a zip source distribution file without --format was a bug. So (if the former is what you meant) would a workaround for now be to do something like: setup.py sdist --format=gztar upload ? =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: problem uploading ZIP file tp PyPI
So (if the former is what you meant) would a workaround for now be to do something like: setup.py sdist --format=gztar upload (1) error: command 'tar' failed: No such file or directory I was assuming that tar and gzip were available. There are various tar/gzip applications available for Windows, e.g. Cygwin, gnuwin32. http://cygwin.com http://gnuwin32.sourceforge.net http://www.gzip.org (2) error: invalid command 'upload' Using the files link alternative to 'upload', then (I thought that specifying 'upload' in my example would make the question clearer, since it spells out that I want to upload the dist, without saying that I will use the files link). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-04-16 through 2005-04-30
trumped by potentially harmful. - if the API is awkward or error-prone, that is a bad sign. Contributing threads: - `atexit missing an unregister method http://mail.python.org/pipermail/python-dev/2005-April/052983.html`__ [TAM] --- Pickling buffer objects --- Travis Oliphant proposed a patch to the pickle module to allow pickling of the buffer object. His use case was avoiding copying array data into a string before writing to a file in Numeric, while still having Numeric arrays interact seamlessly with other pickleable types. The proposal was to unpickle the object as a string (since a `bytes object`_ does not exist) rather than to mutable-byte buffer objects, to maintain backwards compatibility. Other than a couple of questions, no objections were raised, so a patch is likely to appear. Contributing threads: - `Pickling buffer objects. http://mail.python.org/pipermail/python-dev/2005-April/052707.html`__ .. _bytes object: http://python.org/peps/pep-0296.html [TAM] - Referencing counting when entering/exiting scopes - Matt Barnes noticed that symtable_exit_scope decrefs a borrowed reference, which should lead to data corruption ... except that symtable_enter_scope leaks a reference. Since they're called as a pair, it works out. Guido did suggest that it would be better if the code were written in a less brittle manner. Contributing threads: - `Reference counting when entering and exiting scopes http://mail.python.org/pipermail/python-dev/2005-April/052779.html`__ [Jim Jewett] === Skipped Threads === - `Another Anonymous Block Proposal http://mail.python.org/pipermail/python-dev/2005-April/053031.html`__ - `PEP 340: What is ret in block statement semantics? http://mail.python.org/pipermail/python-dev/2005-April/053140.html`__ - `anonymous blocks (off topic: match) http://mail.python.org/pipermail/python-dev/2005-April/052759.html`__ - `Reference counting when entering and exiting scopes http://mail.python.org/pipermail/python-dev/2005-April/052779.html`__ - `How do you get yesterday from a time object http://mail.python.org/pipermail/python-dev/2005-April/052712.html`__ - `shadow password module (spwd) is never built due to error in setup.py http://mail.python.org/pipermail/python-dev/2005-April/052679.html`__ - `Problem with embedded python http://mail.python.org/pipermail/python-dev/2005-April/052995.html`__ - `python.org crashing Mozilla? http://mail.python.org/pipermail/python-dev/2005-April/052992.html`__ - `noob question regarding the interpreter http://mail.python.org/pipermail/python-dev/2005-April/053103.html`__ - `Newish test failures http://mail.python.org/pipermail/python-dev/2005-April/052771.html`__ - `Error checking in initmodule functions http://mail.python.org/pipermail/python-dev/2005-April/052847.html`__ - `a few SF bugs which can (probably) be closed http://mail.python.org/pipermail/python-dev/2005-April/052864.html`__ - `Check out a new way to read threaded conversations. http://mail.python.org/pipermail/python-dev/2005-April/052674.html`__ - `Python 2.1 in HP-UX http://mail.python.org/pipermail/python-dev/2005-April/052710.html`__ - `Python tests fails on HP-UX 11.11 and core dumps http://mail.python.org/pipermail/python-dev/2005-April/052652.html`__ - `IPV6 with Python- 4.2.1 on HPUX http://mail.python.org/pipermail/python-dev/2005-April/052656.html`__ - `Fwd: CFP: DLS05: ACM Dynamic Languages Symposium http://mail.python.org/pipermail/python-dev/2005-April/052699.html`__ - `PyCon 2005 keynote on-line http://mail.python.org/pipermail/python-dev/2005-April/052684.html`__ - `PyCallable_Check redeclaration http://mail.python.org/pipermail/python-dev/2005-April/052677.html`__ - `os.urandom uses closed FD (sf 1177468) http://mail.python.org/pipermail/python-dev/2005-April/052716.html`__ - `Removing --with-wctype-functions support http://mail.python.org/pipermail/python-dev/2005-April/052968.html`__ Epilogue This is a summary of traffic on the `python-dev mailing list`_ from April 16, 2005 through April 30, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. A `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 2nd summary written by the python-dev summary cabal of Steve Bethard, Tim Lesher, and Tony Meyer (missing Brett yet?). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tim Lesher (tlesher at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us
RE: Quote-aware string splitting
I need to split a string as per string.strip(), but with a modification: I want it to recognize quoted strings and return them as one list item, regardless of any whitespace within the quoted string. See the recent python-tutor thread starting here: http://mail.python.org/pipermail/tutor/2005-April/037288.html For various solutions. Or just use a regular expression, which is what the thread concludes. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Python 2.4 killing commercial Windows Python development ?
[Nemesis] OK, so the python installer _does_ ship this dll. So also the win installer has the redistribution problem, or does they pay for redistributing msvcr71.dll? If you have a legal copy of one of the commercial MS compilers that includes msvcr71.dll, you get the right to redistribute it. Many of the python-dev people have one of these, so one of their copies is being distributed (exactly whose copy is academic, really). The redistribution is subject to various conditions, including getting the user to agree to a certain form of EULA, which the 2.4 and 2.4.1 .msi installers do not do, so they breach the EULA, yes. All of this is pretty clear in the EULA, and has been said before, here and on python-dev. If anyone wanted to help out, and lessen the incredibly remote chance that MS will take legal action against the 2.4 distribution, then I'm sure that MvL would be happy to accept patches for the .msi so that an appropriate click-through EULA was part of the installation. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Python 2.4 killing commercial Windows Python development ?
installs it where? the MS docs seem to indicate that they want you to install it in the program directory, rather than in a shared location: http://support.microsoft.com/default.aspx?scid=kb;en-us;326922 From http://mail.python.org/pipermail/python-list/2005-February/265334.html: This means to install it into the directory containing python.exe. Unfortunately, this does not work if your extension is then used in an embedded Python, e.g. one running as a COM object. In this case, python.exe will not be the main executable, but, say, outlook.exe will be. So Microsoft's recommendation to install the DLL into the EXE directory is flawed for COM and other embedded cases. This is precisely the reason why the Python installer installs both python24.dll and msvcr71.dll into system32. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Python 2.4 killing commercial Windows Python development ?
[problems with dependency on msvr71.dll snipped] One option is to create a Windows Python 2.4 installer that includes a Python not built with MSVC7 - for example gcc or MSVC6 - which doesn't have the dependency on mscvr71.dll. Both VC6 and gcc are feasible, although there may be a reasonable amount of work required. If the installer proved popular, then I'm sure the python-dev people could be convinced (for 2.5, perhaps) that there should be an official release of this type, much like there's a separate 64 bit installer available. (Assuming that patches could be submitted that made the build process as seamless as the existing one). This seems a much more achievable goal than anything involving a meeting with Microsoft... =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: compound strip() string problem
As Sidharth Kuruvila pointed out, time.strftime() is probably
the best choice for your situation. For the general case of
removing whitespace from a sting, one method is:
''.join(mystring.split())
Alternatively, you could do something like:
import string
for c in string.whitespace:
mystring = mystring.replace(c, )
Not as good if you want to remove all whitespace from the string, but it
looked like the OP only really had spaces, so a simple
mystring=mystring.replace(' ', '') would be the clearest (and fastest).
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: Unexpected result when comparing method with variable
[David Handy] I had a program fail on me today because the following didn't work as I expected: class C: ... def f(self): ... pass ... c = C() m = c.f m is c.f False [...] The workaround really awkward: What's wrong with this? class C: ... def f(self): ... pass ... def g(self): ... pass ... c = C() m = c.f m == c.f True m == c.g False =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: IMAP4.search by message-id ?
Can anyone tell me how to get a message's number from the message-id
using IMAP4.search?
I've tried this:
resp, items = server.search(None, 'HEADER',
'Message-id', msgID) but it gives me a 'bogus search criteria' error
import imaplib
i = imaplib.IMAP4(mail.example.com)
i.login(username, password)
[...]
i.select()
[...]
i.search(None, '(HEADER Message-ID
[EMAIL PROTECTED])')
('OK', ['4'])
i.logout()
[...]
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: Python LEGO Mindstorm control...
I have a question re the use of Python to control a robot built with the LEGO Mindstorm system. This is to help my 11yr old with his increased interest in 'programming' and 'robotics'... If not feasible, he wants to use the graphical-tool that comes with it... Would you suggest: 1. Using LegOS (http://legos.sourceforge.net/) and writing/using py extensions from a Linux-box, OR BTW, this should be BrickOS (http://brickos.sourceforge.net/). 2. Using LeJOS (http://lejos.sourceforge.net/) and writing Jython utils. Wanted to incorporate Python somehow, as it may be quite appropriate for his age. Will have to help quite a bit in either case, tho... but was wondering which is a more treaded path... I've used the graphical environment that comes with Mindstorms in conjunction with CPython. Basically I have a Python extension that can send IR signals (well, a 0-255 number) to the RCX. In the graphical environment I can design a program to respond to the IR signals (pretty simple stuff), and in a Python script I can put more complex behaviour that interacts with other things and sends out the appropriate IR controls. (Essentially, the graphical environment is used for strict RCX control - turning motors on/off, reading sensors, etc, and the Python environment is used for everything else). I found this a good way to do things (although part of that is the nature of the larger project), and suspect it may be in other cases, too. It does mean you can avoid C/C++ (apart from creating the extension in the first place) and Java, and don't need to replace the firmware, as with LeJOS. The extension is a fairly simple adaptation of some NQC code (NQC is licensed under the MPL). I can wrap it up and give it to you if you'd like, or just describe what I did. If you wanted to do a lot more work, you could wrap a great deal more of the NQC code and have a CPython extension that can really control the RCX without using the graphical environment or BrickOS/LeJOS. I think starting off with the graphical environment is generally good, though. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: sorting a dictionary?
Thank you scott, but 'sorted' itself is not a python library function. So I assume by sorted(mydict.items(), you meant the object of mydict.items() which has been sorted, right? It's a builtin as of Python 2.4: Python 2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. sorted built-in function sorted Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. sorted Traceback (most recent call last): File stdin, line 1, in ? NameError: name 'sorted' is not defined So you can use it if you have 2.4, but not otherwise (but the other solutions posted will work). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: sorting a dictionary?
mydict = {'the':358, 'they':29, 'went':7, 'said':65}
Is there an easy to sort this dictionary and get a
list like the following (in decreasing order)?
the 358
said 65
they 29
went 7
The dictionary's keys and values are lists, which can be sorted, so you can
just use that. This would be simple to do if you were sorting on the keys,
but is a bit more complicated trying to sort on the values (since you can't
lookup a key from a value).
You can do this by converting the items (not just values) to a list and then
sorting, for example:
mydict = {'the':358, 'they':29, 'went':7, 'said':65}
mydict_as_list = list(mydict.items())
mydict_as_list.sort(key=lambda p:p[1], reverse=True)
for k,v in mydict_as_list:
... print k, v
...
the 358
said 65
they 29
went 7
There are no doubt faster and cleverer ways to do this (and ways that don't
use a lambda), but this works...
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
Python 2.4, asyncore and errors
Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of warning: unhandled exception (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Does anyone else agree that this should be changed? If so, what should be the correct behavior? (I'm happy to work up a patch and submit it). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: select random entry from dictionary
How can I select a random entry from a dictionary, regardless of its
key-values?
import random
d = {1:'a', 2:'b', 3:'c'}
a = random.choice(d.keys())
a, d[a]
(2, 'b')
(etc)
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: Dictionaries of Lists
I'd like to associate certain lists with keywords, and
retrieve them. But this is not possible as lists are
not hashable.
A dictionary's values don't have to be hashable, so if the keywords are the
keys in the dictionary, this would work.
d = {}
d['key1'] = [1,2,3]
d['key2'] = [4,5,6]
d
{'key2': [4, 5, 6], 'key1': [1, 2, 3]}
I don't mind making my lists immutable. Is there a way
to tupelize them?
l = [1,2,3,4]
tuple(l)
(1, 2, 3, 4)
list(tuple(l))
[1, 2, 3, 4]
I tried mydict[mykey]=([a for a in list]) but it
didn't seem to work.
[a for a in list] (or a[:]) makes a copy of a list. Putting parentheses
around a list does absolutely nothing. You then assign the copied list to
the 'mykey' index in the dictionary.
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: convert a list to a string?
Suppose I have a list myList = [this, is, a, sample, list] If I don't want to iterate through it and concatenate the list elements, how do I easily convert it to a string like this is a sample list .join(myList) =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: reading only new messages in imaplib
[Raghul] Is it posssible to read only the new messages or unread messages using imaplib in python? If it is possible pls specify the module or give a sample code. [Tony Meyer] This will print out the first 20 chars of each undeleted message. You should be able to figure out how to do what you want from it. [...] [Raghul] Received: by twmail. Received: from mail. [...] it prints something like this. what it actually display. Did you read what I wrote, or just run the code? As I said, it displays the first 20 characters of each undeleted message. If you can't see where the 'first 20 characters' bit is in the code, then you really need to forget about IMAP for the moment and start with the Python tutorial. And pls tell me what it actually does? I can't understand import imaplib Imports the imaplib module. i = imaplib.IMAP4(mail.example.com) Creates an imaplib.IMAP4 instance to be connected to the mail.example.com server. i.login(username, password) Logs into the server with the username username and the password password. i.select() Selects the inbox. for msg_num in i.search(None, UNDELETED)[1][0].split(): Does an IMAP search for UNDELETED messages. Assumes that [0] of the response is OK and that [1] of the response is a tuple of the string of the ids. Splits the string on whitespace and iterates through it. ... msg = i.fetch(str(msg_num), RFC822) Fetches the message (header and body in RFC822 format) for the given message number. ... print msg[1][0][1][:20] Digs down through the response (use imaplib.debug = 4 to see it) to get the message as a string. Prints out 20 characters of it. As basically everyone has said, you must read the IMAP RFC and understand it in order to use imaplib. Please do so. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Dealing with config files what's the options
How are the expert pythoneers dealing with config files? [...] You can just import ConfigParser, or look at the various alternatives: http://www.python.org/moin/ConfigParserShootout =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: reading only new messages in imaplib
Is it posssible to read only the new messages or unread
messages using imaplib in python? If it is possible pls
specify the module or give a sample code.
This will print out the first 20 chars of each undeleted message. You
should be able to figure out how to do what you want from it.
import imaplib
i = imaplib.IMAP4(mail.example.com)
i.login(username, password)
('OK', ['[CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY
UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User
username authenticated'])
i.select()
('OK', ['12'])
for msg_num in i.search(None, UNDELETED)[1][0].split():
... msg = i.fetch(str(msg_num), RFC822)
... print msg[1][0][1][:20]
...
Return-Path: kelly_
Return-Path: J.M.La
Return-Path: H.L.Sc
Return-Path: elenat
[etc]
Simply playing around with an imaplib.IMAP4 class in an interactive prompt,
with imaplib.debug set to 4 and a copy of the RFC handy is the best way to
learn.
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: how can i randomly choose keys in dictionary
Hi,there. How can I choose a key in dictionary randomly?
Say, random.choice() in lists,
A dictionary's keys() are a list, so you already have the answer:
import random
d = {'a': 1, 'b': 2, 'c': 3}
random.choice(d.keys())
=Tony.Meyer
--
http://mail.python.org/mailman/listinfo/python-list
RE: - E02 - Support for MinGW Open Source Compiler
In addition, there are some unresolved licensing questions concerning the .NET runtime file for extensions (msvcr71.dll): [...] msvcr71.dll is a redistributable for applications written using their compiler. You can redistribute that. If (and only if) you own a copy of the (non-free) Microsoft compiler, or are a redistributer of another package that legitimately includes it. This is what the license states (the python-dev thread referenced earlier contains links to the various license texts). There are also other conditions, to do with what you are redistributing it with (it can't be alone), and including a particular type of license with your redistribution. (It appears that Python 2.4 doesn't correctly follow this at the moment, IIRC). If that answer is not good enough for you there is now a free version of Microsofts Visual Studio called Visual Studio Express (downloadable from the Microsoft's website). This DLL is (to my understanding) part of Visual Studio 7.1 and Visual Studio Express. The licenses for the free compilers from Microsoft do *not* include permission to redistribute any of the dlls, including msvcr71.dll. So you can get hold of it, but you cannot redistribute it. No licensing problem exists. Not true. The python-dev threads have much more detail. Microsoft will not get upset about msvcr71.dll being distributed. This is possibly true. But they do have the right to do so, and to take legal action against people that don't follow the rules that they have laid out. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: parsing IMAP responses?
Is there a library somewhere that impliments the IMAP protocol syntax? Twisted has pretty good IMAP support (particularly client), and it's much higher level than imaplib. It probably does what you're after. Of course, the catch is that you have to use twisted 0.5 wink. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: OS env for Windows
Is there any other way of distinguishing between XP and 2000 I wonder? WinXP SP2: import win32api major, minor, spack, platform, ver_str = win32api.GetVersionEx() print major, minor, spack, platform, ver_str 5 1 2600 2 Service Pack 2 WinNT SP4: import win32api major, minor, spack, platform, ver_str = win32api.GetVersionEx() print major, minor, spack, platform, ver_str 5 0 2195 2 Service Pack 4 =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: Where are list methods documented?
You're not the only one with a hard time finding the list documentation. It's even crazier for string docs. If you want to see how to strip strings in Python you have to go to the library docs, then click sequence types (betcha don't think of strings as sequences), then scroll to the bottom, then click String Methods, then scroll to find strip(). Does nobody use an index anymore? If you type strip into the index of the Windows HTML help, the first entry is strip (string method), which is probably what you want. Or you can use the pyhelp.cgi script linked from http://python.org/doc and search for strip and strip (string method) is the second entry (the first, which is strip in the string module, would tell you more-or-less the same, anyway). http://starship.python.net/crew/theller/pyhelp.cgi?keyword=stripversion=cu rrent Or you can go to the general index in the regular version of the HTML help. As you might expect, strip can be found under s. http://docs.python.org/lib/genindex.html#letter-s I presume that there's some sort of index in the PDF and all the other versions of the help, too. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
RE: getting data from a port in use
I am trying to use Python to get the data received at a specific port (in use) on my computer. I already tried below code which seems to hang at the statement accepting connections. Yes. It hangs at accept. I always end up doing end task because it never passes the accept statement. What do you get from wherever you are trying to connect to the port (e.g. telnet). Does it connect, or fail to connect? Note that (as others have said) if you are trying to intercept data from an existing socket connection, this is not the way to do it. (This will let you use a port that another process has already claimed, and accept new connections to it). =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
