Re: [Python-Dev] mkdir -p in python
Hey folks, On 21 July 2010 10:37, Greg Ewing wrote: > Steven D'Aprano wrote: >> >> Perhaps all we need is a recipe in the docs: >> >> try: >> os.makedirs(path) >> except OSError, e: >> if e.errno != 17: >> raise > > I don't like writing code that depends on particular > errno values, because I don't trust it to work cross- > platform. I use errno.EEXIST instead of a magic number. later, -- Clinton Roy Software Engineer Global Change Institute University of Queensland humbug.org.au - Brisbane Unix Group clintonroy.wordpress.com - Blog flickr.com/photos/croy/ - Photos ___ 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] Curious datetime method
On Tue, Jul 20, 2010 at 5:56 PM, Alexander Belopolsky wrote: > In the real world where we have to take backward compatibility into > account, I would like to make today() and now() to be the same: both > taking optional tz argument, both available as either date or datetime > methods and both covariant. the justification for having two methods > doing exactly the same will be just readability: date.today() and > datetime.now() are more readable than date.now() and datetime.today(). I agree. Unless, of course, someone has a good explanation/reason for why today() and now() are implemented differently (i.e. a use case where the difference is significant). Anders ___ 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] Python-dev signal-to-noise processing question
No, the reply is fine as far as it goes, and I am sure the poster did get a reply from c.l.py, but his question revealed a thirst for knowledge not usually evidenced in non-dev inquiries. Unfortunately (?) the question also revealed a lack of understanding of a fairly basic concept. IIUC, he wanted to know how Python handles SIGKILL, when the hole point of SIGKILL is that you cannot handle it. So he shouldn't have been surprised that he couldn't find a place in Python where it's handled. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
On Jul 16, 2010, at 12:16 AM, Amaury Forgeot d'Arc wrote: >2010/7/15 Barry Warsaw : >> The first draft of PEP 3149 is ready for review. > >I like it! Cool! >I think it could mention the case where packages are not installed >in the canonical directory, but placed elsewhere along the PYTHONPATH. >This is how I deploy applications, for example, and the differences >between python versions makes this a pain. Because of the way the results of ./configure are embodied in the Makefile's $SO variable, and that variable is used unconditionally from sysconfig (and thus distutils), once you've configured --with-so-abi-tag, that tag will be used globally everywhere. I've added a note about this. >The specific case of Windows should be mentioned: each foo.pyd >contains the name of the python library (Python27.dll) it has been >linked with; It must be rebuilt for a major version change. >IMO the Windows installers provided by python.org should be built with >a tag that contains this major number. The current version of the PEP and my implementation do not change the Windows builds at all. I don't feel qualified to integrate the ideas expressed in PEP 3149 for Windows builds, but I would be happy to accept patches to either the PEP or implementation to export the same tagging feature for Windows. >> Thus for example, an initial implementation of PEP 384, compiled with >> `--with-so-abi-tag=cpython-xy` would search for the following file >> names when extension module `foo` is imported (in this order):: >> >> foo.abi3.so >> foo.cpython-xy.so >> foo.so > >Is this the correct order? IMO the so-abi-tag is more precise and the >two first items should be swapped. Good point, fixed. >PyPy would also benefit from this patch: it can now use extension >modules, but the ABI is slightly different. By default, PyPy would >load only modules containing the ABI tag, and refuse foo.so which is >incompatible for sure. But the installations could still be shared >between Python implementations. Interesting. I've added a note about this to the PEP. Thanks for the feedback. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What to do with languishing patches?
On Wed, Jul 21, 2010 at 2:09 AM, Stephen J. Turnbull wrote: .. > > In this particular case I'd rather tend to agree - an editable > > single-line box to enter space-*and*-comma-separated modules list > > would be the best interface. > > For active developers, yes. But this is unhelpful for people who > aren't hyper-familiar with the component list or who can't spell. It does not have to be either or. We can have a text box and a link/button next to it which will pop up a window with a selectable list of modules. Once modules are selected and pop-up closed, the text box should contain comma separated list of selected modules. ___ 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] Does trace modules have a unit test?
On Tue, Jul 20, 2010 at 6:19 PM, Nick Coghlan wrote: .. > Yep, we're pretty free to rename stuff as required inside the test > suite. The only real exception is test.support, as that's a documented > standard library module. Would anyone object to moving Lib/test/test_trace.py to Lib/test/test_line_tracing.py in 2.7 maint branch as Benjamin did in py3k? As I suggested in issue 9315 [1], the tests should be first written for 2.7 and either designed to run unchanged in 3.x, or ported in a controlled fashion to assure that we don't have regressions. (And in fact we do! [2, 3]) PS: The bikeshedding period is probably closed on this, but I would rather call the new test file test_sys_settrace rather than test_line_tracing. The sys.settrace function does more than line tracing and the test naming convention seems to be component rather than functionality oriented in the rest of the test suite. [1] http://bugs.python.org/issue9315 [2] http://bugs.python.org/issue9317 [3] http://bugs.python.org/issue9323 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Language Summit EuroPython 2010
Before the main events of EuroPython 2010 a Python Language Summit took
place at the Conference venue in Birmingham. Present were (in the order
they sat around the table):
* Brett Cannon
* Guido van Rossum
* Holger Krekel
* Amaury Forgeot D'Arc
* Georg Brandl
* Péter Szabó
* Ezio Melotti
* Michael Foord
* Mark Dickinson
* Martin von Loewis
* Ronald Oussoren
* Tim Golden
* Marc Andre Lemburg
* Richard Jones
Michael initiated a round-up of current and prospective Python versions for
various implementations. CPython and IronPython have both just released
v2.7 with IronPython offering some Py3 compatibility via a command-line
switch. The recent/current migration of Numpy and SciPy to Py3 should
give a boost to uptake. Amaury confirmed that PyPy currently supports
2.5.2 but is looking to target 2.7.
The PyPy guys also announced a C API bridging layer which should enable
a range of Python extension modules to work directly with PyPy. This is
only a stepping stone by way of broadening support. Brett suggested that
the Unladen Swallow merge to trunk was waiting for some work to complete
on the JIT compiler and Georg, as release manager for 3.2, confirmed that
Unladen Swallow would not be merged before 3.3.
The email module needs some work in Py3. David Murray has been given some
money by the PSF but needs more from other sources to complete the work.
This is hampered by the legalities around commercial organisations making
donations to not-for-profits when those donations are earmarked. Various
suggestions were put forward with no-one sure of the legal issues. Guido
suggested that we should move forward rather than stall for want of legal
advice.
A broad discussion arose concerning the issues debated on web-sig concerning
the WSGI protocol and the bytes vs string issues. Marc Andre brought up the
cgi module which has similar issues under Py3 and other examples were given,
including ftplib, urllib and some os functions. Various solutions were put
forward including a hybrid bytes-with-encoding object. This proposal was widely
unpopular, but two proposals met with broad approval: that certain stdlib
functions might be polymorphic, returning the type of their input as output;
and that the encoding string should include its error-handling. An example
of the first would be that os.getenv ("HOME") would return "/home/tjg" while
os.getenv (b"HOME") would return b"/home/tjg". An example of the latter would
be "utf8:strict". Something of the sort already works for PYTHONIOENCODING.
The issue of a __format__ equivalent for bytes was also raised as was the
idea of object methods to render an object as string or bytes, which could
be used in the polymorphic functions above.
Martin spoke about the state of the stable ABI PEP, indicating that he was
targetting 3.2. This work would reduce the need to recompile extension
modules separately on Windows for every version of Python -- something
especially pertinent when code has been orphaned but is still useful.
The versioned .so files PEP being worked out by Barry Warsaw overlaps with
this PEP and would only be useful for extensions which don't target the
stable ABI.
A messy discussion turned on the question of garbage collection of module
objects, and the order in which finalisers are called if at all, especially
when reference cycles exist. Marc Andre was proposing a __cleanup__ magic
function
for Python modules, which would enable the implementer to define the order
in which resources are released / closed down. This is quite a subtle area
and raised the issue of unfinalised objects in a reference cycle whose
memory has been freed out from under them but which still exist. Martin
described
the Java approach where finalisers are called once and then flagged so
they are not called again even if their object is resurrected. This sounded
like a useful approach for Python but would break code which expected to
be able to resurrect an object during its __del__ method... which is not
expected to account for much code.
Guido pointed out that no-one can be expected to hold enough of the complexities
of this area of Python's implementation in their head, and that an
implementation
of some sort would need to be written so that the corner-cases could emerge.
Ronald described the issues around the version and architecture differences
on Mac OS X and especially around Tkinter (and therefore IDLE). It was agreed
that
two installers could be provided: one targetting OS 10.3 on 32-bit Intel/PPC;
the other targetting 10.6 on 32 and 64-bit Intel. This latter would then be
able to use the system's Tk 8.5. The 10.6 binary would also work for 10.5,
which would be indicated in the install docs.
The Mercurial migration should move forward once Dirkjan has finished work
on his thesis. Martin insisted that a for-real repository would have to be
set up so that people can really see how it would work. An outstanding issue
in hg-svn prevents the Python history from being imported, but it shou
Re: [Python-Dev] Python-dev signal-to-noise processing question
On Wed, Jul 21, 2010 at 4:43 AM, "Martin v. Löwis" wrote: > Unfortunately (?) the question also revealed a lack of understanding > of a fairly basic concept. IIUC, he wanted to know how Python > handles SIGKILL, when the hole point of SIGKILL is that you cannot > handle it. So he shouldn't have been surprised that he couldn't find > a place in Python where it's handled. No, you misunderstood. He knew that one cannot set a SIGKILL signal handler. He just wanted to find the code in CPython responsible for turning that error into an exception for the purposes of giving a tutorial on signals. Reid ___ 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] Python Language Summit EuroPython 2010
On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden wrote: [...snip...] > A messy discussion turned on the question of garbage collection of module > objects, and the order in which finalisers are called if at all, especially > when reference cycles exist. Marc Andre was proposing a __cleanup__ magic > function > for Python modules, which would enable the implementer to define the order > in which resources are released / closed down. This is quite a subtle area > and raised the issue of unfinalised objects in a reference cycle whose > memory has been freed out from under them but which still exist. Martin > described > the Java approach where finalisers are called once and then flagged so > they are not called again even if their object is resurrected. This sounded > like a useful approach for Python but would break code which expected to > be able to resurrect an object during its __del__ method... which is not > expected to account for much code. > > Guido pointed out that no-one can be expected to hold enough of the > complexities > of this area of Python's implementation in their head, and that an > implementation > of some sort would need to be written so that the corner-cases could emerge. FWIW; I'm currently dealing with a bug in this area w.r.t multiprocessing and threads and modules we have imported vanishing due to this issue. I'm interested in hearing more. The problem affects 2.7 final, as well. jesse ___ 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] Python Language Summit EuroPython 2010
On Wed, 21 Jul 2010 11:42:00 -0400 Jesse Noller wrote: > On Wed, Jul 21, 2010 at 11:11 AM, Tim Golden wrote: > [...snip...] > > A messy discussion turned on the question of garbage collection of module > > objects, and the order in which finalisers are called if at all, especially > > when reference cycles exist. Marc Andre was proposing a __cleanup__ magic > > function > > for Python modules, which would enable the implementer to define the order > > in which resources are released / closed down. This is quite a subtle area > > and raised the issue of unfinalised objects in a reference cycle whose > > memory has been freed out from under them but which still exist. Martin > > described > > the Java approach where finalisers are called once and then flagged so > > they are not called again even if their object is resurrected. This sounded > > like a useful approach for Python but would break code which expected to > > be able to resurrect an object during its __del__ method... which is not > > expected to account for much code. > > > > Guido pointed out that no-one can be expected to hold enough of the > > complexities > > of this area of Python's implementation in their head, and that an > > implementation > > of some sort would need to be written so that the corner-cases could emerge. > > FWIW; I'm currently dealing with a bug in this area w.r.t > multiprocessing and threads and modules we have imported vanishing due > to this issue. I'm interested in hearing more. One common resolution is to not use a __del__ method, but instead a weakref callback which will do the necessary cleanup of a certain set of resources. This is of course not applicable in all situations. ___ 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] Python Language Summit EuroPython 2010
On Wed, Jul 21, 2010 at 17:11, Tim Golden wrote: > The Mercurial migration should move forward once Dirkjan has finished work > on his thesis. Martin insisted that a for-real repository would have to be > set up so that people can really see how it would work. An outstanding issue > in hg-svn prevents the Python history from being imported, but it should be > fixable. Martin & Tim brought up the issue of externals which the buildbots > use on Windows to bring in and build slightly patched versions of external > libraries such as OpenSSL and sqlite3. The issue in hgsubversion (which is different from hgsvn) has been fixed. The current problem is some oddity in the SVN bindings where it keeps complaining about having too many files open... I've been troubleshooting this in my thesis downtime, but nothing definitive yet. I'd like to hear more about where these externals are, so we can look into fixing that. Recent Mercurial includes support for svn subrepos, which might be usable for this. I wonder if it's sensible to discuss the splitting of the interpreter from the stdlib in separate repositories, because it might be better to convert to separate repositories in one go (instead of splitting out the stdlib later on). Not sure about this, but it would be useful to discuss at least. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unladen swallow status
On Wed, Jul 21, 2010 at 8:11 AM, Tim Golden wrote: > Brett suggested that > the Unladen Swallow merge to trunk was waiting for some work to complete > on the JIT compiler and Georg, as release manager for 3.2, confirmed that > Unladen Swallow would not be merged before 3.3. Yeah, this has slipped. I have patches that need review, and Jeff and Collin have been distracted with other work. Hopefully when one of them gets around to that, I can proceed with the merge without blocking on them. Reid ___ 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] Python Language Summit EuroPython 2010
Tim, thanks for this write-up! Bill ___ 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] Python Language Summit EuroPython 2010
Thanks Tim ! On Wed, Jul 21, 2010 at 5:11 PM, Tim Golden wrote: [..] > > Several people outlined the recent heated discussion over the addition > of a checkbox to the PyPI user-registration pages. Tarek has already > undertaken to patch PyPI to move the checkbox back one step, allowing > existing distutils users to register from the command line. Yes, so the problem goes away and we are conforming to the legal requirements. > At the same > time, Brett advised removing that functionality from distutils2 as > signing up on a web page is no great hardship. We will remove/simplify the register command, and get rid of that part. In the meantime, to try to avoid this problem in the future, since quite a few projects depend on PyPI now, I would like to suggest that a PEP of the various protocols PyPI has, is created. We do have some documentation here and there about the XML-RPC interface, the HTTP interface, etc., but we should have a single document describing the PyPI APIs, and maybe adding an API version number, so it can evolve smoothly. This would also be helpful for the people that are writing their own PyPI software, and ensure that distutils2 can work out of the box with any PyPI server out there. Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit EuroPython 2010
Am 21.07.10 17:47, schrieb Dirkjan Ochtman: Martin& Tim brought up the issue of externals which the buildbots use on Windows to bring in and build slightly patched versions of external libraries such as OpenSSL and sqlite3. The issue in hgsubversion (which is different from hgsvn) has been fixed. The current problem is some oddity in the SVN bindings where it keeps complaining about having too many files open... I've been troubleshooting this in my thesis downtime, but nothing definitive yet. I'd like to hear more about where these externals are, so we can look into fixing that. Recent Mercurial includes support for svn subrepos, which might be usable for this. This isn't really about svn:externals, but about http://svn.python.org/projects/external/ which gets used in http://svn.python.org/projects/python/trunk/Tools/buildbot/external-common.bat There may not be a problem - all is needed is a recommendation how to replace it. The requirements are these: - multiple versions of external libraries - each Python version only needs a single copy of the library - we make changes to the code after its imported from upstream, and want to remember what these changes are Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Language Summit EuroPython 2010
On Wed, Jul 21, 2010 at 10:11 AM, Tim Golden wrote: > A discussion on the Cheeseshop / Package Index highlighted the fact that > the packaging infrastructure has become increasingly important especially > since setuptools, buildout and pip all download from it. Richard produced > graphs showing the increase in package downloads over time, and attributed > the recent slight tail-off to the fact that the toolchains are now becoming > more canny with respect to cacheing and mirroring. > > Martin & Richard confirmed that mirrors are now in place and Marc Andre > confirmed > that he would be putting together a proposal to have PyPI hosted in the > cloud. Guido pointed out that if an AppEngine implementation were > desirable, > he was sure that AppEngine team would support it with resources as needed. > Martin didn't feel that there was a problem with loading on the box in > question; it's the uptime that's behind people's concern as it's now so > essential to installing and deploying Python applications. > >From what I've been able to tell from afar, I strongly suspect PyPI's downtimes would be greatly reduced with a move to mod_wsgi (currently it is using mod_fcgi, and most downtime is solved with an Apache restart -- mod_wsgi generally recovers from these problems without intervention). Martin attempted this at one time but ran into some installation problems. It seems like the team of people managing PyPI could benefit from the addition of someone with more of a sysadmin background (e.g., to help with installing a monitor on the server). -- Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does trace modules have a unit test?
2010/7/21 Alexander Belopolsky : > On Tue, Jul 20, 2010 at 6:19 PM, Nick Coghlan wrote: > .. >> Yep, we're pretty free to rename stuff as required inside the test >> suite. The only real exception is test.support, as that's a documented >> standard library module. > > Would anyone object to moving Lib/test/test_trace.py to > Lib/test/test_line_tracing.py in 2.7 maint branch as Benjamin did in > py3k? As I suggested in issue 9315 [1], the tests should be first > written for 2.7 and either designed to run unchanged in 3.x, or ported > in a controlled fashion to assure that we don't have regressions. > (And in fact we do! [2, 3]) > > PS: The bikeshedding period is probably closed on this, but I would > rather call the new test file test_sys_settrace rather than > test_line_tracing. The sys.settrace function does more than line > tracing and the test naming convention seems to be component rather > than functionality oriented in the rest of the test suite. True, but the tests in that file are (mostly?) all about line tracing. -- Regards, Benjamin ___ 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] Does trace modules have a unit test?
On Wed, Jul 21, 2010 at 1:42 PM, Benjamin Peterson wrote: .. > True, but the tests in that file are (mostly?) all about line tracing. > Hopefully this will change soon. :-) ___ 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] Python Language Summit EuroPython 2010
On Wed, Jul 21, 2010 at 19:38, Ian Bicking wrote: > From what I've been able to tell from afar, I strongly suspect PyPI's > downtimes would be greatly reduced with a move to mod_wsgi (currently it is > using mod_fcgi, and most downtime is solved with an Apache restart -- > mod_wsgi generally recovers from these problems without intervention). > Martin attempted this at one time but ran into some installation problems. > It seems like the team of people managing PyPI could benefit from the > addition of someone with more of a sysadmin background (e.g., to help with > installing a monitor on the server). I have some experience with mod_wsgi (and this is what we're using for the hg.python.org setup, I think). I'd be happy to help out more with that, if it helps (though most of my experience is not with the Debian-based distributions). Cheers, Dirkjan ___ 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] Unladen swallow status
On Wed, Jul 21, 2010 at 6:50 PM, Reid Kleckner wrote: > On Wed, Jul 21, 2010 at 8:11 AM, Tim Golden wrote: >> Brett suggested that >> the Unladen Swallow merge to trunk was waiting for some work to complete >> on the JIT compiler and Georg, as release manager for 3.2, confirmed that >> Unladen Swallow would not be merged before 3.3. > > Yeah, this has slipped. I have patches that need review, and Jeff and > Collin have been distracted with other work. Hopefully when one of > them gets around to that, I can proceed with the merge without > blocking on them. > > Reid The merge py3k-jit to trunk? Cheers, fijal ___ 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] Unladen swallow status
On Wed, Jul 21, 2010 at 2:43 PM, Maciej Fijalkowski wrote: > On Wed, Jul 21, 2010 at 6:50 PM, Reid Kleckner > wrote: >> On Wed, Jul 21, 2010 at 8:11 AM, Tim Golden wrote: >>> Brett suggested that >>> the Unladen Swallow merge to trunk was waiting for some work to complete >>> on the JIT compiler and Georg, as release manager for 3.2, confirmed that >>> Unladen Swallow would not be merged before 3.3. >> >> Yeah, this has slipped. I have patches that need review, and Jeff and >> Collin have been distracted with other work. Hopefully when one of >> them gets around to that, I can proceed with the merge without >> blocking on them. >> >> Reid > > The merge py3k-jit to trunk? I believe he's talking about the merger of the Unladen tree into the py3k-jit branch. Collin ___ 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] Unladen swallow status
On Wed, Jul 21, 2010 at 11:45 PM, Collin Winter wrote: > On Wed, Jul 21, 2010 at 2:43 PM, Maciej Fijalkowski wrote: >> On Wed, Jul 21, 2010 at 6:50 PM, Reid Kleckner >> wrote: >>> On Wed, Jul 21, 2010 at 8:11 AM, Tim Golden wrote: Brett suggested that the Unladen Swallow merge to trunk was waiting for some work to complete on the JIT compiler and Georg, as release manager for 3.2, confirmed that Unladen Swallow would not be merged before 3.3. >>> >>> Yeah, this has slipped. I have patches that need review, and Jeff and >>> Collin have been distracted with other work. Hopefully when one of >>> them gets around to that, I can proceed with the merge without >>> blocking on them. >>> >>> Reid >> >> The merge py3k-jit to trunk? > > I believe he's talking about the merger of the Unladen tree into the > py3k-jit branch. > > Collin > If so, how does this relate to 3.2 and 3.3 release schedule? Cheers, fijal ___ 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] mkdir -p in python
Ray Allen wrote: I think in this case, the errno is generate by c standard library, which can be seen as cross-platform. But I'm never sure how standard the actual error numbers are, though. I tend to think of them as coming from Unix-land, and thus fair game for getting screwed around with on Windows. Am I worrying too much? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does trace modules have a unit test?
On 7/21/2010 6:45 PM, Alexander Belopolsky wrote: > On Wed, Jul 21, 2010 at 1:42 PM, Benjamin Peterson > wrote: > .. >> True, but the tests in that file are (mostly?) all about line tracing. >> > > Hopefully this will change soon. :-) At which point the renaming would be justified. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] Python-dev signal-to-noise processing question
>> 1. I suggested one improvement to the canned response in my previous >> post: expand 'using' to 'using or understanding'. > > I changed wording to "if you're having problems learning, understanding > or using Python" I think it's critical to disambiguate between questions about "using and programming with the Python language" versus working with the actual code base that makes Python. Your boilerplate is appropriate for the former, but completely confusing for the latter. As to your question of how best to handle inquiries from the blue or "noisy questions", I personally prefer the following (only slightly tongue-in-cheek): ...After a sufficient period of waiting, say a day or two with no response: "busy busy busy, the gnomes must be hard at work. You've no answer. That means that your question(s) either isn't interesting enough in an obvious way, or it's simply off-topic. If you feel you been unfairly ignored, you might try rewording the question, doing some research to show that you've checked the obvious, or try the following venues: comp.lang.python, for blah blah blah python-ideas,for pitching your new lambda form, to etc, etc" In any case, Mr Crute gave a quite perfect answer, not that such detail should be exptected. Cheers, Marcos ___ 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] Python Language Summit EuroPython 2010
On 7/21/2010 6:21 PM, Tarek Ziadé wrote: > Thanks Tim ! > > On Wed, Jul 21, 2010 at 5:11 PM, Tim Golden wrote: > > [..] >> >> Several people outlined the recent heated discussion over the addition >> of a checkbox to the PyPI user-registration pages. Tarek has already >> undertaken to patch PyPI to move the checkbox back one step, allowing >> existing distutils users to register from the command line. > > Yes, so the problem goes away and we are conforming to the legal requirements. > >> At the same >> time, Brett advised removing that functionality from distutils2 as >> signing up on a web page is no great hardship. > > We will remove/simplify the register command, and get rid of that part. > > In the meantime, to try to avoid this problem in the future, since > quite a few projects > depend on PyPI now, I would like to suggest that a PEP of the various > protocols PyPI has, is created. > > We do have some documentation here and there about the XML-RPC > interface, the HTTP interface, etc., but we should have a single > document describing the PyPI APIs, and maybe adding an API version > number, so it can evolve smoothly. > > This would also be helpful for the people that are writing their own > PyPI software, and ensure that distutils2 can work out of the box with > any PyPI server out there. > > Tarek +1 Readers may not be aware that there is a current attempt to try to catalog and to some extent unify the different web presences that the Foundation maintains. This is why I am copying this message to Ethan Schoonover, who leads that effort. PyPi will doubtless be an increasingly important part of that presence, so I hope it can be integrated with the rest somehow. I do not imagine that this will be an easy issue to resolve, but a journey of a thousand miles begins with a single step. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] Python Language Summit EuroPython 2010
On 7/21/2010 10:40 PM, Dirkjan Ochtman wrote: > On Wed, Jul 21, 2010 at 19:38, Ian Bicking wrote: >> From what I've been able to tell from afar, I strongly suspect PyPI's >> downtimes would be greatly reduced with a move to mod_wsgi (currently it is >> using mod_fcgi, and most downtime is solved with an Apache restart -- >> mod_wsgi generally recovers from these problems without intervention). >> Martin attempted this at one time but ran into some installation problems. >> It seems like the team of people managing PyPI could benefit from the >> addition of someone with more of a sysadmin background (e.g., to help with >> installing a monitor on the server). > > I have some experience with mod_wsgi (and this is what we're using for > the hg.python.org setup, I think). I'd be happy to help out more with > that, if it helps (though most of my experience is not with the > Debian-based distributions). > > Cheers, > > Dirkjan Copying this message to the mod_wsgi author/maintainer, who should be able to give us sound advice on this (as should Ian, but he's a secondary server for the data :-). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] What to do with languishing patches?
Alexander Belopolsky writes: > On Wed, Jul 21, 2010 at 2:09 AM, Stephen J. Turnbull > wrote: > .. > > > In this particular case I'd rather tend to agree - an editable > > > single-line box to enter space-*and*-comma-separated modules list > > > would be the best interface. > > > > For active developers, yes. But this is unhelpful for people who > > aren't hyper-familiar with the component list or who can't spell. > > It does not have to be either or. We can have a text box and a > link/button next to it which will pop up a window with a selectable This is what Roundup multilinks do anyway. I just don't want the "best" (cf the post I'm replying to) to get in the way of the "good". ___ 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] Python-dev signal-to-noise processing question
On 21/07/10 23:43, "Martin v. Löwis" wrote: IIUC, he wanted to know how Python handles SIGKILL, when the hole point of SIGKILL is that you cannot handle it. No, I think he wanted to know how Python disallows attempting to set a handler for SIGKILL, when he couldn't find any code that special-cases SIGKILL in the implementation of signal(). Although he didn't express the question all that clearly, so it's hard to tell. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python signal processing question
Greg Ewing writes: > Scott McCarty wrote: > > All, I have searched everywhere (mostly the code and a little google) > > and I cannot understand where the SIGKILL signal gets checked when it is > > set as a handler. > > Possibly it's not being checked at all by Python, but > is being rejected by the system call. The Darwin man > page says this about signal(3) in the ERRORS section: > > [EINVAL] An attempt is made to ignore or supply a handler for > SIGKILL or SIGSTOP. The Linux signal(2) manpage just says EINVAL signum is invalid. But I suppose that could be stretched to cover "SIGKILL, SIGSTOP, or not a signal number known to the kernel". > Not sure why it gets reported as a RuntimeError rather > than an OSError, though. My understanding of OSError is that the OS is saying "sorry, what you tried to do is perfectly reasonable under some circumstances, but you can't do that now." ENOMEM, EPERM, ENOENT etc fit this model. RuntimeError OTOH is basically saying "You should know better than to try that!" EINVAL fits this model. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Timeouts for subprocess module
Hi python-dev, I've been working through a patch to add timeouts to the subprocess module: http://bugs.python.org/issue5673 It's gotten a fair amount of review, and I'm planning to commit it. Since it's my first contribution, I'm taking Georg's suggestion to send mail to python-dev to see if anyone objects. If not, I'll commit it to the py3k branch tomorrow night. Reid ___ 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] mkdir -p in python
Greg Ewing writes: > Ray Allen wrote: > > > I think in this case, the errno is generate by c standard library, > > which can be seen as cross-platform. > > But I'm never sure how standard the actual error numbers are, though. You can use them by name, and in fact I strongly recommend it: import os import errno try: os.makedirs(path) except OSError, exc: if exc.errno != errno.EEXIST: raise > I tend to think of them as coming from Unix-land, and thus fair game > for getting screwed around with on Windows. Am I worrying too much? There are some that differ between different OSen, true. Using them by name avoids dealing with *different* numbers (since the ‘errno’ module's attributes will use the same name for semantically the same error), leaving only the problem of errors that are *missing* on some platforms. EEXIST is common to all of them though, AFAIK. -- \ “Sittin' on the fence, that's a dangerous course / You can even | `\ catch a bullet from the peace-keeping force” —Dire Straits, | _o__) _Once Upon A Time In The West_ | Ben Finney ___ 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] Python signal processing question
On Jul 22, 2010, at 12:00 AM, Stephen J. Turnbull wrote: > My understanding of OSError is that the OS is saying "sorry, what you > tried to do is perfectly reasonable under some circumstances, but you > can't do that now." ENOMEM, EPERM, ENOENT etc fit this model. > > RuntimeError OTOH is basically saying "You should know better than to > try that!" EINVAL fits this model. That is not my understanding of OSError at all, especially given that I have seen plenty of OSErrors that have EINVAL set by various things. OSError's docstring specifically says "OS system call failed.", and that's the way I've already understood it: you made a syscall and got some kind of error. Python _mostly_ avoids classifying OSErrors into different exception types in other APIs. The selection of RuntimeError in this particular case seems somewhat random and ad-hoc, given that out-of-range signal values give ValueError while SIGKILL and SIGSTOP give RuntimeError. The RuntimeError's args start with "22" (which I assume is supposed to mean "EINVAL") but it doesn't have an 'errno' attribute as an OSError would. The ValueError doesn't relate to an errno at all. Nowhere does the documentation say "raises OSError or ValueError or TypeError or RuntimeError whose args[0] may be an errno". To be clear, this particular area doesn't bother me. I've been dealing with weird and puzzling signal-handling issues in Python for years and years and this dusty corner of the code has never come up. I did want to reply to this particular message, though, because I *would* eventually like the exception hierarchy raised by certain stdlib functions to be more thoroughly documented and coherent, but a prerequisite to that is to avoid rationalizing the random potpourri of exception types that certain parts of the stdlib emit. I think signal.signal is one such part. ___ 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] Python-dev signal-to-noise processing question
On Wed, Jul 21, 2010 at 07:28:24PM -0600, average wrote: > As to your question of how best to handle inquiries from the blue or > "noisy questions", I personally prefer the following (only slightly > tongue-in-cheek): > > ...After a sufficient period of waiting, say a day or two with no response: Ok, I'll wait a bit longer. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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
