On 30 Nov 2006, at 1:34 AM, Greg Ewing wrote:
Ronald Oussoren wrote:
It is already possibly to extend the type struct in Python 2.3
and later
From Python?
No, from C.
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 29, 2006, at 7:51 PM, Giovanni Bajo wrote:
> it's a minor issue, but I was wondering if the interpreter prompt
> could be
> changed in Py3K. The current prompt is ">>>" which happens to match
> the
> standard character used for quotes in e-
I've re-factored the file interfaces to reflect the current discussion.
I've also redone the MutableSequence and Mapping interfaces to use default
parameters, which makes them much more comprehensible.
See what you think.
> http://wiki.python.org/moin/AbstractBaseClasses
Bill
__
Greg Ewing wrote:
> Bill Janssen wrote:
>
> > Incidentally, what kind of iteration should apply to files opened in
> > "binary" mode
>
> I don't think binary files should directly support
> iteration at all. Wrap it in an object that iterates
> the way you want.
>
>for b in readbytes(f):
>
On Thu, Nov 30, 2006, Giovanni Bajo wrote:
>
> it's a minor issue, but I was wondering if the interpreter prompt could be
> changed in Py3K. The current prompt is ">>>" which happens to match the
> standard character used for quotes in e-mails. As a result, intepreter
> sessions might look funky
I don't know about this one. But I'm sure that the CVS history of
typeobject.c (in the 2.2a through 2.3 era, probably) would show that
serious hacks were necessary to make certain slots perform well
enough. I remember doing quite a bit of performance tuning with some
incredible results -- all to ma
But the >>> prompt is Python's trademark! I always get a warm fuzzy
feeling when I see it, e.g. in a corner of a slide in a NASA
presentation.
Just set sys.ps1 = "-->" if you want something different. You can even
set PYTHONSTARTUP= in your environment so
you won't hve to think about it.
--Guido
Hello,
it's a minor issue, but I was wondering if the interpreter prompt could be
changed in Py3K. The current prompt is ">>>" which happens to match the
standard character used for quotes in e-mails. As a result, intepreter
sessions might look funky when copy & pasted inside mails.
Given that
Benji York wrote:
> One such coping mechanism is to configure mailman to not send you copies
> of messages you were sent directly via the "Avoid duplicate copies of
> messages?" option.
That's what I do, and it seems to work well enough.
When replying, sometimes I'll trim the address list down
Brett Cannon wrote:
> Or the other option is that in the future we just don't have the
> distinction and make sure that the __getitem__ methods do the requisite
> type checks. The type check is done at some point in the C code anyway
> so it isn't like there is a performance reason for the dif
Ronald Oussoren wrote:
> It is already possibly to extend the
> type struct in Python 2.3 and later
From Python?
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(type):
... __s
Talin wrote:
> The "list" version, however, is considered an internal
> method (since it's more specialized), and has the name ".tp_getitem".
Is there really a need for both the dot and the tp_
prefix? Just ".getitem" etc. ought to be sufficient.
--
Greg
_
Bill Janssen wrote:
> Incidentally, what kind of iteration should apply to files opened in
> "binary" mode
I don't think binary files should directly support
iteration at all. Wrap it in an object that iterates
the way you want.
for b in readbytes(f):
...
for blk in readblocks(f, 10
First choice: binary files should not be iterable at all. I've never
felt the need for this feature.
Second choice: binary files should iterate given the buffer size
(explicit or default) passed to open(). For unbuffered files they
should iterate over bytes.
On 11/29/06, Bill Janssen <[EMAIL PROT
Though I'm not happy with the current factoring of the "file" type at
http://wiki.python.org/moin/AbstractBaseClasses. I'm thinking this
afternoon that there should be an InputStream type and an OutputStream
type, and that the particular mix of interfaces you get back from
"open" should depend on
I would not count on GFs, but I would suggest to count on ABCs and a
better hierarchy.
E.g. look at what Bill Janssen came up with (clearly incomplete):
http://wiki.python.org/moin/AbstractBaseClasses
I think that seekability should be a dynamically determined property though.
On 11/29/06, tomer
Talin wrote:
> Now, I tend to prefer using a static table vs. the
> function-call-per-method simply because of my habits, which tend to be
> overly parsimonious with code size and such (It's a side-effect of
> working on embedded systems, which is what game consoles effectively
> are.) I would
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Some comments:
>> >
>> > - Fredrik's solution makes one call per registered method. (I don't
>> > know if the patch he refers to follows that mode
On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Have you thought much about the issue of different signature? The
> regular method table only has functions taking one or more objects and
> returning an object. (There are a few flags to indicate variations on
> the call ar
Guido van Rossum wrote:
> By all means use reply-all which CC's the author (and others). This
> seems to be what most people do, so folks who aren't using gmail yet
> have presumably developed other strategies to cope.
One such coping mechanism is to configure mailman to not send you copies
of me
On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
> (Oh, and off topic, I have a procedural question about the list: Is it
> considered good etiquette to only reply to the list, and not the
> individuals whom you are replying to? If you "reply all", then folks
> might get two copies of the message, but
Guido van Rossum wrote:
> Have you thought much about the issue of different signature? The
> regular method table only has functions taking one or more objects and
> returning an object. (There are a few flags to indicate variations on
> the call args.) The special slots have all sorts of other si
Guido:
> Agreed that for the distinction between readable/writable it's pretty
> silly, and probably just encourages LBYL code
no, the point was -- should we use separate StreamReader/StreamWriter
classes, we wouldn't need this querying, the object will fail with
AttributeError/TypeError if we att
I've updated the page to answer a few questions Jim Jewett posed, and
to expand a few more interfaces. I haven't tried to explain the
implementation types, like Code or Frame. I'm hoping someone else
will do that. I've broken up the File type into a set of types which
attempt to capture (1) the
Have you thought much about the issue of different signature? The
regular method table only has functions taking one or more objects and
returning an object. (There are a few flags to indicate variations on
the call args.) The special slots have all sorts of other signatures,
some returning int, so
25 matches
Mail list logo
