Re: [Python-Dev] OpenIndiana and Solaris support
I work for Joyent (joyent.com) now, which employs a number of devs that work on illumos (illumos.org). We also provide cloud infrastructure. Would it help if we offered one or more instances (VMs) on which to run buildbot slaves (and on which volunteers for bug fixing could hack)? I know a lot of people in the illumos community would be quite sad to have it dropped as a core Python plat. Guido, Yes you are correct that Oracle owns the Solaris brand. tl;dr history if you care: - sunos -> Solaris - Sun open sources Solaris, called OpenSolaris (2005) - Oracle acquires Sun and closes Solaris (Aug 2010). Shortly after, the community forks OpenSolaris and calls it illumos (Sep 2010) - OpenIndiana is a distro of illumos (somewhat similar to how Ubuntu is a distro of Linux). Other distros are SmartOS (the one Joyent works on), and OmniOS. - Oracle continues work on Solaris, releasing "Solaris 11 Express". I've no real numbers of usage of illumos vs Solaris 11 vs others. Cheers, Trent p.s. I hear that Jesus is also in contact with some of the illumos-devs on IRC (and perhaps email). I hope we can help there. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
Soliciting opinions on issue 2142 (http://bugs.python.org/issue2142).
There are patched available so this isn't vapour. :)
The issue is this (I'll discuss only unified_diff(), but the same
applies to context_diff()):
>>> from difflib import *
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
..."one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
one
two
-three+trois
Where as with `diff`, `hg` and `git`:
diff -r 667b0870428d a
--- a/a Wed Oct 06 15:39:50 2010 -0700
+++ b/a Wed Oct 06 15:40:31 2010 -0700
@@ -1,3 +1,3 @@
one
two
-three
\ No newline at end of file
+trois
\ No newline at end of file
While originally marked as a *bug*, the issue was changed to be a
*feature* request, because arguably `difflib.unified_diff()` is fine,
and the problem is in the naive use of the following to create a patch
that will work with `patch`:
''.join(gen)
Possiblities:
1. Change `difflib.unified_diff` to emit:
['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n',
'-three\n', '\ No newline at end of file', '+trois\n', '\ No newline
at end of file']
instead of:
['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n',
'-three', '+trois']
for this case.
2. Add a `add_end_of_file_newline_markers_to_make_patch_happy` keyword
arg (probably with a different name:) to `difflib.unified_diff` to do
this additional handling. The reason is to not surprise existing code
that would be surprised with those "\No newline at end of file"
entries.
3. Not touch `difflib.unified_diff` and instead update
http://docs.python.org/library/difflib.html#difflib-interface
documentation to discuss the issue and show how users of unified_diff
should handle this case themselves.
Thoughts?
Orthogonal: *After* a decision is made for the Python 3.3 tree we can
discuss if including this in either of Python 2.7 or 3.2 would be
wanted.
--
Trent Mick
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] some notes from the first part of the lang summit
(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html) Note that this was just from the first 15 minutes or so... Some quick notes about the coming plans by the "other" Python implementations from today's Python Language Summit at PyCon 2010: - IronPython: - plan is to do Python 2.7 first, focus for this year - python 3.2 for the end of next year hopefully - other work on IDE stuff - Pynie (i.e. Parrot) -- Allison Randall: - about 4 major features away from pure Python syntax (did dicts last night) - targetting py3k repo and test suite: should be on track for python 3.2 - Jython: - plan to target 2.6 (b/c 2to3 depends on 2.6) - temporarily skip 2.7 and target 3.x (probably 3.2) - then if 3.x adoption isn't fully there, then go back and add Python 2.7 - will require JDK 2.7 for Python 3 support (b/c of new support for dynamic languages) - PyPy (Holger): - plan is Benjamin will port to Python 2.7 in the summer - only have slight deviations from CPython: idea is to merge back with CPython so don't have deviations. Typcically 1 or 2 line changes in ~25 modules. Trent -- Trent Mick trentm at activestate.com http://trentm.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] notes from "2 to 3 porting" session of Python Language Summit at PyCon
My notes from the "2 to 3 porting" session of Python Language Summit at PyCon. There were some agreements in this session that people wanted recorded. Happy to provide clarification in my notes aren't clear. ## python 2 to 3 migration - 2to3 distutils flag (part of install or sdist) - 2to3 is slow: lots of room for speedup (esp. on the matching) - 3to2 - good, wanted, needed: esp. by module authors - brett: volunteers? silence. Benjamin? Google SOC. Jesse volunteered to mentor. - decision: want to look into it - Want target compat 2.x (which "x"). Can be done by selecting appropriate fixers. - some discussion of dict views, etc. - 2.x branch: - decision: 18 to 24 month btwn releases. - decision: 2.7 (2.6?) *might* be the end of the 2.x line. - 3.1: - in alpha now - a2 during the sprints (Brett channeling Benjamin) - MvL still has a couple PEPs he wants to propose - Jython: considering targetting 3.2 next, *then* maybe 2.7 - 3.1 will be the one exception to 18-24 mos. - on "18-24 mo": start a release date PEP with a feature freeze date stake in the ground when the prev ver is released - 3.0: special case, not doing 5 years of security releases... - hence 3.1 being released soon - linux distro guys are fine with that - extension docs for porting still missing: - brett: Benjamin has a draft - PortingToPy3k in the wiki - Gerhard: doing it against svn - the other Python implementations: what ver to target - depends on their audiences - Jython leaning on the latest 3 - IronPython doesn't want a moving target - skip 3.0 and go for 3.1 - python2 & python3 binaries: - make install should do it - "python3" for new and forever - or "python2" for Python 2.x release? Thomas: bad idea because usage of "python2" in the shebang line will only work on newer systems Trent -- Trent Mick trentm at gmail.com trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Chris Withers wrote: That said, it may make sense to just give greater prominence to existing repackagers, such as ActiveState or Enthought. Right, getting ActivePython or similar approved might be the way to go, but I'm betting it depends on the project... Apologies for jumping in mid-thread here. FYI: We're (where "we" == ActiveState here) looking at spending more effort on Python of late. Some of our thoughts are on add modules: whether added to the ActivePython core or easily addable via an equivalent to ActivePerl's ppm (package manager) is still be batted around. I'm curious as to people's thoughts. I'll also be at PyCon in Chicago getting thoughts. Cheers, Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daily Windows Installers
David Bolen wrote: > I hit it with a sledge-hammer and modified my build slave to disable > error boxes for anything it runs, so we'll get the 3.0 MSI now but > with a bad chm until it gets figured out. How do you tell Windows to do that? Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Email addresses in PEPs?
[EMAIL PROTECTED] wrote: > Trent> If some would find it useful, here is a snippet of code that > Trent> obfuscates email addresses for HTML as done by Markdown (a > Trent> text-to-html markup translator). It randomly encodes each > Trent> charater as a hex or decimal HTML entity (roughly 10% raw, 45% > Trent> hex, 45% dec). > > Aren't most spammers' scrapers going to be intelligent enough by now > (several years since they first arrived on the scene) to "see through" these > sorts of common obfuscations? Perhaps, yes. No way of really knowing. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Email addresses in PEPs?
David Goodger wrote:
> On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> I believe email addresses are automatically obfuscated as part of the
>> HTML generation process, but one of the PEP editors can correct me if
>> I am wrong.
>
> Yes, email addresses are obfuscated in PEPs.
>
> For example, in PEPs 0 & 12, my address is encoded as
> "goodger at python.org" (the "@" is changed to " at " and
> further obfuscated from there). More tricks could be played, but that
> would only decrease the usefulness of addresses for legitimate
> purposes.
If some would find it useful, here is a snippet of code that obfuscates
email addresses for HTML as done by Markdown (a text-to-html markup
translator). It randomly encodes each charater as a hex or decimal HTML
entity (roughly 10% raw, 45% hex, 45% dec).
The email still appears normally in the browser, but is pretty obtuse
when slicing and dicing the raw HTML.
Would others find this useful in pep2html.py?
---
from random import random
def _encode_email_address(self, addr):
# Input: an email address, e.g. "[EMAIL PROTECTED]"
#
# Output: the email address as a mailto link, with each character
# of the address encoded as either a decimal or hex entity, in
# the hopes of foiling most address harvesting spam bots. E.g.:
#
#foo@exa
# mple.com
#
# Based on a filter by Matthew Wickline, posted to the BBEdit-Talk
# mailing list: <http://tinyurl.com/yu7ue>
chars = [_xml_encode_email_char_at_random(ch)
for ch in "mailto:"; + addr]
# Strip the mailto: from the visible part.
addr = '%s' \
% (''.join(chars), ''.join(chars[7:]))
return addr
def _xml_encode_email_char_at_random(ch):
r = random()
# Roughly 10% raw, 45% hex, 45% dec.
# '@' *must* be encoded. I [John Gruber] insist.
if r > 0.9 and ch != "@":
return ch
elif r < 0.45:
# The [1:] is to drop leading '0': 0x63 -> x63
return '&#%s;' % hex(ord(ch))[1:]
else:
return '&#%s;' % ord(ch)
---
--
Trent Mick
trentm at activestate.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping support for Win9x
Martin v. Löwis wrote: > I'd like to remove support for Windows 9x (95, 98(SE), ME) > soon from the Python trunk. This would primarily affect all > wide-string APIs (which would be considered present > unconditionally), as well as certain "new" Win32 functions; > in this cleanup, I would also drop support for NT+ before > Windows 2000 (i.e. NT 3.1, 3.5(1), 4.0). > > I'm not sure whether w9xpopen should be left in place; Tim > suggested it should, however, I don't see why (something > with alternative command line interpreters IIRC). I'm not entirely sure, but I think that w9xpopen gets used when it looks like the shell (as per %ComSpec%) is command.com rather than cmd.exe. My understanding is that a Win9x machine *upgraded* (rather than a clean re-install) to Win2k or XP will retain command.com as the %ComSpec% setting. If so, that *might* be sufficient reason to keep w9xpopen around. I don't have a strong opinion though: I'm all for dropping win9x support and would be happy with either a doc note that users need to ensure they aren't using command.com, or a warning in the installer if this is detected. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Thomas Heller wrote: >>> Are there others that can provide a Windows buildbot? It would probably >>> be good to have two -- and a WinXP one would be good. >> It certainly would be good. Unfortunately, Windows users are not that >> much engaged in the open source culture, so few of them volunteer >> (plus it's more painful, with Windows not being a true multi-user >> system). > > I'll try to setup a buildbot under WinXP. > Whom do I contact to get HOST:PORT and PASSWORD ? Martin, I believe. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
> I'm not quite a '-1', but am a little confused about where this would leave > us. To some extent, this would formalize PCBuild8 and VC6 directories. > External tools would then slowly start growing support for these additional > directories and the previous benefits of "PCBuild is the canonical location" > appear to vanish. Further, I expect that such a patch would confuse any > attempts to manually copy from PCBuild8 into PCBuild, for example (ie, some > tools knowing about PCBuild8 while others assume PCBuild is likely to get > confusing.) > > Trent: I assume you use the same source tree for multiple platforms and > compilers, meaning that changing these "optional" build processes to copy > from PCBuild8/VC6 into PCBuild would cause pain? If not, do you think that > would be a reasonable solution? Changing to have bits always in PCbuild would work for me -- i.e. I *don't* build for multiple compilers/platforms in the same tree. Perhaps that is a better solution -- in the long run, anyway. Having the "bits" always in one dir for whatever the configuration is more akin to the Unix-y configure/make system. Is this something that could work for Python 2.5? Or just 2.6? Long term/aside: Moving to a configure/make build system on Windows, as you proposed in your first email, would be interesting. With MSYS though, not cygwin (a la bsmedberg's new MozillaBuild stuff). I just wish there were an autoconf alternative that wasn't as painful as autoconf. I have a few attempts for my purposes that are written in Python (an obvious bootstrapping problem for building Python itself :). Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
Martin v. Löwis wrote: >> I use this patch in ActivePython to get distutils to find the correct >> PCbuild dir (see attached). > > Would you like to commit this to 2.6? (or perhaps 2.5 even?) Sure, if others think it is a good thing. Will do tomorrow unless I hear a -1 before then. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
It seems the
best thing might be to modify the PCBuild8 build process so the output
binaries are in the ../PCBuild' directory - this way distutils and others
continue to work fine. Does that sound reasonable?
I think Kristjan will have to say a word here: I think he just likes
it the way it is right now. That would rather suggest that build_ext
needs to be changed.
I use this patch in ActivePython to get distutils to find the correct
PCbuild dir (see attached).
Trent
--
Trent Mick
trentm at activestate.com
--- python/Lib/distutils/command/build_ext.py Tue Mar 13 03:19:35 2007
+++ python/Lib/distutils/command/build_ext.py Tue Apr 17 12:51:26 2007
@@ -176,7 +176,16 @@
# Append the source distribution include and library directories,
# this allows distutils on windows to work in the source tree
self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC'))
-self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCBuild'))
+from distutils.msvccompiler import get_build_version
+msvc_version = get_build_version()
+if msvc_version == 6:
+self.library_dirs.append(os.path.join(sys.exec_prefix, 'PC',
'VC6'))
+elif 6 < msvc_version < 8:
+self.library_dirs.append(os.path.join(sys.exec_prefix,
'PCbuild'))
+elif msvc_version >= 8:
+self.library_dirs.append(os.path.join(sys.exec_prefix,
'PCbuild8'))
+else:
+log.warn("unexpected MSVC version: %r", msvc_version)
# OS/2 (EMX) doesn't support Debug vs Release builds, but has the
# import libraries in its "Config" subdirectory
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Trent Mick wrote: > It has been a while since I set it up. Tim did so at about the same time > and wrote down his steps to setup... but I can't find the reference to > those instructions right now. http://wiki.python.org/moin/BuildbotOnWindows If you run into problems setting it up, feel free to ping me. chat: (Gtalk/Jabber) [EMAIL PROTECTED] > > I've found maintenance to be low -- just have to have to start a cmd > shell and run the buildbot slave command. I believe MarkH posted some notes on getting a buildbot Windows slave running as a service as well, but I didn't try that. Getting that working easily could help cut down on the maintenance. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
[MarkH] >> I'm guessing vsextcomp doesn't use the Visual >> Studio 'ReleaseAMD64' configuration - would it be OK for me to check in >> changes to the PCBuild projects for this configuration? > [Martin v. Löwis] > Please don't. It exclusively relies on vsextcomp, and is only useful > if you have that infrastructure installed. See for yourself: it uses > the /USE_CL:MS_OPTERON command line switch, which isn't a Microsoft > invention (but instead invented by Peter Tröger). Aside: it isn't my experience that vsextcomp is necessary to cross-compile for AMD64 and IA64. My cross-build process basically equates to: - Run the appropriate environment setup for the correct compiler. E.g., for the Platform SDK AMD64 compiler and with the current Platform SDK this is: C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd /X64 /RETAIL - Run the solution file with "devenv.com" (IIRC, devenv.exe doesn't take command-line args) and be sure to pass ing "/useenv" to pick up the environment changes. (*) set DEVENV_COM=path/to/devenv.com %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 (*) Note that for a cross-build the "make_versioninfo" and "make_buildinfo" projects need to be built natively first: "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 /project make_versioninfo %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 /project make_buildinfo This is all VS7.1, though. I don't yet know if VS8 throws a spanner into the works. For VS6 I use "msdev" instead of "devenv.com" and "PC\VC6\pcbuild.dsw" instead of "PCbuild\pcbuild.sln". I haven't looked into what vsextcomp does, so apologies if this is ignorant. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Thomas Heller wrote: >> Are there others that can provide a Windows buildbot? It would probably >> be good to have two -- and a WinXP one would be good. > > How much work is it to set one up, and to maintain it? Maybe I can offer an > XP VMWare image. It has been a while since I set it up. Tim did so at about the same time and wrote down his steps to setup... but I can't find the reference to those instructions right now. I've found maintenance to be low -- just have to have to start a cmd shell and run the buildbot slave command. However, that may be because the box on which it is running isn't one I use regularly, so I don't have to worry about accidentally killing the process, frequent reboots or anything like that. I'll try to dig around and see what I can find for setup instructions. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk Is my buildbot the only reliable Windows buildbot machine? It is possible that within a couple of weeks or so I'll have to take this one offline. Are there others that can provide a Windows buildbot? It would probably be good to have two -- and a WinXP one would be good. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
Steven Bethard wrote:
> On 5/2/07, Michael Foord <[EMAIL PROTECTED]> wrote:
>> Implicit string concatenation is massively useful for creating long
>> strings in a readable way though:
>>
>> call_something("first part\n"
>>"second line\n"
>> "third line\n")
>>
>> I find it an elegant way of building strings and would be sad to see it
>> go. Adding trailing '+' signs is ugly.
>
> You'll still have textwrap.dedent::
>
> call_something(dedent('''\
> first part
> second line
> third line
> '''))
>
> And using textwrap.dedent, you don't have to remember to add the \n at
> the end of every line.
But if you don't want the EOLs? Example from some code of mine:
raise MakeError("extracting '%s' in '%s' did not create the "
"directory that the Python build will expect: "
"'%s'" % (src_pkg, dst_dir, dst))
I use this kind of thing frequently. Don't know if others consider it
bad style.
Trent
--
Trent Mick
trentm at activestate.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ok to just checkin minor obvious fixes?
Is it generally accepted to just checkin obviously non-controversial fixes (*) (as long as there is no code freeze), or is it still preferred that I go through adding a patch to the SF tracker and getting review? Trent (*) In my case a tweak to the old VC6 Windows build files to ensure a clean build works (_ctypes project must depend on pythoncore proj). -- Trent Mick trentm at activestate.com ___ 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] About SSL tests
Steven Bethard wrote: > Another difference I believe is that TerminateProcess on Windows > doesn't kill the tree of processes like kill would. It would be nice > if Popen.terminate() did the same thing on both Unix and Windows. (I > assume that would mean making *all* the appropriate TerminateProcess > calls.) Possibly that should be kept separate and handled via eventual handling for process jobs: http://msdn2.microsoft.com/en-us/library/ms684161.aspx > A job object allows groups of processes to be managed as a unit. Job objects > are namable, securable, sharable objects that control attributes of the > processes associated with them. Operations performed on the job object affect > all processes associated with the job object. > > ... > To terminate all processes currently associated with a job object, use the > TerminateJobObject function. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] About SSL tests
Christian Heimes wrote:
>> I'd be willing to look at adding it, if the group thinks it's the right
>> thing to do.
>
> I like the idea and I'm proposing to add two more methods to subprocess
> Popen.
>
> class Popen(...):
> ...
> def signal(self, signal):
> """Send a signal to the process (UNIX only)
>
> signal is constant from the signal module
> """
>
> def terminate(self, force=False):
> """Terminate the process
>
> On UNIX terminate(False) is equivalent to signal(SIGTERM) and
> terminate(True) to signal(SIGKILL).
>
> On Windows ... (does Windows support a forced terminate?)
> """
Here is what my process.py [1] does for termination (not suggesting you
follow the API here, just showing how it handles termination on
Windows). Some of the Windows logic is borrowed from PyWin32's
winprocess.py [2]
> def kill(self, exitCode=0, gracePeriod=1.0, sig=None):
> """Kill process.
>
> "exitCode" [deprecated, not supported] (Windows only) is the
> code the terminated process should exit with.
> "gracePeriod" (Windows only) is a number of seconds the process is
> allowed to shutdown with a WM_CLOSE signal before a hard
> terminate is called.
> "sig" (Unix only) is the signal to use to kill the process. Defaults
> to signal.SIGKILL. See os.kill() for more information.
>
> Windows:
> Try for an orderly shutdown via WM_CLOSE. If still running
> after gracePeriod (1 sec. default), terminate.
> """
> if sys.platform.startswith("win"):
> import win32gui
> # Send WM_CLOSE to windows in this process group.
> win32gui.EnumWindows(self._close_, 0)
>
> # Send Ctrl-Break signal to all processes attached to this
> # console. This is supposed to trigger shutdown handlers in
> # each of the processes.
> try:
> win32api.GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT,
> self._processId)
> except AttributeError:
> log.warn("The win32api module does not have "\
> "GenerateConsoleCtrlEvent(). This may mean that "\
> "parts of this process group have NOT been killed.")
> except win32api.error, ex:
> if ex.args[0] not in (6, 87):
> # Ignore the following:
> # api_error: (87, 'GenerateConsoleCtrlEvent', 'The
> parameter is incorrect.')
> # api_error: (6, 'GenerateConsoleCtrlEvent', 'The
> handle is invalid.')
> # Get error 6 if there is no console.
> raise
>
> # Last resort: call TerminateProcess if it has not yet.
> retval = 0
> try:
> self.wait(gracePeriod)
> except ProcessError, ex:
> log.info("[%s] Process.kill: calling TerminateProcess",
> id(self))
> win32process.TerminateProcess(self._hProcess, -1)
> win32api.Sleep(100) # wait for resources to be released
>
> else:
> if sig is None:
> sig = signal.SIGKILL
> try:
> os.kill(self._pid, sig)
> except OSError, ex:
> if ex.errno != 3:
> # Ignore: OSError: [Errno 3] No such process
> raise
Links:
[1] http://trentm.com/projects/process/
[2]
http://pywin32.cvs.sourceforge.net/pywin32/pywin32/win32/Demos/winprocess.py?revision=1.2&view=markup#l_121
--
Trent Mick
trentm at activestate.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
Guido van Rossum wrote: > If you ask me, having it hosted by Trent is probably more helpful for > its popularity than putting it in the Python source distro; the Tools > directory is mostly a poorly-maintained collection of trivia I wrote > many years ago that is now quietly gathering dust. > > (Not all of it, of course; there's some useful stuff there that I > *didn't* write, which ended up there because it is either *used* by > the distro (e.g. the compiler package support) or because the author > needed a channel that guaranteed open source status (e.g. world and > pynche). But Trent's which.py doesn't seem to fall in either > category.) Agreed. However, I think my which.py might be a good candidate for the stdlib (for Py2.6) as per python.org/sf/1509798 and could put together a patch (along with test suite integrate and docs) if others think it worthwhile. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Brett Cannon wrote: > > > The idea is that there be a separate Python interpreter per web > > > browser page instance. > > > I think there may be scaling issues there. JavaScript isn't doing that > > is it, do you know? As well, that doesn't seem like it would translate > > well to sharing execution between separate chrome windows in a > > non-browser XUL/Mozilla-based app. > > And if you don't think it is going to scale, how do you think it should > be done? That was an ignorant response (I haven't read what you've suggested and really though about it). Sorry for the unsubstantiated babbling. To Bob's question on how much interpreter state *is* there: I don't know. Have you done any measuring of that, Brett? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Brett Cannon wrote: > The plan is to allow pure Python code to be embedded into web pages like > JavaScript. ... > ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so > getting Python compiled right into Firefox itself shouldn't be too bad. > > If this really takes off, will probably want both: get into Firefox, but have > an extension for pre-existing installations. You should really speak with Mark, if you haven't recently. He's gotten a lot further than just PyXPCOM. My understanding (I might be a bit off on the branches and timing) is that his "DOM_AGNOSTIC" work on the Mozilla code has mostly been checked into the trunk. This work is to do mostly what you are describing: Python as a client-side scripting language along-side JavaScript. I can't recall what Mozilla's distribution plans are for this. Certainly it wouldn't be before Firefox 3. Then again, default Firefox builds would like not include Python by default. It sounds to me that a restricted-execution/security-model story for Python would be important here. Mark (and me a little bit) has been sketching out creating a "Python for Mozilla/Firefox" extension for installing an embedded Python into an existing Firefox installation on the pyxpcom list: http://aspn.activestate.com/ASPN/Mail/Message/pyxpcom/3167613 > The idea is that there be a separate Python interpreter per web browser page > instance. I think there may be scaling issues there. JavaScript isn't doing that is it, do you know? As well, that doesn't seem like it would translate well to sharing execution between separate chrome windows in a non-browser XUL/Mozilla-based app. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)
POINTER_c_char (ctypes.test.test_stringptr.StringPtrTestCase) ... ok > test__c_char_p (ctypes.test.test_stringptr.StringPtrTestCase) ... ok > test_functions (ctypes.test.test_stringptr.StringPtrTestCase) ... ok > test (ctypes.test.test_strings.StringArrayTestCase) ... ok > test_c_buffer_raw (ctypes.test.test_strings.StringArrayTestCase) ... ok > test_c_buffer_value (ctypes.test.test_strings.StringArrayTestCase) ... ok > test_param_1 (ctypes.test.test_strings.StringArrayTestCase) ... ok > test_param_2 (ctypes.test.test_strings.StringArrayTestCase) ... ok > test (ctypes.test.test_strings.WStringArrayTestCase) ... ok > test_wchar (ctypes.test.test_strings.WStringTestCase) ... ok > test_1_A (ctypes.test.test_struct_fields.StructFieldsTestCase) ... ok > test_1_B (ctypes.test.test_struct_fields.StructFieldsTestCase) ... ok > test_2 (ctypes.test.test_struct_fields.StructFieldsTestCase) ... ok > test_3 (ctypes.test.test_struct_fields.StructFieldsTestCase) ... ok > test_4 (ctypes.test.test_struct_fields.StructFieldsTestCase) ... ok > test (ctypes.test.test_structures.PointerMemberTestCase) ... ok > test_abstract_class (ctypes.test.test_structures.StructureTestCase) ... ok > test_emtpy (ctypes.test.test_structures.StructureTestCase) ... ok > test_fields (ctypes.test.test_structures.StructureTestCase) ... ok > test_init_errors (ctypes.test.test_structures.StructureTestCase) ... ok > test_initializers (ctypes.test.test_structures.StructureTestCase) ... ok > test_intarray_fields (ctypes.test.test_structures.StructureTestCase) ... ok > test_invalid_field_types (ctypes.test.test_structures.StructureTestCase) ... > ok > test_keyword_initializers (ctypes.test.test_structures.StructureTestCase) ... > ok > test_methods (ctypes.test.test_structures.StructureTestCase) ... ok > test_nested_initializers (ctypes.test.test_structures.StructureTestCase) ... > ok > test_packed (ctypes.test.test_structures.StructureTestCase) ... ok > test_simple_structs (ctypes.test.test_structures.StructureTestCase) ... ok > test_struct_alignment (ctypes.test.test_structures.StructureTestCase) ... ok > test_structures_with_wchar (ctypes.test.test_structures.StructureTestCase) > ... ok > test_unions (ctypes.test.test_structures.StructureTestCase) ... ok > test_subclass (ctypes.test.test_structures.SubclassesTest) ... ok > test_subclass_delayed (ctypes.test.test_structures.SubclassesTest) ... ok > test_native (ctypes.test.test_unaligned_structures.TestStructures) ... ok > test_swapped (ctypes.test.test_unaligned_structures.TestStructures) ... ok > test_ascii_ignore (ctypes.test.test_unicode.StringTestCase) ... ok > test_ascii_replace (ctypes.test.test_unicode.StringTestCase) ... ok > test_ascii_strict (ctypes.test.test_unicode.StringTestCase) ... ok > test_buffers (ctypes.test.test_unicode.StringTestCase) ... ok > test_latin1_strict (ctypes.test.test_unicode.StringTestCase) ... ok > test_ascii_ignore (ctypes.test.test_unicode.UnicodeTestCase) ... ok > test_ascii_replace (ctypes.test.test_unicode.UnicodeTestCase) ... ok > test_ascii_strict (ctypes.test.test_unicode.UnicodeTestCase) ... ok > test_buffers (ctypes.test.test_unicode.UnicodeTestCase) ... ok > test_latin1_strict (ctypes.test.test_unicode.UnicodeTestCase) ... ok > test_an_integer (ctypes.test.test_values.ValuesTestCase) ... ok > test_undefined (ctypes.test.test_values.ValuesTestCase) ... ok > test_array_invalid_length (ctypes.test.test_varsize_struct.VarSizeTest) ... ok > test_resize (ctypes.test.test_varsize_struct.VarSizeTest) ... ok > test_vararray_is_sane (ctypes.test.test_varsize_struct.VarSizeTest) ... ok > test_varsized_array (ctypes.test.test_varsize_struct.VarSizeTest) ... ok > test_zerosized_array (ctypes.test.test_varsize_struct.VarSizeTest) ... ok > test_struct_by_value (ctypes.test.test_win32.Structures) ... ok > > == > ERROR: test_find (ctypes.test.test_loading.LoaderTest) > -- > Traceback (most recent call last): > File "/Users/trentm/src/python/Lib/ctypes/test/test_loading.py", line 41, > in test_find > cdll.LoadLibrary(lib) > File "/Users/trentm/src/python/Lib/ctypes/__init__.py", line 372, in > LoadLibrary > return self._dlltype(name) > File "/Users/trentm/src/python/Lib/ctypes/__init__.py", line 290, in > __init__ > self._handle = _dlopen(self._name, mode) > OSError: dlcompat: unable to open this file with RTLD_LOCAL > > == > ERROR: test_load (ctypes.test.test_loading.LoaderTest) > ------ > Traceback (most recent call last): > File "/Users/trentm/src/python/L
Re: [Python-Dev] beta1 coming real soon
Trent Mick wrote: > Trent Mick wrote: >> * [ 1462338 ] upgrade pyexpat to expat 2.0.0 >>http://python.org/sf/1462338 >> >> * [ 1295808 ] expat symbols should be namespaced in pyexpat >>http://python.org/sf/1295808 > > These are in now. I don't see any failures yet, either on the buildbots > or on the Windows/Linux/Mac OS X boxes I tested on. It looks like this broke the x86 cygwin build: http://python.org/dev/buildbot/trunk/x86%20cygwin%20trunk/builds/859/step-test/0 > gcc -shared -Wl,--enable-auto-image-base > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlparse.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlrole.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmltok.o > -L/usr/local/lib -L. -lpython2.5 -o > build/lib.cygwin-1.5.19-i686-2.5/pyexpat.dll > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o: > In function `set_error': > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:126: > undefined reference to `_XML_GetCurrentLineNumber' > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:127: > undefined reference to `_XML_GetCurrentColumnNumber' > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:131: > undefined reference to `_XML_ErrorString' > ... I don't have this environment setup right now, though I'll try to check in the morning if someone hasn't beaten me to it. (Showing my ignorance here and grasping at straws: this wouldn't be because of some extern C-name-mangling-with-underscore-prefix thing would it?) Modules/pyexpat.c:5 #include "expat.h" Modules/expat/expat.h:18 #include "expat_external.h" Modules/expat/expat_external.h:12 #include "pyexpatns.h" Modules/expat/pyexpatns.h:52 #define XML_GetCurrentLineNumberPyExpat_XML_GetCurrentLineNumber I don't see where the disconnect is. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Trent Mick wrote: > * [ 1462338 ] upgrade pyexpat to expat 2.0.0 >http://python.org/sf/1462338 > > * [ 1295808 ] expat symbols should be namespaced in pyexpat >http://python.org/sf/1295808 These are in now. I don't see any failures yet, either on the buildbots or on the Windows/Linux/Mac OS X boxes I tested on. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
[Neal Norwitz wrote on June 8th] > It's June 9 in most parts of the world. The schedule calls for beta 1 > on June 14. That means there's less than 4 days until the expected > code freeze. Please don't rush to get everything in at the last > minute. The buildbots should remain green to keep Anthony happy and > me sane (or is it the other way around). > > If you plan to make a checkin adding a feature (even a simple one), > you oughta let people know by responding to this message. Please get > the bug fixes in ASAP. Remember to add tests! [and then Anthony Baxter wrote today] > Subject: TRUNK FREEZE IMMINENT FOR 2.5 BETA 1 - 00:00 UTC,20-JUNE-2006 > > The trunk will be FROZEN for 2.5b1 from 00:00UTC on Tuesday, 20th of > June. That's about 16 hours from now. Please don't checkin while the > trunk is frozen, unless you're one of the release team (me, Martin, > Fred, Ronald). Can I, or will I be able to get these PyExpat fixes? * [ 1462338 ] upgrade pyexpat to expat 2.0.0 http://python.org/sf/1462338 * [ 1295808 ] expat symbols should be namespaced in pyexpat http://python.org/sf/1295808 The second one is that one I care about (and is well tested in Komodo on four platforms). It will be very important to have that one in the Python/Mozilla world (which with Mark Hammond's recent work for mozilla.org -- making Python a first class language in the browser along with JavaScript) because this namespacing is required to avoid crashing conflicts with another version of the expat symbols in the mozilla process. Martin v. L. wanted the namespacing fix to be preceded by the upgrade to expat 2.0.0 -- which I have a patch for also. I haven't checked in yet, because I dropped the ball for a few weeks here. I'm going to start working on checking it in right now and will probably just go for it (because I have a few hours until Anthony's deadline ;)) unless I hear some screams. Honestly I didn't intentionally wait until the pending trunk-freeze email came. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "mick-windows" buildbot uptime
We've pretty much gotten settled into our new diggs at work here (ActiveState) so my Windows buildbot machine should have better uptime from now on. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Tim Peters wrote] > In fact, that reminds me I added a "delete all the .pyc files" step to > the Windows buildbot clean.bat precisely so I didn't have to burn time > and space backing up 1600 stale files each day. So -0 on changing. Good enough for me. Let's not bother. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Neal Norwitz wrote] > On 4/10/06, Trent Mick <[EMAIL PROTECTED]> wrote: > > > > Sorry that I took so long to run this. It is a little unfortunate that > > with the last build step being "clean", I couldn't just cd into the > > build directory and try to run this. > > Maybe we should clean before we configure/compile? That would leave > the last build in tact until the next run. Sure. Have to make sure that it doesn't choke on the bootstrapping problem: the first time there is no "Makefile" with which to call "make clean". Then again, maybe it is a good thing that one is discouraged from poking around in a buildbot build tree (potentially leaving turds that taint future builds). Thoughts? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Tim Peters wrote]
> Trent (and anyone else who wants to play along), what happens if you
> do this by hand in a current trunk or 2.4 build?:
>
> import socket
> s = socket.socket()
> s.settimeout(30.0)
> s.connect(("gmail.org", 995))
>
> On my box (when gmail.org:995 responds at all), the connect succeeds
> in approximately 0.03 seconds, giving 29.97 seconds to spare ;-)
C:\trentm\src\python\python\PCbuild>python_d
Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
[25133 refs]
>>> s = socket.socket()
[25145 refs]
>>> s.settimeout(30.0)
[25145 refs]
>>> s.connect(("gmail.org", 995))
[25145 refs]
>>>
Sorry that I took so long to run this. It is a little unfortunate that
with the last build step being "clean", I couldn't just cd into the
build directory and try to run this.
Seems like that was a good thing that I did take so long because it
passed in the most recent build :)
http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/371/step-test/0
> Can you identify a reason for why it times out on the Win2K buildbot?
> (beats me -- firewall issue, DNS sloth, ...?)
It is possible that this was due to network changes that we are doing at
work here. We are preparing for an office move in a couple of weeks
(http://blogs.activestate.com/activestate/2006/02/free_as_in_will.html).
My eyes glaze over whenever the systems dudes mention VPN, SSH, DNS,
VMWare, sub-domains and DHCP in the same breath.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] updating PyExpat (Was: need info for externally maintained modules PEP)
[Martin v. Loewis wrote] > Brett Cannon wrote: > > - expat > > Not sure whether you mean the Expat parser proper here, or the pyexpat > module: both are externally maintained, also; pyexpat is part of PyXML. > OTOH, people can just consider PyXML to be part of Python, and I > synchronize the Python sources with the PyXML sources from time to time. I was going to be updating Modules/expat/... to Expat 2.0 relatively soon. Must I then go via the PyXML folks to do this update then or can I checkin to Python's SVN directly? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Thomas Wouters suggested "import ... or" syntax] > or is that all going too far? :) Yes. It is overkill. The number of different ways to import ElementTree is perhaps unfortunate but it is a mostly isolated incident: effbot providing pure and c versions, it being popular and hence having other implementations *and* quickly getting into the core. The original issue was that the various import paths to ElementTree are a little confusing. Adding "or" syntax doesn't change that. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Fredrik Lundh wrote]
> Trent Mick wrote:
>
> > That is the current state.
>
> which reminds that maybe it's time to add an import helper to
> the standard library, so you can do
>
> stringio = import_search("cStringIO", "StringIO")
> ET = import_search("lxml.etree", "cElementTree", "xml.etree.cElementTree")
> db = import_search("superdb", "sqlite3", "fancydb", "dumbdb")
To the 'imp' module? Hrm, would then maybe want to change the docs from:
3.21 imp -- Access the import internals
to
3.21 imp -- Access the import internals and some other useful importing
stuff
:)
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
[Martijn Faassen wrote]
> I.e., this in ElementTree:
> ...
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/475126
import ElementTree from everywhere
try:
import xml.etree.ElementTree as ET # in python >=2.5
except ImportError:
try:
import cElementTree as ET # effbot's C module
except ImportError:
try:
import elementtree.ElementTree as ET # effbot's pure Python
module
except ImportError:
try:
import lxml.etree as ET # ElementTree API using libxml2
except ImportError:
import warnings
warning.warn("could not import ElementTree "
"(http://effbot.org/zone/element-index.htm)")
# Or you might just want to raise an ImportError here.
# Use ET.Element, ET.ElementTree, etc...
That is the current state.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] current 2.5 status
[Tim Peters wrote] > Trent, FYI, on my box the invariable cause for > > LINK : fatal error LNK1104: cannot open file './python25_d.dll' > > in a failed buildbot Windows compile step is that some previous run > left behind a python_d.exe process that won't go away. I don't know > why it won't go away on its own, or how it gets into that state, but I > do know that once it happens it never fixes itself. You have to find > the python_d process(es) and kill it yourself. Then the buildbot > dance works fine again. In this case it was because python_d.exe crashed and Windows then popped up a system modal dialog to tell me: hanging the process. I wonder if it would be possible to write a "reaper" script that used some combination of EnumWindows, SendKeys, the Performance Monitoring APIs (Pdh* function) and some elbow grease to click these crash dialogs away. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Firefox searchbar engine for Python bugs
[Anthony Baxter wrote] > I've created a searchbar plugin for the firefox search bar that allows > you to search bugs. I think someone created one for the sidebar http://starship.python.net/~skippy/mozilla/ http://projects.edgewall.com/python-sidebar/ Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP to list externally maintained modules and where to report bugs?
[Brett Cannon wrote] > Anyone else think we need a PEP to point to places where externally > maintained code should have bugs or patches reported? I don't want to > hunt down a URL for where to do this every time and so it would be > nice to have a list of what code needs bugs/patches reported where. > Otherwise I am prone to just check my changes into the tree and not > get them reported upstream since I want the warnings to go away. =) +1 Perhaps that could be merged with generic "how to report a bug" instructions. This might be helpful for a start: http://producingoss.com/html-chunk/bug-reporting.html Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 for AMD64 (Windows)
[Thomas Heller wrote] > Linking... >Creating library .\./python25.lib and object .\./python25.exp > zipimport.obj : error LNK2001: unresolved external symbol __security_cookie > traceback.obj : error LNK2001: unresolved external symbol __security_cookie > typeobject.obj : error LNK2001: unresolved external symbol __security_cookie > unicodeobject.obj : error LNK2001: unresolved external symbol > __security_cookie > > (lots of similar errors...) I have this patch to the python 2.4 sources to get win64-ia64 to build (that I haven't yet had the chance to submit to SF). I think it will require a little massaging for the trunk. Does this work for you? Trent -- Trent Mick [EMAIL PROTECTED] diff Must link with bufferoverflowU.lib for Win64 builds of some binaries with the latest Platform SDK to avoid errors a la (c.f. http://support.microsoft.com/?id=894573): 'unresolved external symbol __security_cookie' errors. diff -ur python/PCbuild.original/_bsddb.vcproj python/PCbuild/_bsddb.vcproj --- python/PCbuild.original/_bsddb.vcproj Thu Aug 12 07:07:49 2004 +++ python/PCbuild/_bsddb.vcprojThu Jun 02 16:41:43 2005 @@ -179,7 +179,7 @@ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pyexpat namespace problem (Was: libbzip2 version?)
[Martin v. Loewis wrote] > Trent Mick wrote: > > I'm testing my patch to the trunk right now to make sure it passes > > everything. If you all think this is a good idea I could apply it and > > then also give a go an upgrading out expat version (I haven't looked at > > whether that would be very difficult). > > I would like to see an update to the current Expat release before that. Okay. I'll see if I can try that tomorrow. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pyexpat namespace problem (Was: libbzip2 version?)
[Trent Mick wrote] > I'm testing my patch to the trunk right now to make sure it passes > everything. If you all think this is a good idea I could apply it and > then also give a go an upgrading out expat version (I haven't looked at > whether that would be very difficult). "give a go at upgrading our (i.e. Python's) expat version" Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pyexpat namespace problem (Was: libbzip2 version?)
[Georg Brandl wrote] > There seems to be a new version of expat too: http://python.org/sf/1433435 > > The namespace problem with pyexpat persists: http://python.org/sf/1295808 http://python.org/sf/1295808 [My lastest comment to that bug] > As Neal points out this is a duplicate of > <http://python.org/sf/1075984>. The patch on *that* bug > fixes the specific issue, but does not solve the general > problem (as Michael, 'mwh', pointed out in the comments > there). > > I think we should > 1. apply this patch > 2. then perhaps update our expat version (see >http://python.org/sf/1433435, >http://mail.python.org/pipermail/python-dev/2006-March/062287.html), > 3. then update Modules/expat/pyexpatns.h (that this patch >adds) for any new symbols in the new version of Expat. I'm testing my patch to the trunk right now to make sure it passes everything. If you all think this is a good idea I could apply it and then also give a go an upgrading out expat version (I haven't looked at whether that would be very difficult). Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
> Fredrik Lundh wrote: > > a) sys.executable points to the executable that was used to load the > > Python interpreter library/dll. > > > > this use is supported by the docstring and the implementation, and is > > quite > > common in the wild. an application using this interpretation may > > > > - call sys.executable to run another instance of itself > > - extract data from resources embedded in (or attached to) > > sys.executable > > - locate configuration data etc via os.path.dirname(sys.executable) > > > > etc. [Thomas Heller wrote] > py2exe used the a) interpretation. It uses sys.executable to find the exe > that is currently > running, for registration of COM servers, and for finding resources in the > exe: the manifest > file that's needed for GUI applications on WindowsXP to give the native XP > look and feel, > icons, typelibs, and more. > > The use case for b) 'call sys.executable to run a Python script' makes no > sense for > a py2exe'd application. Ditto on both counts for PyXPCOM (Python embedded in Mozilla). Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Trent Mick wrote] > [Martin v. Loewis wrote] > > Tim Peters wrote: > > > I'd say instead that they should never be skipped: the real > > > difference on your box is the expected _outcome_ in the third > > > category. > > > > That is indeed more reasonable than what I proposed. > > I'll do this tonight or tomorrow. Done now (finally). Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecated modules going away in 2.5
[Neal Norwitz wrote] > In addition, I will swap sre and re. This will make help(re) work properly. Yay! Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
> Martin v. L?wis wrote: > > So PythonWin needs to be installed on a Windows buildbot slave, right? PyWin32 you mean. PythonWin is the IDE-thing that is part of PyWin32. [Fredrik Lundh wrote] > unless someone hacks Twisted to use _subprocess.TerminateProcess > instead of the win32all version... +1 Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] >... > I see that your Win2K buildbot slave always dies in the compile step now, with > > """ > -- Build started: Project: pythoncore, Configuration: Debug Win32 -- > > Compiling resources... > generate buildinfo > cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL > -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include > -I..\PC > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. > getbuildinfo.c > Linking... > LINK : fatal error LNK1104: cannot open file './python25_d.dll' > """ > > That happened to me once, but I still don't understand it. It turned > out that the corresponding python_d.exe was still running (for hours, > and hours, and hours, ...), and I had to manually kill the process. > I'm not sure that was enough, because I coincidentally rebooted the > box before the buildbot tests ran again. I am pretty sure that the > symptom above won't fix itself. Yes I've noticed it too. I've had to kill python_d.exe a few times. I haven't yet had the chance to look into it. I am NOT getting this error on another Windows Python build slave that I am running in-house for play. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Martin v. Loewis wrote] > Tim Peters wrote: > > I'd say instead that they should never be skipped: the real > > difference on your box is the expected _outcome_ in the third > > category. > > That is indeed more reasonable than what I proposed. I'll do this tonight or tomorrow. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Mark Hammond wrote] > Maybe the following VBScript "port" of the above will work: > ... Cool, yes that works. > Running "cscript.exe check_soundcard.vbs" and checking the return code > should work. cscript.exe comes with all modern Windows variants, and > although there may be ways to install Windows without it, I think we can > safely assume it exists for these purposes. I have a patch in the works that defaults to "yes, this machine does have a soundcard" if cscript.exe cannot be found on the PATH. However, one wrinkle: test_winsound.py is made up of three test cases: BeepTest MessageBeepTest PlaySoundTest only the last need be skipped if there is not soundcard. However, TestSkipped only works add the module level. So, which is better: 1. Use TestSkipped and skip all three test cases if there is not sound card. Running the test suite will actually show that something is being skipped. 2. Conditionally define class PlaySoundTest only if there is a soundcard. Running the test suite on a machine without a soundcard will not show that something is being skipped but *will* run the Beep tests. 3. Break out test_winsound.py into two test modules: one with the beep tests and one with PlaySoundTest (the latter using TestSkipped). Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Martin v. Loewis wrote]
> Trent Mick wrote:
> > I do have a sound card in that box, however, the "Sounds and Multimedia
> > Properties" dialog (off Control Panel) says that there are "No Playback
> > Devices" for Sound Playback. So I guess that is it. Maybe the sound card
> > in that box is not hooked up. Grrr. I certainly don't care about the
> > sound card for that box but I don't want the test suite to keep
> > reporting a spurious failure.
>
> Now, if there was a reliable check whether a soundcard is present, that
> check could be run as a prerequisite, then raising TestSkipped if no
> soundcard is present.
Roger on python-win32 had an answer which works for me:
[Roger Upole wrote]
> WMI can list sound devices.
>
> import win32com.client
> wmi=win32com.client.GetObject('winmgmts:')
> scs=wmi.InstancesOf('win32_sounddevice')
> for sc in scs:
> print sc.Properties_('Name'), sc.Properties_('Status')
However, that requires PyWin32 so can't really use that for
test_winsound.py. My understanding of ctypes is that it can NOT replace
win32com, but I'd be happy to be wrong here. Thomas?
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Martin v. Loewis wrote] > I took an approach with a little more automation: > Tools/buildbot/external.bat gradually learns how to fetch and build > the necessary prerequisites; to avoid moving URLs, these come from > the external/ directory of the projects svn (in case of bsddb, > this already has the patches, and the VS project files converted). > > > If people don't mind having prebuilt binaries checked in > > Well, I do mind having prebuilt binaries checked in. They take up space > for little gain, plus they might increase the maintenance burden. I like you approach better. Very nice. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Thomas Heller wrote] > Trent Mick wrote: > > > Yup. Looks like my build worked. Another TODO now though: > > > > - Figure out why usage of: > > winsound.PlaySound(, winsound.SND_ALIAS) > > fails on my Win2k box. This is why the test suite fails on that box. > > > > Doesn't that always fail when there is no soundcard in the machine? I don't know. The *other* winsound tests work and I *can* hear that rising tone goop coming out of the box's tinny speakers when the test suite is run. http://www.python.org/dev/buildbot/all/x86%20W2k%202.4/builds/5/step-test/0 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_playsound.asp PlaySound ... SND_ALIAS The pszSound parameter is a system-event alias in the registry or the WIN.INI file. ... These aliases are apparently supposed to be in the registry or WIN.INI, but the docs don't say where. Perhaps my Win2k box is missing some registry entries. No, I think it is the config of the box -- read on. I do have a sound card in that box, however, the "Sounds and Multimedia Properties" dialog (off Control Panel) says that there are "No Playback Devices" for Sound Playback. So I guess that is it. Maybe the sound card in that box is not hooked up. Grrr. I certainly don't care about the sound card for that box but I don't want the test suite to keep reporting a spurious failure. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] > This touches on something we (including Martin) should think about: > it's very painful to build a full Python on Windows because of these > external packages... Yup. That is part of what I meant by updating PCBuild\readme.txt below: to improve the instructions so the build-dance for all these external packages is a little more cut n' paste. > Something we might be able to do instead is have just one person per > external project endure the pain of building it, and then have them > check in the whole post-compilation post-test project directory tree. > Everyone else (presumably including Windows buildbot slaves) using the > same compiler could then just check out the result. If people don't mind having prebuilt binaries checked in, yes I suppose we could do this. For some projects here at work we have a "prebuilt" dir at the root of the source tree: prebuilt/ win32-x86/ foo/# Windows prebuilt bits for package foo linux-x86/ foo/ solaris8-sparc/ foo/ ... Whoa, someone is way ahead of me here. :) > What's worse is when checkins cause both trunk and branch rebuilds. > That can bring my zippy box to its knees, particularly when two of the > disk-intensive tests (like test_largefile) run at the same time. That would require some kind of Scheduler work in the build master config that knows how to queue up scheduled builds from multiple sources to only allow one per machine at a time. I'd find this very useful for other projects at work and I'm sure other buildbot users would as well. Maybe buildbot may already have something like this? > > Remaining TODOs: > > - make sure the python24-maint branch one works > > Works for me, although (as the Wiki page says) you also need to copy > zlib-1.2.3 into the branch build area. Yup. Looks like my build worked. Another TODO now though: - Figure out why usage of: winsound.PlaySound(, winsound.SND_ALIAS) fails on my Win2k box. This is why the test suite fails on that box. > > - get the build slaves running as a Windows service > > Mark Hammond has a patch to the buildbot project toward this end: > > <http://sf.net/tracker/index.php?func=detail&aid=1401121&group_id=73177&atid=537003> Cool. I'll look into that. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] > Setup is hellish Any objections to: Index: Tools/buildbot/build.bat === --- build.bat (revision 42982) +++ build.bat (working copy) @@ -1,3 +1,3 @@ @rem Used by the buildbot "compile" step. call "%VS71COMNTOOLS%vsvars32.bat" -devenv.com /build Debug PCbuild\pcbuild.sln +devenv.com /useenv /build Debug PCbuild\pcbuild.sln Adding the /useenv means that one's PATH actually gets through. This is important for the _ssl.vproj build. It calls build_ssl.py which tries to find a Perl to use. Without "/useenv" Visual Studio is getting a PATH from somewhere else (presumably from its internal environment configuration). The result is that build_ssl.py fallsback to its "well-known" locations for a Perl install. On one mahcine I was trying this on I didn't have Perl installed to C:\Perl but to C:\Perl58. People who install to an alternate drive might also get surprised. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] > Setup is hellish, Agreed, though I have everything going with my own testing buildbot master (everything for the trunk build that is). My only remaining problem is that I can't connect to python.org's master. (Following up with Martin.) > The second-worst part was figuring out which parts of various software > docs could be ignored. :) Did you apply the Berkeley DB patches to your db-4.2.52 sources? > I recorded all that remained here: > > http://wiki.python.org/moin/BuilbotOnWindows correction for others: http://wiki.python.org/moin/BuildbotOnWindows > > "x86 XP-2 trunk". I'd still like to give it a go. The machine I'd use > > (initially at least) would be Win2k -- so not just a dupe of Tim's WinXP > > box. > > That would be great. A dupe of WinXP would also be great: I'm not > going to keep my buildbot slave up all the time, or anywhere near all > the time. I'm worried about the load this is going to cause on this machine with a new build for every checkin (granted they are serialized so not for *every* checkin). The full (doubled) test suite takes a *long* time to run on Windows. It looks like it took about 25 minutes on your box. It is taking over 40 minutes on one of my machines here. :( This Windows box needs an enema. Remaining TODOs: - get connection to python.org master working - make sure the python24-maint branch one works - see about the load issue - get the build slaves running as a Windows service - update PCbuild/readme.txt Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
> > On such a machine probably other source files should be used. I have no > > such > > machine - is it possible to build the 64-bit version on a 32-bit machine > > (with > > the platform SDK)? > > Indeed, this is possible. I don't know of anybody who does so, so far, > but in principle, the procedure is described in PCbuild/readme.txt. In > essence, you install the platform SDK and vsextcomp, and then build the > ReleaseAMD64 solution setting. I do this for ActivePython builds... by setting up the Platform SDK compiler I want in the environment and then using: devenv.com .../pcbuild.sln /useenv /build Release Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch to MS VC++ 2005 ?!
[Alex Martelli wrote] > What I hear from the rumor mill (not perhaps a reliable source) is a > bit discouraging about the stability of VS2005 (e.g. internal > rebellion at MS in which groups which need to ship a lot of code > pushed back against any attempt to make them use VS2005, and managed > to win the internal fight and stick with VS2003), but I don't know if > any such worry applies to something as simple as the mere compilation > of C code... As a (perhaps significant) datapoint: the Mozilla guys are moving to building with VS2005. That's lots of C++ and widely run -- though probably not the C runtime so much. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping support for Win9x in 2.6
[Neal Norwitz wrote] > Martin and I were talking about dropping support for older versions of > Windows (of the non-NT flavor). We both thought that it was > reasonable to stop supporting Win9x (including WinME) in Python 2.6. > I updated PEP 11 to reflect this. Are there specific code areas in mind that would be ripped out for this or is this mainly to avoid having to test on and ensure new code is compatible with? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
[Martin v. Loewis wrote] > If you want to build extensions for this build using distutils, you > need to > ... > 2. open an AMD64 retail shell > ... > > It might be possible to drop 2) some day, but finding the SDK from > the registry is really tricky. Look for: def find_platform_sdk_dir() here: http://cvs.sourceforge.net/viewcvs.py/pywin32/pywin32/setup.py?view=markup That is the best code I know for doing that. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
[Greg Ewing wrote] > It's not perfect, but it's still a lot better than the > situation on any other unix I've seen so far. Better than Unix, sure. But you *can* (and ActivePython does do) install everything under: /opt/$app_name/... > > open DMG, don't run the app from here, drag it to your > > Applications folder, then eject this window/disk, then run it from > > /Applications, > > A decently-designed application should be runnable from > anywhere, including a dmg, if the user wants to do that. > If an app refuses to run from a dmg, I consider that a > bug in the application. Yes, but the typical user probably *wants* to run the app from their /Applications folder (or somewhere else on their harddrive). When they start running from the mounted DMG, they can't then unmount the DMG to clean up. Actually the typical non-geek user doesn't care where they run the app from. They don't want to worry about those details. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
[Bob Ippolito wrote] >... > >/Library/Frameworks/Python.framework/... > >/Applications/MacPython-2.4/... # just MacPython does this > > ActivePython doesn't install app bundles for IDLE or anything? It does, but puts them under here instead: /Library/Frameworks/Python.framework/Versions/X.Y/Resources/ >... > >Also, a receipt of the installation ends up here: > > > >/Library/Receipts/$package_name/... > > > >though Apple does not provide tools for uninstallation using those > >receipts. > > That stuff is really behind the scenes stuff that's wholly managed by > Installer.app and is pretty much irrelevant. Sure. > Single apps are better than OK. Download them by whatever means you > want, put them wherever you want, and run them. You can run any well- > behaved application from a DMG (or a CD, or a USB key, or any other > readable media). For naive or new-to-mac users it is a confusing process to get the .app bundle to an appropriate place and then start running it. Why else have various app distributors out there come up with myriad slick background images for their DMG's trying to instruct users what to do with the icons in the mounted DMG's Finder window? On Windows you download an MSI (it ends up in your browser downloads folder), it starts the installation, and the end of the installation it starts the app for you. The app is nicely in Program Files. No need to eject something. No need to find somewhere to drag the icon. I'll grant that having the whole thing in one bundle is cool/handy/cute. ...anyway this is getting seriously OT for python-dev. :) Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
[Greg Ewing wrote] > MacOSX seems to be the only system so far that has got > this right -- organising the system so that everything > related to a given application or library can be kept > under a single directory, clearly labelled with a > version number. ActivePython and MacPython have to install stuff to: /usr/local/bin/... /Library/Frameworks/Python.framework/... /Applications/MacPython-2.4/... # just MacPython does this /Library/Documentation/Help/... # Symlink needed here to have a hope of registration with # Apple's (crappy) help viewer system to work. Also, a receipt of the installation ends up here: /Library/Receipts/$package_name/... though Apple does not provide tools for uninstallation using those receipts. Mac OS X's installation tech ain't no panacea. If one is just distributing a single .app, then it is okay. If one is just distributing a library with no UI (graphical or otherwise) for the user, then it is okay. And "okay" here still means a pretty poor installation experience for the user: open DMG, don't run the app from here, drag it to your Applications folder, then eject this window/disk, then run it from /Applications, etc. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] / as path join operator
[Nick Coghlan wrote] > What if we used "subpath" as the name instead of joinpath? "append"? not-a-big-fan-of-joinpath-either-ly yours, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The path module PEP
[Gustavo J. A. M. Carneiro wrote] > And BTW, what does splitunc do? http://en.wikipedia.org/wiki/Path_%28computing%29#Universal_Naming_Convention > It really should have a more descriptive name. No more that should "urllib" or "splitext". Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 a module catalogue with buildbot
> > Does that make sense? We would just need /f's script in SVN. > > in python/Tools/something or sandbox/something ? python/Doc/tools/something? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot: doing occasional full builds
[EMAIL PROTECTED] wrote] > > Trent> Specifically are you concerned about the readability of the > Trent> waterfall page or other things (maintainability or something)? If > Trent> the former, perhaps we could get some mileage out of the query > Trent> args that Brian mentioned: > > One concern might be performance. All buildbot slaves are contributed > hardware. I don't mind the load on my Mac (it's a dual processor g5), but > it may be an issue for other people. Does/can buildbot run at a lower > priority or is it just a matter of nice-ing the slave process at startup? As (I think) Brian mentioned, the scheduler for the (proposed) "full builder" could be setup to just build, say, once per day or only a couple of times per day where as the "incremental builder" would trigger for every SVN checkin. Nicing could probably also be done. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot: doing occasional full builds
[Martin v. Loewis wrote] > Brian Warner wrote: > > That would work, although to be honest the buildbot is more about repeatable > > builds. My first suggestion would be to have two separate Builders, one of > > which does incremental builds, the other which does full (from-scratch) > > builds. > > My concern is that then the number of builders would go up from 8 to 16, > even though it is just four different machines that we use. Specifically are you concerned about the readability of the waterfall page or other things (maintainability or something)? If the former, perhaps we could get some mileage out of the query args that Brian mentioned: [Brian Warner wrote] > I should mention a feature that you might find useful: you can add > some query arguments to the top-level Waterfall page's URL to > restrict the set of Builders that are displayed. If you append > "?show=full-2.3", you'll wind up with a waterfall display that > only contains the "full-2.3" Builder's column. Appending > "?show=full-2.3&show=full-2.4" will show two columns, etc. You can > also create multiple Waterfall instances, each with a different > set of "categories", and use that to manage the complexity of > displaying status for lots of Builders. (with the current release > these multiple Waterfalls must all listen on different TCP ports, > unfortunately, but you can always hide this with the > reverse-proxy's URL mapping). Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 a module catalogue with buildbot
[Neal Norwitz wrote] > > [Fredrik Lundh wrote] > > > Can buildbot deal with custom test/validation scripts, and collect the > > > output > > > somewhere ? > > > ... > It looks like we could define a class similar to Test, such as: > > class Catalog(ShellCommand): > name = "catalog" > warnOnFailure = 0 # this was 1, not sure which we want > description = ["catalog"] > descriptionDone = ["catalog"] > command = ["/f cmd here", "and", "other", "flags"] > > The factory is created like this: > f = factory.GNUAutoconf(source, test=["make","testall"]) > > ISTM, we can just add this line: >f.steps.append(s(Catalog, command=Catalog.command)) > > Does that make sense? We would just need /f's script in SVN. Yup. Sounds right to me. > PS If there was a method on ShellCommand, adding a step would be simpler, > e.g., > > def addStep(self, cls, **kwds): > self.steps.append((cls, kwds)) > > then we could do: f.addStep(Catalog, command=Catalog.command) > which would simplify a bunch of code in process/factory.py since it is > called this way 10 times. Didn't look elsewhere. Add a buildbot patch/bug? http://sourceforge.net/tracker/?func=add&group_id=73177&atid=537003 Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py
[Stephen J. Turnbull wrote]
> >>>>> "Fredrik" == Fredrik Lundh <[EMAIL PROTECTED]> writes:
>
> Fredrik> many test frameworks support "expected failures" for this
> Fredrik> purpose. how hard would it be to add a
>
> Fredrik> unittest.FailingTestCase
>
> Fredrik> class that runs a TestCase, catches any errors in it, and
> Fredrik> signals an error ("test foo passed unexpectedly") if it
> Fredrik> runs cleanly ?
>
> One can do even better than that. unittest.FailingTestCase should
> (except possibly for platform dependencies) know _how_ the TestCase is
> expected to fail. You also want to know if the error changes.
How about this:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307970
a better assertRaises() for unittest.py
When writing unit tests for Python using the standard unittest.py
system the assertRaises() (aka failUnlessRaises()) method is used to
test that a particular call raises the given exception. This recipe
if for assertRaisesEx() that adds three things: (1) the ability to
assert the raised exception's args; (2) the ability to test that the
stringified exception matches a given regular expression; and (3)
much better failure messages.
I haven't read this thread, so apologies is this doesn't really apply to
the discussion.
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
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 a module catalogue with buildbot
[Fredrik Lundh wrote]
> Can buildbot deal with custom test/validation scripts, and collect the output
> somewhere ?
Yes, it should be able to. However, it might change the part of the the
master.cfg file that defines the build steps from being trivial
(probably something like:
building_python_factory = factory.GNUAutoconf(
s(SVN, svnurl="http://svn.python.org/projects/python/trunk";),
test=["make", "test"],
)
) to something a little less trivial.
The standard GNUAutoconf class would have to be subclassed to add that
extra step ("make check_for_missing_docs"?). That probably would be
fairly straightforward. Neil and Martin would probably know better. I
don't have access to the buildbot setup.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter
[EMAIL PROTECTED] wrote] > ...and whoever the Tcl/Tk master is these days (still Ousterhout?)... That's Jeff Hobbs. He sits behind me. I'll see if I can pester him to give some Tcl/Tk and _tkinter thoughts. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
[Martin v. Loewis wrote] > Trent Mick wrote: > > I think I'm part of the way there with the following. I've subclassed > > the "SVN" source build step to add support for new source mode: > > "update_and_clobber_occassionally". Basically it (hackily) changes the > > source type btwn "update", which we usually want, and "clobber", which > > we sometimes want. > > Ah, but that would require changes to the slaves, right? I would > prefer a solution that avoids that. I don't think so. In my little test setup I didn't have to make any change to the slave. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
> > To wipe out the build occassionally you could (presumably) add a
> > starting step to the Python 'builder' (in the build master.cfg) to
> > rm -rf $builddir
> > every, say, Sunday night.
>
> Sure, that would be the idea. How to formulate it?
I think I'm part of the way there with the following. I've subclassed
the "SVN" source build step to add support for new source mode:
"update_and_clobber_occassionally". Basically it (hackily) changes the
source type btwn "update", which we usually want, and "clobber", which
we sometimes want.
The current problem with this is that I don't know if the build step
objects have access to a local data store -- so it could, say, count how
many builds have been done to know to clobber every tenth one. The
current code just chooses to clobber for any build on Sunday. Not a very
satisfying solution.
Brian,
Is there a way for build steps to maintain some state?
clipped from the build master's master.cfg -
...
class SVNEx(step.SVN):
"""A SVN Source build step that adds the ability for the Source
"mode" to be a combination of "update" and "clobber". This is useful if
your general just want to update the source tree from source code
control,
but occassionally want to clobber and start fresh.
To use this functionality use mode="update_and_clobber_occassionally".
To control when "occassionally" is now override the "should_clobber"
method. The default implementation is currently hardcoded to
"every Sunday". (This is a HACK. Perhaps there should be constructor
options to clobber every Nth time or to have cron-like arguments -- see
"Nightly" in scheduler.py. I don't know if "steps" have access to a
local
data store to be able to do this -- e.g. keep a counter.)
Ideally this would be an option of the base "Source" class in
buildbot/process/step.py.
"""
def __init__(self, **kwargs):
if kwargs.has_key("mode") \
and kwargs["mode"] == "update_and_clobber_occassionally":
self.update_and_clobber_occassionally = True
kwargs["mode"] = "update"
else:
self.update_and_clobber_occassionally = False
step.SVN.__init__(self, **kwargs)
def should_clobber(self):
from datetime import date
is_sunday = date.today().weekday() == 6 # it is Sunday
from twisted.python import log
log.msg("should_clobber? %s", (is_sunday and "yes" or "no"))
return is_sunday
def startVC(self, *args, **kwargs):
if self.update_and_clobber_occassionally:
if self.should_clobber():
self.args["mode"] = "clobber"
else:
self.args["mode"] = "update"
step.SVN.startVC(self, *args, **kwargs)
python_factory = factory.GNUAutoconf(
s(SVNEx, svnurl="http://svn.python.org/projects/python/trunk";,
mode="update_and_clobber_occassionally"),
test=["make", "test"], # use `make testall`?
)
# Then use python_factory as something like so:
#c['builders'] = [
#{'name': "linux-x86",
# 'slavename': "...",
# 'builddir': "python",
# 'factory': python_factory,
# },
#...
#]
clipped from the build master's master.cfg -
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
[Martin v. Loewis wrote] > I would like to do this in buildbot, but I'm not sure how to > (i.e. wipe the build occasionally, but not every time). > > For example, I could imagine completely cleaning the build directory > every time the build number % 10 == 0. Still, what the precise > buildbot incantation would be, I don't know. (Still learning my buildbot mojo.) One idea would be to do what Mozilla's Tinderbox does: they have one set of builds that are incremental and one set that are full. Actually looking around on tinderbox.mozilla.org I could only find incremental builds so I'm not sure what they are doing. To wipe out the build occassionally you could (presumably) add a starting step to the Python 'builder' (in the build master.cfg) to rm -rf $builddir every, say, Sunday night. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Buildbot-devel] Re: buildbot
> > Or for separate logic projects being built with the same builtbot > > master. For example, say Python's buildbot wanted to do regular builds > > and tests of the distutils tree > > (http://svn.python.org/view/distutils/trunk/). > > I believe you could always get it arranged the way you like by properly > setting up an "uninteresting changes" filter. You would have several > builders, one change source, and each builder would filter out the > changes it is interested in. I meant that more as a justification for improving the Waterfall status receiver to support separate summary pages for separate projects and trunks... all with the same buildbot master server. python.org/dev/buildbot/python/... python.org/dev/buildbot/python-release24-maint/... python.org/dev/buildbot/distutils/... Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
[Trent Mick wrote] > Or for separate logic projects being built with the same builtbot s/logic/logical/ Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
[Brian Warner wrote] >... > The only lingering issues are with status delivery: the main HTML > "Waterfall" HTML will interleave builds of both branches on the same > page, which could be a bit confusing (if the top line is red, does > that mean the trunk is broken, or the 2.4 branch?). Or for separate logic projects being built with the same builtbot master. For example, say Python's buildbot wanted to do regular builds and tests of the distutils tree (http://svn.python.org/view/distutils/trunk/). > Fixing this (by creating separate pages for each branch) is high on > the TODO list. I'm keen to help with that if I can. I'm now subscribed to buildbot-devel (as trentm at gmail) so I can pester you about that there further. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] slight inconsistency in svn checkin email subject lines
[Martin v. Loewis wrote] > Trent Mick wrote: > > Is this intentional? If not, could someone point me to where the svn > > trigger scripts are maintained so I could poke around for a fix? (Or > > just fix it themselves. :) > > It was not my intention. They are in > dinsdale.python.org:/data/repos/projects I don't have access to that box. Is this a machine used for maintaining the pydotorg stuff? Do you want me in that "club"? Or would it be easier for you the fix this little inconsistency... or have me make a bug on SF and assign to you (or someone else)? Thanks, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] slight inconsistency in svn checkin email subject lines
Here are the subject lines for two recent svn commit emails: [Python-checkins] commit of r41847 - in python/trunk: Lib/test/test__locale.py Python/as... [Python-checkins] commit of r41848 - python/trunk/setup.py ^ `--- one extra space There is an extra space when the checkin includes exactly one file (at least, I think that is the condition). Is this intentional? If not, could someone point me to where the svn trigger scripts are maintained so I could poke around for a fix? (Or just fix it themselves. :) Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of development documentation
[Neal Norwitz wrote] > I couldn't let Trent have all the fun. > > http://docs.python.org/dev/ Yah, I'd had a great time. Back to Xmas drinking. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] status of development documentation
[Fredrik wrote] > - could a cronjob that does this be set up on some python.org machine > (or on some volunteer's machine) I bit: http://trentm.com/python/ Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorporation of zlib sources into Python subversion
[Gregory P. Smith wrote] > (i don't know what version python uses today maybe this is a non issue?) $ svn cat http://svn.python.org/projects/python/trunk/PCbuild/zlib.vcproj | grep "zlib-" ... zlib 1.2.3 Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of development documentation
[Fredrik Lundh wrote] > $ make html > TEXINPUTS=... > +++ TEXINPUTS=... > +++ latex api > *** Session transcript and error messages are in > .../Python-2.5/Doc/html/api/api.how. > *** Exited with status 127. > The relevant lines from the transcript are: > > +++ latex api > sh: latex: command not found > *** Session transcript and error messages are in > .../Python-2.5/Doc/html/api/api.how. > *** Exited with status 127. > make: *** [html/api/api.html] Error 127 > > I'm not sure I have enough time to sort this out... For the record... I remember way back that I hit a limitation in latex2html that disallowed having any hyphens in the path to where the docs were being built. So your hyphen in "Python-2.5" might be confounding latex2html there. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing expat instances
[Martin v. Loewis wrote] > Trent Mick wrote: > > C:\trentm\src\python\python\PCbuild>svn st > > A _elementtree.vcproj > > M pcbuild.sln > > > > Shall I checkin the build changes? > > Go ahead. A change to Tools/msi/msi.py is also in order. Okay, done. I naively added "_elementtree" to the extensions list in msi.py. I'm guessing that that was all that was necessary. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing expat instances
[Fredrik Lundh wrote]
> can anyone with a working windows setup look at building the
> _elementtree module for windows ?
>
> (see the setup.py file for build options; it wants the same defines
> as pyexpat, plus one extra define.).
C:\trentm\src\python\python\PCbuild>python
Python 2.5a0 (#60, Dec 15 2005, 11:17:15) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from _elementtree import Element, ElementTree
>>> root = Element("root")
>>> root.append(Element("one"))
>>> tree = ElementTree(root)
>>> import sys
>>> tree.write(sys.stdout)
>>>
C:\trentm\src\python\python\PCbuild>svn st
A _elementtree.vcproj
M pcbuild.sln
Shall I checkin the build changes?
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
[Thomas Heller wrote] > Anyway, AFAIK, the activestate distribution contains Python debug dlls. [Er, a month late, but I was in flitting around Australia at the time. :)] Yes, as a separate download. ftp://ftp.activestate.com/ActivePython/etc/ ActivePython--win32-ix86-debug.zip And those should be binary compatible with the equivalent python.org installs as well. Note that the simple "install.py" script in those packages bails if the Python installation isn't ActivePython, but I could easily remove that if you think that would be useful for your users. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode charmap decoders slow
[Martin v. Loewis wrote] > Maybe it is possible to hack up a project file to invoke distutils > as the build process, but no such project file is currently available, > nor is it known whether it is possible to create one. This is essentially what the "_ssl" project does, no? It defers to "build_ssl.py" to do the build work. I didn't see what the full build requirements were earlier in this thread though, so I may be missing something. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2) (and a first post)
[richard barran wrote] > So I have a question: do the previous mails mean that a relpath > function might possibly be a usefull addition to os.path? Yes, it seems to have support. > And if the answer to the previous question is "yes", then should I > submit a patch, or is someone else already working on it? Yes, please do. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
> > But this begs the question: What is relpath good for, anyway? > > A couple of use cases I've encountered: > Another one: - Build tools that work with paths alot can really improve their log readability if relative paths can be used to keep paths short rather than the common fallback of just making everything an absolute path. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
[Greg Ewing wrote] > Nathan Bullock wrote: > > I find that I quite often want a > > function that will give me a relative path from path A > > to path B. I have created such a function, but it > > would be nice if it was in the standard library. > > +1 from me. It's a fairly common thing to want to do. If this *does* get added (I'm +0) then let's call it "relpath" or "relpathto" as in the various implementations out there: http://www.jorendorff.com/articles/python/path/ http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302594 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/208993 Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
[Nathan Bullock wrote]
> Just wondering if a function such as this has ever
> been considered? I find that I quite often want a
> function that will give me a relative path from path A
> to path B. I have created such a function, but it
> would be nice if it was in the standard library.
>
> This function would take two paths: A and B and give
> the relation between them. Here are a few of examples.
>
> os.path.diff("/A/C/D/", "/A/D/F/")
> ==> "../../D/F"
>
> os.path.diff("/A/", "/A/B/C/")
> ==> "B/C"
>
> os.path.diff("/A/B/C/", "/A/")
> ==> "../.."
Look around for functions/recipes called "relpath". E.g.:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302594
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/208993
http://www.jorendorff.com/articles/python/path/
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[Barry Warsaw wrote]
> Also, we already have precedence in format+print in the logging
> package. I actually think the logging provides a nice, fairly to use
> interface that print-ng can be modeled on.
The main reason for doing that in the logging package is for
performance: processing the args into the format string can be deferred
until the logging system knows that the log message will actually be
used. I'm not saying that the separation of 'fmt' and args in the
logging methods doesn't have the other benefit of clarity:
log.debug("%s %s %s %s ...", arg1, arg2, arg3,
really_really_long_arg4,) # nicer
log.debug("%s %s %s %s ..." % (arg1, arg2, arg3,
really_really_long_arg4)) # icky
but the performance reason doesn't apply to the printf()/write()
discussion here.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
[Brett Cannon wrote] > Where is it used so much? In the stdlib, grepping for WindowsError > recursively in Lib in 2.4 turns up only one module raising it > (subprocess) and only two modules with a total of three places of > catching it (ntpath once, urllib twice). In Module, there are no > hits. Just a data point (not really following this thread): The PyWin32 sources raise WindowsError twice (one of them is win32\Demos\winprocess.py which is probably where subprocess got it from) an catches it in 11 places. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pdb: should next command be extended?
[Ilya Sandler wrote] > > > At OSCON, Anthony Baxter made the point that pdb is currently one of the > > more unPythonic modules. > > What is unpythonic about pdb? Is this part of Anthony's presentation > online? (Google found a summary and slides from presentation but they > don't say anything about pdb's deficiencies) Kevin Altis was policing him to 5 minutes for his lightning talk so he didn't have a lot of time to elaborate. :) His slides were more of the Lawrence Lessig, quick and pithy style rather than lots of explanatory text. I think overridability, i.e. being about to subclass the Pdb stuff to do useful things, or lack of it was the main beef. Mostly Anthony was echoing comments from others' experiences with trying to work with the Pdb code. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
[Guido van Rossum wrote] > Also, P4 has *no* command to tell you which > files you've created without adding them to the repository yet -- so > the most frequent build breakage is caused by missing new files. This one is a frequent complaint from CVS-heads here at ActiveState. I have a p4 wrapper called "px" that extends some p4 commands (and adds a couple). One of the commands that it extends is "diff" to add a "-sn" (new) option similar to the "-se" (edit), "-sd" (delete). $ px help diff ...the usual 'p4 help diff'... new px options: [-sn -c changelist#] Px adds another -s option: -sn Local files not in the p4 client. Px also adds the --skip option (which only makes sense together with -sn) to specify that regularly skipped file (CVS control files, *~) should be skipped. The '-c' option can be used to limit diff'ing to files in the given changelist. '-c' cannot be used with any of the '-s' options. 'px' should grow a "px status" a la "svn|cvs status" to give a quick summary of local differences. Other additions: $ px help px 'px' entensions to 'p4': px --help Add px-specific help output to the usual 'p4 -h' and 'p4 -?'. See 'px help usage'. px -V, --version Print px-specific version information in addition to the usage 'p4 -V' output. See 'px help usage'. px -g ... Format input/output as *un*marshalled Python objects. Compare to the usual 'p4 -G ...'. See 'px help usage'. px annotate ... Identify last change to each line in given file, like 'cvs annotate' or 'p4pr.pl'. See 'px help annotate'. px backout ... Provide all the general steps for rolling back a perforce change as described in Perforce technote 14. See 'px help backout'. px changes -d ... Print the full 'p4 describe -du' output for each listed change. See 'px help changes'. px diff -sn --skip ... List local files not in the p4 depot. Useful for importing new files into a depot via 'px diff -sn --skip ./... | px -x - add'. See 'px help diff'. px diff -c ... Limit diffing to files opened in the given pending change. See 'px help diff'. px genpatch [] Generate a patch (usable by the GNU 'patch' program) from a pending or submitted chagelist. See 'px help genpatch'. Available here: http://starship.python.net/~tmick/#px Pure python. Works on Python >=2.2. Windows, Linux, Mac OS X, Unix. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Who made me the Perforce-bitch? Here I am screaming "Subversion! Subversion!" and y'all think I just using that as cover for a p4 lover affair. :) [Donovan Baarda wrote] > On Mon, 2005-08-08 at 15:49, Trent Mick wrote: > > One feature I like in Perforce (which Subversion doesn't have) is the > > ability to have pending changesets. A changeset is, as with subversion, > > something you check-in atomically. Pending changesets in Perforce allow > > you to (1) group related files in a source tree where you might be > > working on multiple things at once to ensure and (2) to build a change > > description as you go. In a large source tree this can be useful for > > separating chunks of work. > > This seems like a poor workaround for crappy branch/merge support. More like a pretty nice independent self-organizing feature that was necessitated as a workaround for a crappy solution (clientspecs) for huge data trees. > I'm new to perforce, but the pending changesets seem dodgey to me... you > are accumulating changes gradually without recording any history during > the process... ie, no checkins until the end. You want to do checkins of code in a consisten state. Some large changes take a couple of days to write. During which one may have to do a couple minor things in unrelated sections of a project. Having some mechanism to capture some thoughts and be able to say "these are the relevant source files for this work" is handy. Creating a branch for something that takes a couple of days is overkill. Perforce branching is pretty good in my experience. For very long projects one can easily create a branch. > Even worse, perforce seems to treat clients like "unversioned branches", > allowing you to review and test pending changesets in other clients. I'm not sure what you are talking about here. Yes, client information is stored on the server, but the *changes* (i.e. the diffs) on the client aren't so you must be talking about some other tool. Actually, if there *were* such a feature that would be quite handy. I'd love to be able to easily transfer my diffs developed on my Windows box to my Linux or Mac OS X box to quickly test changes there before checking in. > This supposedly allows people to review/test each others changes before > they are committed. The problem is, since these changes are not > committed, there is no firm history of what what was reviewed/tested vs > what gets committed... ie they could be different. The alternative being either that you have separate branches for everything (can be a pain) or just check-in for review (possibly breaking the build or functionality for other developers until the review is done). Actually the Perl guys working on PureMessage downstairs have two branches going in Perforce: one for checking into right away and then a cleaner tree to which only reviewed check-ins from the first are integrated. I'm not saying I am awash in pending changelists here. Nor that they should be used for what is better handled with branching. It is a tool (and a minor one). > Trying to develop and test a mixture of different changes in one > source tree is asking for trouble... they can interact. ...within reason. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
[Tim Peters wrote] > [Trent Mick] > > ... > > There are other little things, like not being able to trim the check-in > > filelist when editing the check-in message. For example, say you have > > 10 files checked out scattered around the Python source tree and you > > want to check 9 of those in. > > This seems dubious, since you're not checking in the state you > actually have locally, Say that 10th file is a documentation fix for a module unrelated to the other 9 files. > and you were careful to run the full Python > test suite with your full local state ;-) Absolutely. Er. Always. :) Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
One feature I like in Perforce (which Subversion doesn't have) is the ability to have pending changesets. A changeset is, as with subversion, something you check-in atomically. Pending changesets in Perforce allow you to (1) group related files in a source tree where you might be working on multiple things at once to ensure and (2) to build a change description as you go. In a large source tree this can be useful for separating chunks of work. There are other little things, like not being able to trim the check-in filelist when editing the check-in message. For example, say you have 10 files checked out scattered around the Python source tree and you want to check 9 of those in. Currently with svn you have to manually specify those 9 to be sure to not include the remaining one. With p4 you just say to check-in the whole tree and then remove that one from the list give you in your editor with entering the check-in message. Not that big of a deal. [Martin v. L?wis on Perforce] > The biggest disadvantage, to me, is that few people know how > to use it (myself included). Granted. For that reason and for a couple of others I mentioned (SVN will probably work better for offline and distributed developers) I think Subversion wins over Perforce. That is presuming, of course, that we find Subversion to be acceptibly stable/robust/manageble. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
[Aahz wrote] > On Sun, Aug 07, 2005, Barry Warsaw wrote: > > > > We'd also have to teach the current crop of developers how to use the > > client tools effectively. I think it's fairly simple to teach a CVS > > user how to use Subversion, but have no idea if translating CVS > > experience to Perforce is as straightforward. > > The impression I got from Alex Martelli is that it's not particularly > straightforward. Agreed. > (Google apparently uses Perforce.) We do at ActiveState as well. *The* Perl source code repository is a Perforce one (hosted separately here at ActiveState as well). Microsoft licenses the Perforce code and uses it (with some slight modifications I hear) internally. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
