Re: [Python-Dev] Numeric alignment issue with PEP 3101
On Mon, Sep 7, 2009 at 11:10 PM, Eric Smith wrote: > Hmm, I never noticed that. At this point, I think changing the formatting > for any types would break code, so we should just change the documentation > to reflect how currently works. I think the alignment for Decimal *does* need to be changed, though. It currently left-aligns by default (my fault: I just blindly followed PEP 3101 without thinking too hard about it). I'd like to fix this for 3.2 and 2.7; I'm not sure whether it's too disruptive to fix it in 3.1 and 2.6. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numeric alignment issue with PEP 3101
Mark Dickinson wrote: On Mon, Sep 7, 2009 at 11:10 PM, Eric Smith wrote: Hmm, I never noticed that. At this point, I think changing the formatting for any types would break code, so we should just change the documentation to reflect how currently works. I think the alignment for Decimal *does* need to be changed, though. It currently left-aligns by default (my fault: I just blindly followed PEP 3101 without thinking too hard about it). I'd like to fix this for 3.2 and 2.7; I'm not sure whether it's too disruptive to fix it in 3.1 and 2.6. Right, not changing "any types" was too strong. I think that the numeric types should all default to right alignment. That means Decimal should change. I agree this should only be in 3.2 and 2.7. In addition, PEP 3101 and the documentation should be change to reflect the default right alignment for numeric types. Shame on you, Mark, for actually reading and implementing the specs! ;) You see that I didn't bother with that. At the time, I think I was trying to get str.format() to exactly agree with %-formatting. ___ 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] compiling python2.5 on linux under wine
aren't you better off just cross compiling under mingw? You don't even really need to do that... you can just dynamically load the brebuilt windows python libraries in your wine apps... wine is for running windows apps on linux, not for cross compiling... wine itself uses the mingw cross compiler when necessary from my understanding. winelib is for creating elf binaries, not windows binaries... -- View this message in context: http://www.nabble.com/compiling-python2.5-on-linux-under-wine-tp21270106p25340242.html Sent from the Python - python-dev mailing list archive at Nabble.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] [Distutils] Static metadata using setup.cfg
David Lyon wrote: On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers wrote: If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed. +1 Actually, this was already discussed on this mailing list. Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev... (CC'ing so they can tell me I'm wrong ;-) ) I suggested that a "requires" section could easily do this, something along the lines of: [Requires] stdlib=sqlite>=1.5 Tarek, How are requirements spelled for packages in your current setup.cfg? I really don't see why anything should be different for standard library packages (ie: the stdlib= prefix in David's example). Python distributions should just declare all the versions they come with in the same way that whatever-is-being-built by Tarek can introspect in the same way as any other package... So the concept of having an if/else test for this is superfluous. Right. It would also mean it would be possible to release bug fix versions of the standard library packages without having to roll a whole python release. +1 ...which in turn would mean that the standard library is no longer a place where packages go to die... Better yet, since "python" should be a package as far as the packaging system is concerned, library versions can just say what versions of python they work with. +1 - good idea ...and for me, the "python" package should be just another package in the distributions dance, called "python" ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] [Distutils] Static metadata using setup.cfg
2009/9/8 Chris Withers : >> I suggested that a "requires" section could easily do this, something >> along the lines of: >> >> [Requires] >> stdlib=sqlite>=1.5 > > Tarek, How are requirements spelled for packages in your current setup.cfg? Sorry, that's another problem we are dealing with here e.g. How *one* requirement is defined. The .cfg file is just a format that holds values, like you would express them in command line or in arguments. The "How are requirements spelled" part is the changes we will add in PEP 345. The templating part is just here to make these requirements (or anything else) vary, depending on a few environment values, so it can be read without installing the distribution, with a vanilla Python. Please stop cross-posting in other mailing-lists it makes the discussions confusing. there are two discussions, to be talked in distutils-SIG: 1/ static metadata using a setup.cfg.in (the current one) 2/ changes that will occur in PEP 345, to include requirement definitions Regards 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] [Distutils] Static metadata using setup.cfg
Chris Withers wrote: > David Lyon wrote: >> On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers >> >> wrote: >>> >>> If Python had a packaging system *and* used it for the standard >>> library, then things like this wouldn't be a problem... >>> The setup.cfg could just say "requires sqlite greater than version >>> x.y.z", and if it was in the standard library, it would be used >>> unless a newer version was needed. >> >> +1 >> >> Actually, this was already discussed on this mailing list. > > Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev... > (CC'ing so they can tell me I'm wrong ;-) ) My recollection of the python-dev discussions was that the outcome was "there isn't even a distutils-sig consensus yet, so it's a little early for python-dev to be sticking its oar in". Also, I don't think providing new metadata *describing* the standard library was particularly controversial - it was more radical ideas of actually breaking up the core distro into separate components that met resistance. Third party installers having the power to easily "replace" standard library modules for more than a single application was also a heavily debated feature (since that way lies unintended coupling and application/library installations that break previously installed applications). It's probably also worth mentioning that on many of these topics there is a recurring communications gap that usually becomes painful for the distutils-sig side as core devs re-ask questions that were hashed out on the distutils list long before. So I would suggest being prepared to summarise and provide links to such discussions when this all becomes settled enough to bring back to the whole of python-dev. The back and forth of an archived mailing list discussion can sometimes be more persuasive than the relatively sanitised summaries that end up in a PEP :) That said, Tarek's response suggests that this still isn't ready for a wider python-dev discussion, so I've set followup-to accordingly. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] Numeric alignment issue with PEP 3101
> Mark Dickinson wrote: >> I think the alignment for Decimal *does* need to be changed, though. It >> currently left-aligns by default (my fault: I just blindly followed PEP >> 3101 >> without thinking too hard about it). I'd like to fix this for 3.2 and >> 2.7; I'm >> not sure whether it's too disruptive to fix it in 3.1 and 2.6. I notice that complex has the same problem as the just-fixed Decimal. I'll make those changes. ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Howdy, So I've made most of the suggested changes here and put up a release of ipaddr. Do folks here consider this pep is final (enough) for submission or is there more work to be done? Cheers, /peter On Thu, Aug 27, 2009 at 6:52 AM, Peter Moody wrote: > Howdy folks, > > the reference code has been updated per your comments; specifically, > there's no more IP/IPv4/IPv6 factory functions, it's all IPAddress() > and IPNetwork constructors. > > I've submitted a patch to the PEP with updated examples and a lengthy > description of the class inheritance and the benefits from that design > choice. hopefully that should go live soon. > > If there are any more suggestions on the PEP or the code, please let me know. > > Cheers, > /peter > > On Tue, Aug 18, 2009 at 1:00 PM, Peter Moody wrote: >> Howdy folks, >> >> I have a first draft of a PEP for including an IP address manipulation >> library in the python stdlib. It seems like there are a lot of really >> smart folks with some, ahem, strong ideas about what an IP address >> module should and shouldn't be so I wanted to solicit your input on >> this pep. >> >> the pep can be found here: >> >> http://www.python.org/dev/peps/pep-3144/ >> >> the code can be found here: >> >> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ >> >> Please let me know if you have any comments (some already coming :) >> >> Cheers, >> /peter >> > ___ 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] PEP 3145
2009/9/7 Eric Pruitt : > Hello all, > > I have been working on adding asynchronous I/O to the Python > subprocess module as part of my Google Summer of Code project. Now > that I have finished documenting and pruning the code, I present PEP > 3145 for its inclusion into the Python core code. Any and all feedback > on the PEP (http://www.python.org/dev/peps/pep-3145/) is appreciated. Hi Eric, One of the reasons you're not getting many response is that you've not pasted the contents of the PEP in this message. That makes it really easy for people to comment on various sections. BTW, it seems like you were trying to use reST formatting with the text PEP layout. Double backquotes only mean something in reST. -- 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
[Python-Dev] PEP 3145 (With Contents)
Alright, I will re-submit with the contents pasted. I never use double
backquotes as I think them rather ugly; that is the work of an editor
or some automated program in the chain. Plus, it also messed up my
line formatting and now I have lines with one word on them... Anyway,
the contents of PEP 3145:
PEP: 3145
Title: Asynchronous I/O For subprocess.Popen
Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson
Type: Standards Track
Content-Type: text/plain
Created: 04-Aug-2009
Python-Version: 3.2
Abstract:
In its present form, the subprocess.Popen implementation is prone to
dead-locking and blocking of the parent Python script while waiting on data
from the child process.
Motivation:
A search for "python asynchronous subprocess" will turn up numerous
accounts of people wanting to execute a child process and communicate with
it from time to time reading only the data that is available instead of
blocking to wait for the program to produce data [1] [2] [3]. The current
behavior of the subprocess module is that when a user sends or receives
data via the stdin, stderr and stdout file objects, dead locks are common
and documented [4] [5]. While communicate can be used to alleviate some of
the buffering issues, it will still cause the parent process to block while
attempting to read data when none is available to be read from the child
process.
Rationale:
There is a documented need for asynchronous, non-blocking functionality in
subprocess.Popen [6] [7] [2] [3]. Inclusion of the code would improve the
utility of the Python standard library that can be used on Unix based and
Windows builds of Python. Practically every I/O object in Python has a
file-like wrapper of some sort. Sockets already act as such and for
strings there is StringIO. Popen can be made to act like a file by simply
using the methods attached the the subprocess.Popen.stderr, stdout and
stdin file-like objects. But when using the read and write methods of
those options, you do not have the benefit of asynchronous I/O. In the
proposed solution the wrapper wraps the asynchronous methods to mimic a
file object.
Reference Implementation:
I have been maintaining a Google Code repository that contains all of my
changes including tests and documentation [9] as well as blog detailing
the problems I have come across in the development process [10].
I have been working on implementing non-blocking asynchronous I/O in the
subprocess.Popen module as well as a wrapper class for subprocess.Popen
that makes it so that an executed process can take the place of a file by
duplicating all of the methods and attributes that file objects have.
There are two base functions that have been added to the subprocess.Popen
class: Popen.send and Popen._recv, each with two separate implementations,
one for Windows and one for Unix based systems. The Windows
implementation uses ctypes to access the functions needed to control pipes
in the kernel 32 DLL in an asynchronous manner. On Unix based systems,
the Python interface for file control serves the same purpose. The
different implementations of Popen.send and Popen._recv have identical
arguments to make code that uses these functions work across multiple
platforms.
When calling the Popen._recv function, it requires the pipe name be
passed as an argument so there exists the Popen.recv function that passes
selects stdout as the pipe for Popen._recv by default. Popen.recv_err
selects stderr as the pipe by default. "Popen.recv" and "Popen.recv_err"
are much easier to read and understand than "Popen._recv('stdout' ..." and
"Popen._recv('stderr' ..." respectively.
Since the Popen._recv function does not wait on data to be produced
before returning a value, it may return empty bytes. Popen.asyncread
handles this issue by returning all data read over a given time
interval.
The ProcessIOWrapper class uses the asyncread and asyncwrite functions to
allow a process to act like a file so that there are no blocking issues
that can arise from using the stdout and stdin file objects produced from
a subprocess.Popen call.
References:
[1] [ python-Feature Requests-1191964 ] asynchronous Subprocess
http://mail.python.org/pipermail/python-bugs-list/2006-December/
036524.html
[2] Daily Life in an Ivory Basement : /feb-07/problems-with-subprocess
http://ivory.idyll.org/blog/feb-07/problems-with-subprocess
[3] How can I run an external command asynchronously from Python? - Stack
Overflow
http://stackoverflow.com/questions/636561/how-can-i-run-an-external-
command-asynchronously-from-python
[4] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation
http://docs.python.org/library/subprocess.html#subprocess
