[Python-Dev] Mapping cvs version numbers to svn revisions?
In a bug report I filed Neal Norwitz referred me to an earlier, fixed, bug report from before the cvs-to-svn switch. The file versions were thus cvs version numbers instead of svn revisions. Is it possible to map from cvs version number to svn? In this particular situation I can fairly easily infer the revision number because I know Neal made the change and roughly where in the given file(s) he was making changes, but I doubt that would always be true. I guess, did cvstosvn save that mapping somewhere? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python with Visual C++ 2005 Express Edition
On 11/10/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Christos Georgiou wrote: > > I didn't see any mention of this product in the Python-Dev list, so I > > thought to let you know. > > > > http://msdn.microsoft.com/vstudio/express/visualc/download/ > > > > There is also a link for a CD image (.img) file to download. > > > > I am downloading now, so I don't know yet whether Python compiles with it > > without any problems. So if anyone has previous experience, please reply. > > I don't have previous experience, but I think this it likely shares the > issues that VS.NET 2005 has with the current code: > 1. the project files are for VS.NET 2003. In theory, conversion to > the new format is supported, but I don't know whether this conversion > works flawlessly. > 2. MS broke ISO C conformance in VS.NET 2005 in a way that affects > Python's signal handling. There is a patch on SF which addresses > the issue, but that hasn't been checked in yet. FWIW, I downloaded Visual C++ 2005 Express edition, and the latest platform SDK, and had a go at building Python trunk. I just followed the build instructions from PCBuild\readme.txt as best I could - of the optional packages, I only got zlib to work. The issues with the other modules may or may not be serious - for example, bzip2 is now at version 1.0.3, and the old source isn't available. Just renaming the directory didn't work, but I didn't bother investigating further. I applied the patch you mentioned, but otherwise left everything unchanged. The project file conversions seemed to go fine, and the debug builds were OK, although the deprecation warnings for all the "insecure" CRT functions was a pain. It might be worth adding _CRT_SECURE_NO_DEPRECATE to the project defines somehow. I then ran the test suite, which mostly worked. Results: 235 tests OK. 5 tests failed: test_asynchat test_cookie test_grammar test_mmap test_profile 58 tests skipped: test__locale test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_cmd_line test_code test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_coding test_commands test_crypt test_curses test_dbm test_dl test_fcntl test_float test_fork1 test_functional test_gdbm test_gl test_grp test_hashlib test_hashlib_speed test_imgfile test_ioctl test_largefile test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_normalization test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_socket_ssl test_socketserver test_sunaudiodev test_threadsignals test_timeout test_timing test_urllib2net test_urllibnet test_xdrlib 7 skips unexpected on win32: test_hashlib test_cmd_line test_xdrlib test_code test_float test_coding test_functional I'm not sure what to make of the "unexpected" skips... The output for the failed tests was: test_asynchat test test_asynchat produced unexpected output: ** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + Connected + Received: 'hello world' ** test_cookie test test_cookie produced unexpected output: ** *** mismatch between lines 3-4 of expected output and lines 3-4 of actual output: - Set-Cookie: chips=ahoy + Set-Cookie: chips=ahoy; ? + - Set-Cookie: vienna=finger + Set-Cookie: vienna=finger; ? + *** mismatch between line 6 of expected output and line 6 of actual output: - Set-Cookie: chips=ahoy + Set-Cookie: chips=ahoy; ? + *** mismatch between line 8 of expected output and line 8 of actual output: - Set-Cookie: vienna=finger + Set-Cookie: vienna=finger; ? + *** mismatch between line 10 of expected output and line 10 of actual output: - Set-Cookie: keebler="E=mc2; L=\"Loves\"; fudge=\012;" + Set-Cookie: keebler="E=mc2; L=\"Loves\"; fudge=\012;"; ? + *** mismatch between line 12 of expected output and line 12 of actual output: - Set-Cookie: keebler="E=mc2; L=\"Loves\"; fudge=\012;" + Set-Cookie: keebler="E=mc2; L=\"Loves\"; fudge=\012;"; ? + *** mismatch between line 14 of expected output and line 14 of actual output: - Set-Cookie: keebler=E=mc2 + Set-Cookie: keebler=E=mc2; ? + *** mismatch between lines 16-17 of expected output and lines 16-17 of actual output: - Set-Cookie: keebler=E=mc2 + Set-Cookie: keebler=E=mc2; ? + - Set-Cookie: Customer="WILE_E_COYOTE"; Path=/acme + Set-Cookie: Customer="WILE_E_COYOTE"; Path=/acme; ? + *** mis
Re: [Python-Dev] Building Python with Visual C++ 2005 Express Edition
Paul Moore wrote: > I hope this is of some use - it would be brilliant if VC 2005 Express > could be a supported build environment. (Of course, MS have updated > the CRT again, so binaries built with VC 2005 Express aren't binary > compatible with extensions built for the standard release... :-( ) It is not really practical to support two build environments fully; as MS changed the format of the project files again, one would have to maintain two sets of project files (actually, it would be three sets, as we keep the VC6 files as well). So really having the VS2005 files in subversion isn't an option; trying to make conversion go smooth all the time certainly is a desirable goal. Using VS2005 for official builds would only be an option with the next major release (2.5), and I personally don't see that happening: AFAICT, it is not that much of a change as VS2003 was (i.e. for Python, nothing is gained AFAICT); also, I'm getting the impression that VS2005 has too many bugs (*) to be useful, so I recommend to skip that release completely, and go then to VS2006 (or whenever that is release). Regards, Martin (*) besides the really sad changes in the CRT which break ISO C compliance, pre-release versions of the IDE were really unstable. That might have improved for the release, of course. In addition, I'm aware of various problems with .NET 2.0; something that doesn't Python affect too much, though. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mapping cvs version numbers to svn revisions?
[EMAIL PROTECTED] wrote: > In a bug report I filed Neal Norwitz referred me to an earlier, fixed, bug > report from before the cvs-to-svn switch. The file versions were thus cvs > version numbers instead of svn revisions. Is it possible to map from cvs > version number to svn? It would have been possible in the process of using cvs2svn, which could have generated subversion properties to collect the CVS revision numbers. I decided against doing so, as this will become less important over time, and I was uncertain if we would still have to carry those properties around on the trunk forever. I also expected that in most cases, it should be easy to find the relationship from the commit messages. Also, nobody requested that feature in the test installation. If somebody wants to come up with something (e.g. rerunning the conversion, only to create some kind of mapping file): the tarball that was used to do the conversion is at http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2 Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > If I have a Gtk app I have to feed other (socket, callback) pairs to it. It > takes care of adding it to the select() call. Python could dictate that the > way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to > feed Python the (socket, callback) pair. Then you have a uniform way to > control event-driven applications. Today, a package like Michiel's has no > idea what sort of event loop it will encounter. If Python provided the > event loop API it would be the same no matter what widget set happened to be > used. > > The sticking point is probably that a number of such packages presume they > will always provide the main event loop and have to way to feed their > sockets to another event loop controller. That might present some hurdles > for the various package writers/Python wrappers. > I think that in order to solve Michiels' problem, there's no need for something like that, since probably neither of the "loops" are listening to sockets. Currently, Tkinter sets PyOS_InputHook to call its "dooneevent" repeatedly while Python code isn't being executed. It turns out to work excellently. All that is needed to make Tkinter and Michiels' code run together is a way to say "add this callback to the input hook" instead of the current "replace the current input hook with this callback". Then, when the interpreter is idle, it will call all the registered callbacks, one at a time, and everyone would be happy. To make this work with IDLE, or other interactive shells written in Python, you need to expose a function which will run all the registered callbacks. Then IDLE can call that function repeatedly when it's idle, and you'll get the same behaviour you have in the regular interactive shell. Specifically for IDLE, I know where that place is - since there's no way to generally invoke the input hook, I wrote a patch that calls _tkinter.dooneevent(_tkinter.DONT_WAIT) in the right place, and it works fine. Concerning threads - please don't. The "do one event at a time while the interpreter is idle" method works fine. Most programs aren't designed to be thread-safe, and since Tkinter does many callbacks to Python functions, you'll get unexpected behaviour if it's on another thread. I hope I made myself clear. This solution is simple, and works whenever a "do one event" function is available. Have a good week, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Checking working copy consistency
Hi Skip,
I made a script that runs through a subversion
sandbox and checks whether all md5sums are correct.
Please run that on your working copy to see whether
there are still any inconsistent files.
Regards,
Martin
import os, xml.dom.minidom, md5
def checkdir(arg, path, files):
if not path.endswith(".svn"):
return
# avoid further traversal
files[:] = []
entries = xml.dom.minidom.parse(os.path.join(path, "entries"))
for e in entries.getElementsByTagName("entry"):
if e.getAttribute("kind") != "file":
continue
name = e.getAttribute("name")+".svn-base"
digest = md5.md5()
digest.update(open(os.path.join(path, "text-base", name)).read())
if digest.hexdigest() != e.getAttribute("checksum"):
print "Checksum difference in", path, name
os.path.walk(".", checkdir, None)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
Jim Jewett wrote: > (6) Mark Hammond suggests that it might be easier to > replace the interactive portions of python based on the > "code" module. matplotlib suggests using ipython > instead of standard python for similar reasons. > > If that is really the simplest answer (and telling users > which IDE to use is acceptable), then ... I think Michiel > has a point. I don't claim to understand all the low-level details of this discussion, by a very long shot. But as the author of ipython, at least I'll mention what ipython does to help in this problem. Whether that is a satisfactory solution for everyone or not, I won't get into. For starters, ipython is an extension of the code.InteractiveConsole class, even though by now I've changed so much that I could probably just stop using any inheritance at all. But this is just to put ipython in the context of the stdlib. When I started using matplotlib, I wanted to be able to run my code interactively and get good plotting, as much as I used to have with Gnuplot before (IPython ships with extended Gnuplot support beyond what the default Gnuplot.py module provides). With help from John Hunter (matplotlib - mpl for short - author), we were able to add support for ipython to happily coexist with matplotlib when either the GTK or the WX backends were used. mpl can plot to Tk, GTK, WX, Qt and FLTK; Tk worked out of the box (because of the Tkinter event loop integration in Python), and with our hacks we got GTK and WX to work. Earlier this year, with the help of a few very knowledgeable Qt developers, we extended the same ideas to add support for Qt as well. As part of this effort, ipython can generically (meaning, outside of matplotlib) support interactive non-blocking control of WX, GTK and Qt apps, you get that by starting it with ipython -wthread/-gthread/-qthread The details of how this works are slightly different for each toolkit, but the overall approach is the same for all. We just register with each toolkit's idle/timer system a callback to execute pending code which is waiting in what is essentially a one-entry queue. I have a private branch where I'm adding similar support for OpenGL windows using the GLUT idle function, though it's ot ready for release yet. So far this has worked quite well. If anyone wants to see the details, the relevant code is here: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/Shell.py It may not be perfect, and it may well be the wrong approach. If so, I'll be glad to learn how to do it better: I know very little about threading and I got this to work more or less by stumbling in the dark. In particular, one thing that definitely does NOT work is mixing TWO GUI toolkits together. There is a hack (the -tk option) to try to allow mixing of ONE of Qt/WX/GTK with Tk, but it has only ever worked on Debian, and we don't really understand why. I think it's some obscure combination of how the low-level threading support for many different libraries is compiled in Debian. As far as using IDLE/Emacs/whatever (I use Xemacs personally for my own editing), our approach has been to simply tell people that the _interactive shell_ should be ipython always. They can use anything they want to edit their code with, but they should execute their scripts with ipython. ipython has a %run command which allows code execution with a ton of extra control, so the work cycle with ipython is more or less: 1. open the editor you like to use with your foo.py code. Hack on foo.py 2. whenever you wish to test your code, save foo.py 3. switch to the ipython window, and type 'run foo'. Play with the results interactively (the foo namespace updates the interactive one after completion). 4. rinse, repeat. In the matplotlib/scipy mailing lists we've more or less settled on 'this is what we support. If you don't like it, go write your own'. It may not be perfect, but it works reasonably for us (I use this system 10 hours a day in scientific production work, and so does John, so we do eat our own dog food). Given that ipython is trival to install (it's pure python code with no extra dependencies under *nix and very few under win32), and that it provides so much additional functionality on top of the default interactive interpreter, we've had no complaints so far. OK, I hope this information is useful to some of you. Feel free to contact me if you have any questions (I will monitor the thread, but I follow py-dev on gmane, so I do miss things sometimes). Cheers, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
Following Avi's suggestion, can I raise this thread up again? I think
that Reinhold's .dedent() method can be a good idea after all.
The idea is to add a method called "dedent" to strings. It would do
exactly what the current textwrap.indent function does. The motivation
is to be able to write multilined strings easily without damaging the
visual indentation of the source code, like this:
def foo():
msg = '''\
From: %s
To: %s\r\n'
Subject: Host failure report for %s
Date: %s
%s
'''.dedent() % (fr, ', '.join(to), host, time.ctime(), err)
Writing multilined strings without spaces in the beginning of lines
makes functions harder to read, since although the Python parser is
happy with it, it breaks the visual indentation.
On 9/15/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> From the sound of it, it's probably not worth endowing every string
> object with this method and hardcoding its implementation forever in C
> code. There are so many corner cases and variations on the
> functionality of "dedenting" a block that it's better to keep it as
> Python source code.
I've looked at the textwrap.dedent() function, and it's really simple
and well defined: Given a string s, take s.expandtabs().split('\n').
Take the minimal number of whitespace chars at the beginning of each
line (not counting lines with nothing but whitespaces), and remove it
from each line.
This means that the Python source code is simple, and there would be
no problems to write it in C.
On 9/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> -1
>
> Let it continue to live in textwrap where the existing pure python code
> adequately serves all string-like objects. It's not worth losing the
> duck typing by attaching new methods to str, unicode, UserString, and
> everything else aspiring to be string-like.
>
> String methods should be limited to generic string manipulations.
> String applications should be in other namespaces. That is why we don't
> have str.md5(), str.crc32(), str.ziplib(), etc.
>
> Also, I don't want to encourage dedenting as a way of life --- programs
> using it often are likely to be doing things the hard way.
>
I think that the difference between "dedent" and "md5", "crc32" and
such is the fact that making "dedent" a method helps writing code that
is easier to read.
Strings already have a lot of methods which don't make code clearer
the way "dedent" will, such as center, capitalize, expandtabs, and
many others. I think that given these, there's no reason not to add
"dedent" as a string method.
Noam
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
> The motivation > is to be able to write multilined strings easily without damaging the > visual indentation of the source code That is somewhat misleading. We already have that ability. What is being proposed is moving existing code to a different namespace. So the motivation is really something like: I want to write s = s.dedent() because it is too painful to write s = textwrap.dedent(s) Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python with Visual C++ 2005 ExpressEdition
"Martin v. Löwis" wrote: > Using VS2005 for official builds would only be an option with the > next major release (2.5), and I personally don't see that happening: > AFAICT, it is not that much of a change as VS2003 was (i.e. for > Python, nothing is gained AFAICT); also, I'm getting the impression > that VS2005 has too many bugs (*) to be useful, so I recommend to > skip that release completely, and go then to VS2006 (or whenever > that is release). With Microsoft changing the CRT all the time, I think I'd much prefer seeing effort going towards MinGW becoming the official Windows build platform. There was a considerable amount of angst with the 2.4 release that can be blamed solely on the CRT change (and hence different DLLs to link to). And with them deprecating ISO standard functions ... Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] to_int -- oops, one step missing for use.
OK, Tim and I corresponded off-list (after that Aahz graciously suggested direct mail). The code I have is still stand-alone, but I get good speeds: 60% - 70% of the speed of int(string, base). It will take a little bit to figure out how it best belongs in the Python sources, so don't look for anything for a couple of weeks. Also, I'd appreciate someone testing the code on a 64-bit machine. Essentially all I'll need is that person to do a build and then run the tests. Unfortunately the posted module tests only cover the 32-bit long cases, so what I need is another test tried on a 64-bit long machine (that uses 64-bit longs in Python). So, if you have a Python installation where sys.maxint == (1 << 63) - 1 is True, and you'd like to help, here's what I need. If you already have the zip, retrieve: http://members.dsl-only.net/~daniels/dist/test_hi_powers.py If you don't already have the zip, retrieve: http://members.dsl-only.net/~daniels/dist/to_int-0.10.zip (I just added the test_hi_powers.py to the tests in the zip) Unpack the zip, do the build: $ python setup_x.py build copy the built module into the test directory, cd to that dir, and run test_hi_powers.py. Let me know if the tests pass or fail. Thanks. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python with Visual C++ 2005 ExpressEdition
Tim Delaney wrote: > With Microsoft changing the CRT all the time, I think I'd much prefer seeing > effort going towards MinGW becoming the official Windows build platform. > There was a considerable amount of angst with the 2.4 release that can be > blamed solely on the CRT change (and hence different DLLs to link to). And > with them deprecating ISO standard functions ... The problem (for me, atleast) is that VC is so much more convenient to work with. That said, I would personally use what other people contribute (and perhaps only invoke the built process for the actual packaging). So for this to happen, somebody would have to step forward and volunteer as the "windows port maintainer" for the coming years; starting with the changes to the build process. This may be more tricky than it sounds at first: a strategy for building the libraries that we include (such as gzip, openssl, Tcl/Tk) would be needed as well. Plus, that person would have to defend the decision to drop VC (just as I am in the position of defending the switch to VS 2003). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
On 11/12/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > The motivation
> > is to be able to write multilined strings easily without damaging the
> > visual indentation of the source code
>
> That is somewhat misleading. We already have that ability. What is
> being proposed is moving existing code to a different namespace. So the
> motivation is really something like:
>
>I want to write
>s = s.dedent()
>because it is too painful to write
>s = textwrap.dedent(s)
>
Sorry, I didn't mean to mislead. I wrote "easily" - I guess using the
current textwrap.dedent isn't really hard, but still, writing:
import textwrap
...
r = some_func(textwrap.dedent('''\
line1
line2'''))
Seems harder to me than simply
r = some_func('''\
line1
line2'''.dedent())
This example brings up another reason why "dedent" us a method is a
good idea: It is a common convention to indent things according to the
last opening bracket. "dedent" as a function makes the indentation
grow in at least 7 characters, and in 16 characters if you don't do
"from textwrap import dedent".
Another reason to make it a method is that I think it focuses
attention at the string, which comes first, instead of at the
"textwrap.dedent", which is only there to make the code look nicer.
And, a last reason: making dedent a built-in method makes it a more
"official" way of doing things, and I think that this way of writing a
multilined string inside an indented block is really the best way to
do it.
Noam
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking working copy consistency
Martin> I made a script that runs through a subversion sandbox and Martin> checks whether all md5sums are correct. Please run that on your Martin> working copy to see whether there are still any inconsistent Martin> files. Thanks Martin. I got no complaints (trunk, release23-maint, release24-maint, peps), though see my next message... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is some magic required to check out new files from svn?
Is there some magic required to check out new files from the repository? I'm trying to build on the trunk and am getting compilation errors about code.h not being found. If I remember correctly, this is a new file brought over from the ast branch. Using cvs I would have executed something like "cvs up -dPA ." if I found I was missing something (usually a new directory) and wanted to make sure I was in sync with the trunk. I read the developer's FAQ and the output of "svn up --help". Executing "svn up" or "svn info" tells me I'm already at rev 41430, which is the latest rev, right? Creating a fresh build subdirectory followed by configure and make gives me this error: ../Objects/frameobject.c:6:18: code.h: No such file or directory Sure enough, I have no code.h in my Include directory. Before I wipe out Include and svn up again is there any debugging I can do for someone smarter in the ways of Subversion than me? Regarding my checksum problems (which are not appearing at the moment), Martin asked for 1. what specific revision you had checked out (svn info) 2. what the recorded checksum is (see .svn/entries) 3. what the commited-rev is 4. what the actual checksum is on the file on disk (.svn/text-base/filename.base) 5. whether or not the checksums svn reports match the ones you determined yourself. I don't think #2, #4 or #5 apply here. According to .svn/entries I have: Here's "svn info" output: Path: . URL: svn+ssh://[EMAIL PROTECTED]/python/trunk Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 41430 Node Kind: directory Schedule: normal Last Changed Author: fredrik.lundh Last Changed Rev: 41430 Last Changed Date: 2005-11-12 09:55:04 -0600 (Sat, 12 Nov 2005) Properties Last Updated: 2005-11-12 12:00:07 -0600 (Sat, 12 Nov 2005) I was running 1.2.0. I just downloaded and built 1.2.3. It made no difference. This is getting kinda frustrating. I haven't got a lot of confidence in Subversion at this point. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
[EMAIL PROTECTED] wrote: > Python could dictate that the > way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to > feed Python the (socket, callback) pair. Then you have a uniform way to > control event-driven applications. Certainly, if all other event-driven packages are willing to change their ways, they can be made to work together. There's not much that can be done with them the way they are, however. Also, putting the main event loop in Python then gives Python itself a privileged position that it shouldn't necessarily have. Ultimately I think there needs to be an event dispatching mechanism provided by the OS, that is universally used by all packages that want events. With the proliferation of event-driven systems these days, it's becoming as fundamental a requirement as file I/O and deserves serious OS support, I think. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Noam Raphael wrote: > All that is needed to make Tkinter and Michiels' > code run together is a way to say "add this callback to the input > hook" instead of the current "replace the current input hook with this > callback". Then, when the interpreter is idle, it will call all the > registered callbacks, one at a time, and everyone would be happy. Except for those who don't like busy waiting. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Noam Raphael wrote: > > > All that is needed to make Tkinter and Michiels' > > code run together is a way to say "add this callback to the input > > hook" instead of the current "replace the current input hook with this > > callback". Then, when the interpreter is idle, it will call all the > > registered callbacks, one at a time, and everyone would be happy. > > Except for those who don't like busy waiting. > I'm not sure I understand what you meant. If you meant that it will work slowly - a lot of people (including me) are using Tkinter without a mainloop from the interactive shell, and don't feel the difference. It uses exactly the method I described. Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] to_int -- oops, one step missing for use.
$ python2.4 -c 'import sys; print sys.maxint, sys.maxint == (1<<63) - 1' 9223372036854775807 True $ python2.4 test_hi_powers.py Test 0.2 of to_int 0.16 .. -- Ran 70 tests in 0.006s OK pgpq5Yx7ylgEf.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
Noam Raphael wrote:
> Sorry, I didn't mean to mislead. I wrote "easily" - I guess using the
> current textwrap.dedent isn't really hard, but still, writing:
>
> import textwrap
> ...
>
> r = some_func(textwrap.dedent('''\
> line1
> line2'''))
>
> Seems harder to me than simply
>
> r = some_func('''\
> line1
> line2'''.dedent())
I think a better argument for this is that dedenting a literal string is
more of a syntactic operation than a functional one. You don't think
"oh, I bet I'll need to do some dedenting on line 200 of this module, I
better import textwrap". Instead you start writing a long string
literal once you get to line 200. You can do it a few ways:
some_func("line1\nline2")
some_func("line1\n"
"line2")
some_func("""\
line1
line2""")
# If nice whitespace would be pretty but not required:
some_func("""
line1
line2""")
I often do that last one with HTML and SQL.
In practice textwrap.dedent() isn't one of the ways you are likely to
write this statement. At least I've never done it that way (and I hit
the issue often), and I don't think I've seen code that has used that in
this circumstance.
Additionally I don't think textwrapping has anything particular to do
with dedenting, except perhaps that both functions were required when
that module was added.
I guess I just find the import cruft at the top of my files a little
annoying, and managing them rather tedious, so saying that you should
import textwrap because it makes a statement deep in the file look a
little prettier is unrealistic. At the same time, the forms that don't
use it are rather ugly or sloppy.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
> release. The main reason why I changed the import behavior was > pythonservice.exe from the win32 extensions. pythonservice.exe imports > the module that contains the service class, but because > pythonservice.exe doesn't run in optimized mode, it will only import a > .py or a .pyc file, not a .pyo file. Because we always generate bytecode > with -OO at distribution time, we either had to change the behavior of > pythonservice.exe or change the import behavior of Python. While ignoring the question of how Python should in the future handle optimizations, I think it safe to state that that pythonservice.exe should have the same basic functionality and operation in this regard as python.exe does. It doesn't sound too difficult to modify pythonservice to accept -O flags, and to modify the service installation process to allow this flag to be specified. I'd certainly welcome any such patches. Although getting off-topic for this list, note that for recent pywin32 releases, it is possible to host a service using python.exe directly, and this is the technique py2exe uses to host service executables. It would take a little more work to set things up to work like that, but that's probably not too unreasonable for a custom application with specialized distribution requirements. Using python.exe obviously means you get full access to the command-line facilities it provides. So while I believe your idead for getting and setting these flags sounds reasonable, and also believe that at face value the zipimport semantics appear sane, I'm not sure we should use a weakness in a Python tool to justify a change to Python itself. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
