On Sep 18, 1:48 pm, A.T.Hofkamp [EMAIL PROTECTED] wrote:
On 2007-09-17, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It seems that another solution is gobject.io_add_watch, but I don't
see how it tells me how much I can read from the file - if I don't
know that, I won't know the argument to
Hello,
I want to write a terminal program in pygtk. It will run a subprocess,
display everything it writes in its standard output and standard
error, and let the user write text into its standard input.
The question is, how can I know if the process wrote something to its
output, and how much it
Ok, I could have researched this before posting, but here's an
explanation how to do it with twisted:
http://unpythonic.blogspot.com/2007/08/spawning-subprocess-with-pygtk-using.html
It seems that another solution is gobject.io_add_watch, but I don't
see how it tells me how much I can read from
Hello,
I would like to present a module that I have wrote, called byteplay.
It's a Python bytecode assembler/disassembler, which means that you can
take Python code object, disassemble them into equivalent objects which
are easy to play with, play with them, and then assemble a new,
modified,
George Sakkis wrote:
[EMAIL PROTECTED] wrote:
However, I'm designing another library for
managing multi-dimensional arrays of data. Its purpose is similiar to
that of a spreadsheet - analyze data and preserve the relations between
a source of a calculation and its destination.
Sounds
Hello,
Sybren Stuvel wrote:
I think it's ugly to begin with. In math, one would write simply 'x'
to denote an unsubscribed (ubsubscripted?) 'x'. And another point, why
would one call __getitem__ without an item to call?
I think that in this case, mathematical notation is different from
python
Hello,
Fredrik Lundh wrote:
(but should it really result in an empty tuple? wouldn't None be a bit
more Pythonic?)
I don't think it would. First of all, x[()] already has the desired
meaning in numpy. But I think it's the right thing - if you think of
what's inside the brackets as a list of
Hello,
Following Fredrik's suggestion, I wrote a pre-PEP. It's available on
the wiki, at http://wiki.python.org/moin/EmptySubscriptListPEP and I
also copied it to this message.
Have a good day,
Noam
PEP: XXX
Title: Allow Empty Subscript List Without Parentheses
Version: $Revision$
Hello,
I discovered that I needed a small change to the Python grammar. I
would like to hear what you think about it.
In two lines:
Currently, the expression x[] is a syntax error.
I suggest that it will be evaluated like x[()], just as x[a, b] is
evaluated like x[(a, b)] right now.
In a few
Hello,
Terry Reedy wrote:
In a few more words: Currently, an object can be subscripted by a few
elements, separated by commas. It is evaluated as if the object was
subscripted by a tuple containing those elements.
It is not 'as if'. 'a,b' *is* a tuple and the object *is* subcripted by a
Hello,
Terry Reedy wrote:
So I do not see any point or usefulness in saying that a tuple subcript is
not what it is.
I know that a tuple is *constructed*. The question is, is this,
conceptually, the feature that allows you to ommit the parentheses of a
tuple in some cases. If we see this as
Can you provide a case where having a test for equality throw an exception
is actually useful? Yes. It will be useful because: 1. The bug of not
finding a key in a dict because it was implicitly hashed by identity and not
by value, would not have happened. 2. You wouldn't get the weird
It seems to me that both Mike's and Fuzzyman's objections were that
sometimes you want the current behaviour, of saying that two objects
are equal if they are: 1. the same object or 2. have the same value
(when it's meaningful). In both cases this can be accomplished pretty
easily: You can do it
Hello,
Guido has decided, in python-dev, that in Py3K the id-based order
comparisons will be dropped. This means that, for example, {} []
will raise a TypeError instead of the current behaviour, which is
returning a value which is, really, id({}) id([]).
He also said that default equality
Hello,
What is the convention for writing C functions which don't return a
value, but can fail?
If I understand correctly,
1. PyArg_ParseTuple returns 0 on failure and 1 on success.
2. PySet_Add returns -1 on failure and 0 on success.
Am I correct? What should I do with new C functions that I
15 matches
Mail list logo
