m of event loop, and they all provide some way
of hooking other things into it (as does Tkinter),
but whichever one you're using, it likes to be in
charge. Code which blocks reading from standard
input doesn't fit very well into any of them.
--
Greg Ewing, Computer Science Dept, +---
Gustavo J. A. M. Carneiro wrote:
> The object isn't really destroyed. Simply ob_refcnt drops to zero,
> then tp_dealloc is called, which is supposed to destroy it. But since I
> wrote tp_dealloc, I choose not to destroy it,
Be aware that a C subclass of your wrapper that overrides
tp_dealloc
[EMAIL PROTECTED] wrote:
> This sounds sort of like the situation that existed with sys.exitfunc before
> the creation of the atexit module. Can't we develop an API similar to that
> so that many different event-loop-wanting packages can play nice together?
I can't see how that would help. If th
Michiel Jan Laurens de Hoon wrote:
> I have an extension module for scientific visualization. This extension
> module opens one or more windows, in which plots can be made.
What sort of windows are these? Are you using an existing
GUI toolkit, or rolling your own?
> For the graphics windows to
[EMAIL PROTECTED] wrote:
> Python could dictate that the
> way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
> feed Python the (socket, callback) pair. Then you have a uniform way to
> control event-driven applications.
Certainly, if all other event-driven packages are wi
Noam Raphael wrote:
> All that is needed to make Tkinter and Michiels'
> code run together is a way to say "add this callback to the input
> hook" instead of the current "replace the current input hook with this
> callback". Then, when the interpreter is idle, it will call all the
> registered cal
.
And regardless of the need to import, there's a feeling
that it's something that ought to be done at compile
time, or even parse time.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealan
Michiel Jan Laurens de Hoon wrote:
> Greg Ewing wrote:
>
> > How about running your event loop in a separate thread?
>
> I agree that this works for some extension modules, but not very well
> for extension modules for which graphical performance is critical
I don'
Noam Raphael wrote:
> On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Noam Raphael wrote:
> >
> > > callback". Then, when the interpreter is idle, it will call all the
> > > registered callbacks, one at a time, and everyone would be happ
such an otherwise
indentation-savvy language seems a wart.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc.
there a particular
reason it wasn't done that way?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA
r you allocate something, however you do it, so you
need error checks on all your allocations in any case.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
bject * and replacing the
deallocation functions at the end with Py_XDECREF!
Maybe there are other functions where it would not
be so straightforward, but if this really is a
typical AST function, switching to PyObjects looks
like it wouldn't be difficu
Here's a somewhat radical idea:
Why not write the parser and bytecode compiler in Python?
A .pyc could be bootstrapped from it and frozen into
the executable.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citiz
Brett Cannon wrote:
> Is there a specific reason you are leaving out the AST, Greg, or do
> you count that as part of the bytecode compiler
No, I consider it part of the parser. My mental model
of parsing & compiling in the presence of a parse tree
is like this:
[source] -> scanner -> [tokens
steal references to its arguments (whether it
succeeds or not).
However, while that trick works in this particular case, it
wouldn't be so helpful in more complicated situations, so
Martin's version is probably a better model to follow.
--
ng) requires that ast-building functions
effectively return borrowed references, which is not
usual
Thats' not to say it shouldn't be done, but it does
differ from the usual conventions, and that would need
to be kept in mind.
--
Greg Ewing,
t have a .pyc (or at least that's what I thought
you were saying). If a .pyc were always generated,
this problem would not arise.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Chris
In the long run it's probably best to stick to the
conventional conventions, which are there for a reason --
they work!
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, Ne
rated by a fairly simple script?
(I'm being very careful not to suggest using Pyrex
for this, as I can appreciate the desire not to make
such a fundamental part of the core dependent on it!)
--
Greg Ewing, Computer Science Dept, +--+
University of Canter
Jeremy Hylton wrote:
> I still think passing copies is better than sharing live
> objects between Python and C,
Even if the objects are immutable?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandC
return the result of calling it
else:
return True
else:
look in the instance dict for the attribute
There wouldn't be a need to rely on catching exceptions
at all, then.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbur
estioning and
notifying the submitter? I don't see why a full-blown
registration and login should be required.
If the submitter chooses not to supply an email address,
then they have no grounds for being upset at not receiving
any notifications!
--
Greg Ewing, Compute
Guido van Rossum wrote:
> Um, that does't work for types which customize __getattribute__ or
> __getattr__ in various ways.
There could be a __hasattr__ slot in the class itself for
that purpose.
> IMO a property that has a side effect (other than updating a cache or
> statistics or perhaps logg
Calvin Spealman wrote:
> I will have to disagree with you there. If hasattr(a,b) returns True,
> one should be able to expect a.b will work properly. Otherwise, the
> majority of use cases for hasattr will be completely thrown out the
> window. How can hasattr work properly with properties if it d
hen maybe it should be beefed up to include the
module name somehow, so that it works reliably
(or at least more reliably than now).
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch,
Guido van Rossum wrote:
> You *might* want
> to separate classes with two blank lines if the methods within them
> are separated by single blank lines, but even there it's probably
> overkill.
Lately I've taken to putting a separator like this
between consecutive class definitions of any substant
risons other than == and != between disparate types will raise an
> exception unless explicitly supported by the type
can be true without precluding the existence of a
canonical ordering.
--
Greg Ewing, Computer Science Dept, +--+
University of Cante
arately-
compiled pieces of code run, it seems to me that Python
itself deserves to be classed as a "system component".
Although I concede that's probably not quite what
Microsoft mean by the term...
--
Greg Ewing, Computer Science Dept, +--+
Unive
re. Their solution of "compile your whole program
with the same CRT" completely misses the possibility that
the "whole program" may consist of disparate separately-
written and separately-compiled parts, and there may be no
single person with the ability and/or legal rig
y-evaluated sequence or mapping rather than an
iterator.
The iterator protocol is currently very simple and
well-focused on a single task -- producing things
one at a time, in sequence. Let's not clutter it up
with too much more cruft.
--
Greg Ewing, Computer Science Dept, +-
use a def instead.
Given that, I do *not* have the space to waste with 6 or 7
characters of geeky noise-word.
So my vote for Py3k is to either
1) Replace lambda args: value with
args -> value
or something equivalently concise, or
2) Remove lambda entirely.
--
Greg Ewing, Computer
e definition of "a prompt for some action"
> applies equally well.
No, it doesn't, because it's in the wrong direction. The
caller isn't prompting the callee to perform an action,
it's asking for some information.
I agree that "hint" is a more prec
ion in 3.0, so that this
particular example would no longer be a problem.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.
ut the details and write it up.
On the other hand, it may turn out that it's subsumed by
the new enhanced generators plus a trampoline.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam!
Thomas Wouters wrote:
> I have a slight reservation about the name. ... On the other
> hand, there are other places (in C) that want an actual int, and they could
> use __index__ too.
Maybe __exactint__?
--
Greg Ewing, Computer Science Dept, +--+
U
z
print:
"Result is"
w
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
Martin v. Löwis wrote:
> FWIW, Annex D also defines these features as deprecated:
> - the use of "static" for objects in namespace scope (AFAICT
> including C file-level static variables and functions)
> - C library headers (i.e. )
Things like this are really starting to get on my groat.
It use
Tim Peters wrote:
> [Martin v. Löwis]
> > In any case, POSIX makes it undefined what FD_SET does when the
> > socket is larger than FD_SETSIZE, and apparently clearly expects
> > an fd_set to be a bit mask.
>
> Yup -- although the people who designed the fdset macros to begin with
> didn't appear
Martin v. Löwis wrote:
> That future version might get published in 2270,
There are *already* differences which make C and C++
annoyingly incompatible. One is the const char * const *
issue that appeared here. Another is that it no longer
seems to be permissible to forward-declare static things,
Martin v. Löwis wrote:
> then, in C++, 4.4p4 [conv.qual] has a rather longish formula to
> decide that the assignment is well-formed. In essence, it goes
> like this:
>
> [A large head-exploding set of rules]
Blarg.
Const - Just Say No.
Greg
___
Pyt
Smith wrote:
> When teaching some programming to total newbies, a common frustration
> is how to explain why a==b is False when a and b are floats computed
> by different routes which ``should'' give the same results (if
> arithmetic had infinite precision).
This is just a special
Bengt Richter wrote:
> Anyhow, why shouldn't you be able to call freeze(an_ordinary_list) and get
> back freeze(xlist(an_ordinary_list))
> automatically, based e.g. on a freeze_registry_dict[type(an_ordinary_list)]
> => xlist lookup, if plain hash fails?
[Cue: sound of loud alarm bells going of
2401 - 2443 of 2443 matches
Mail list logo
