Greg Ewing <[EMAIL PROTECTED]> writes:
> It might be possible to represent it in a narrower format,
> however. Perhaps there should be an explicit operation for
> re-packing a string into the narrowest possible format?
I suppose it's better to always normalize a polymorphic string
representation.
i'm quite finished with the base of iostack (streams and layers), and
have moved to implementing the adpaters layer (especially the dreaded
TextAdapter).
as was discussed earlier, streams and layers work with bytes, while
adpaters may work with arbitrary objects (be it struct-style records,
serial
While looking at the changes necessary to implement the exception
related syntax changes (except ... as ..., raise without type),
I came across some more substantial things that I think must be discussed.
* How should exceptions be represented in C code? Should there still
be a (type, value, tra
Georg Brandl <[EMAIL PROTECTED]> writes:
> * Could the traceback be made an attribute of the exception?
>
> * What about exception chaining?
>
> Something like this comes to mind::
>
> try:
> whatever
> except ValueError as err:
> raise CustomException("Something went wrong
tomer filiba wrote:
> i'm quite finished with the base of iostack (streams and layers), and
> have moved to implementing the adpaters layer (especially the dreaded
> TextAdapter).
>
> as was discussed earlier, streams and layers work with bytes, while
> adpaters may work with arbitrary objects (be
On 9/2/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
While looking at the changes necessary to implement the exceptionrelated syntax changes (except ... as ..., raise without type),I came across some more substantial things that I think must be discussed.
You have read Ping's PEP 344, right? * How sh
[Talin]
> The Java version, Java.io.BufferedReader, has a "skip()" method which
> only allows seeking forward.
> Sounds to me like copying the Java model would work.
then there's no need for it at all... just read() and discard the return value.
we don't need a special API for that.
on the other
tomer filiba wrote:
> my solution would be completely leaving seek() and tell() out of the
> 3rd layer -- it's a byte-level operation.
That's what I'd recommend, too. Seeking doesn't make
sense when the underlying units aren't fixed-length.
The best you could do would be to return some kind
of o
On 9/2/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Right, which is why the original suggestion came up in the first place. It
> would be nice to compartmentalize exceptions entirely, but the worry of
> keeping a ont of memory alive for it needs to be addressed, especially if
> exceptions are to
On 9/2/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
On 9/2/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> Right, which is why the original suggestion came up in the first place. It> would be nice to compartmentalize exceptions entirely, but the worry of
> keeping a ont of memory alive for it needs
10 matches
Mail list logo
