Re: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code

2005-07-02 Thread jcarlson
Ralf W. Grosse-Kunstleve wrote:
> A shorter alternative (my personal favorite since minimally redundant)::
>
>   class grouping:
>
>   def __init__(self, .keep_this, .and_this, but_not_this, 
> .but_this_again):
>   # real code right here

There is also the variant which I proposed on python-dev:

class grouping:
def __init__(self, _keep_this, _and_this, but_not_this, _but this
again):
InitAttrs(self, locals())
#real code goes here

Essentially you replace the '.' with '_', which doesn't require a
syntax change.  Unfortunately, both are almost invisible.  It does
offer you what you want right now (without that whole waiting a year+
for Python 2.5, PEP process, etc.).

> Enhanced __slot__ semantics proposal
> 
>
> When ``__slots__`` are used (cool feature!) the boilerplate problem
> becomes even worse::
>
>   class grouping:
>
>   __slots__ = ["keep_this", "and_this", "but_this_again"]
>
>   def __init__(self, keep_this, and_this, but_not_this, but_this_again):
>   self.keep_this = keep_this
>   self.and_this = and_this
>   self.but_this_again = but_this_again
>   # real code, finally

There is also the AutoSlots metaclass (which I have fixed) that does
this as well.

class grouping(object):
__metaclass__ = AutoSlots
def __init__(self, _keep_this, _and_this, but_not_this,
_but_this_again):
InitAttrs(self, locals())
#real code goes here

Both AutoSlots and InitAttrs use leading underscores on the __init__
method to discover which attributes are to be __slots__, and which
should be automatically assigned.

> P.S.: If you reply to this message, please clearly separate
> naming/syntax issues from the core issue of providing built-in support
> designed to reduce clutter.

Because you don't seem to have listened in python-dev, I'll say it
here.  Not everything that reduces clutter should be syntax, and not
every function, class, and module which reduces programming time should
be builtin.  Why?


1. Expanding Python syntax bloats the language.  It increases what you
need to teach to new Python users.  In my opinion, syntax additions
should really only be considered when significant gains in readability
and writability for many users are realized, that a lack of syntax
cannot offer.

2. Expanding the Python standard library bloats the distribution.
Right now, Python is a relatively light download.  But if one were to
include the top packages in everything, the distribution would quickly
bloat to 40+ megs.  This is not an option.  Generally, the requirements
of getting code into the standard library is either a demonstrated need
for the addition, or a known best-of-breed implementation for a
commonly used module, or both.

I believe your syntax change is a non-starter.  Why?  Because I've
offered code that does essentially everything you want, without a
syntax change.  If someone happens to include AutoSlots and InitAttrs
with their code, module, what have you, and it manages to make its way
into standard Python, so be it (I place the code into the public
domain).

The code for the InitAttrs and AutoSlots mechanism are available here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/435880

 - Josiah

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Read from stdouton Popen on WinXP?

2005-08-17 Thread jcarlson
> >>> "mhenry1384" <[EMAIL PROTECTED]> 08/16/05 11:48 PM >>>
> I am trying to run a program and filter the output on Windows XP.
> Since I want to filter the output, I'd like to read it a line at a time
> and only print the lines I care about.
>
> p = subprocess.Popen(["doxygen.exe", r"Doxyfile.cfg"],
> stdout=subprocess.PIPE, stderr=subprocess.STDOUT)

Install pywin32 .

Use:
  read(p.stdout, SIZE)
  read(p.stderr, SIZE)

Having defined read() as the below.  The subprocess generally still
needs to flush stdout and stderr.

 - Josiah


import msvcrt
import pywintypes
from win32file import ReadFile
from win32pipe import PeekNamedPipe

def read(stdout_or_stderr, maxsize):
try:
x = msvcrt.get_osfhandle(stdout_or_stderr.fileno())
(read, nAvail, nMessage) = PeekNamedPipe(x, 0)
if maxsize < nAvail:
nAvail = maxsize
if nAvail > 0:
(errCode, read) = ReadFile(x, nAvail, None)
except pywintypes.error, e:
errno = e.args[0]
if errno == 109:  # other end disconnected
stdout_or_stderr.close()
else:
raise

return read

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: PyPE 2.1 run problem

2005-08-18 Thread jcarlson
> Once I done the replacement as suggested above, PyPE2.1 can run from
> the source now. Thanks Josiah !

No problem.

> > I have downloaded the PyPE2.1-win-unicode.zip, after unzip it with winzip
> > into PyPE2.1-win-unicode dierctory on window XP. I try to run "pype.exe"
> > by double
> > click on it, but nothing has happen, then when I run it with "run as..."
> > using the right click button.
> > I have the following Message in the pype.exe.log
> >
> > Traceback (most recent call last):
> >   File "pype.py", line 30, in ?
> >   File "configuration.pyc", line 129, in ?
> > WindowsError: [Errno 267] The directory name is invalid:
> > 'E:\\Downloads\\Python\\PyPE\\PyPE2.1-win-unicode\\library.zip/*.*'
> >
> > I also copy the "PyPE2.1-win-unicode" directory into
> > "C:\Python24\Lib\site-packages" and run it, but it behaves the same !!

I have a solution to that one too...turns out that it was a problem
with PyPE trying to use a home directory inside of the library.zip file
if it couldn't find your platform's home directory.  I have fixed it to
be aware of being py2exe'd.  Try PyPE 2.1.1, available via
sourceforge.net (remember to verify those hashes!)

 - Josiah

-- 
http://mail.python.org/mailman/listinfo/python-list