M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape
M.-A. Lemburg wrote:
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does
Walter Dörwald wrote:
[...]
Sure, we could do that, but please use a different name,
e.g. .encodeall() and .decodeall() - .encode() and .decode()
are already stateles (and so would the new methods be), so
"stateless" isn't all that meaningful in this context.
I like the
Hello all!
The code coverage site at http://coverage.livinglogic.de/ was broken for
the last few months. It's fixed again now and runs the test suite once
per day with
regrtest.py -T -N -uurlfetch,largefile,network,decimal
Servus,
Walter
___
Pyth
Paul Moore wrote:
> [...]
> In all honesty, I think pkgutil.simplegeneric should be documented,
> exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
> [...]
Servus,
Walter
___
Python-Dev mailing list
Python-De
Paul Moore wrote:
2009/1/30 Walter Dörwald :
Paul Moore wrote:
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that.
I wasn't aware of the fact
Am 03.02.2012 um 01:59 schrieb Nick Coghlan :
> On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
> wrote:
>> I updated and completed my PEP and published the last draft. It will
>> be available at:
>> http://www.python.org/dev/peps/pep-0410/
>> ( or read the source: http://hg.python.org/peps/file/
On 04.06.12 13:19, Dirkjan Ochtman wrote:
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting dateti
On 26.09.12 16:43, ezio.melotti wrote:
http://hg.python.org/cpython/rev/36f61661f71e
changeset: 79194:36f61661f71e
user:Ezio Melotti
date:Wed Sep 26 17:43:23 2012 +0300
summary:
Add a few entries to whatsnew/3.3.rst.
[...]
+
+A new :data:`~html.entities.html5` dictionary th
eeps
state. The only thing that does keep state in Python is a
StreamReader/StreamWriter.
Bye,
Walter Dörwald
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
thon 2.4 (#1, Nov 30 2004, 14:16:24)
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.encoding
'ANSI_X3.4-1968'
Bye,
Walte
ly a few others don't support
decoding imcomplete input yet (although AFAICR the functionality
is mostly there in the CJK codecs).
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
oo"
x = str2("bar")
print str(x)
class unicode2(unicode):
def __unicode__(self):
return u"foo"
x = unicode2(u"bar")
print unicode(x)
---
This outputs:
foo
bar
IMHO this should be fixed so that __unicode__() is used in the
M.-A. Lemburg wrote:
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
[...]
If you drop the base class for unicode, this
Bob Ippolito wrote:
On Jan 19, 2005, at 4:40, Walter Dörwald wrote:
[...]
That's cheating! ;)
My use case is an XML DOM API: __unicode__() should extract the
character data from the DOM. For Text nodes this is the text,
for comments and processing instructions this is u"" etc. T
o is among the
direct or indirect base classes.
Simply moving the PyUnicode_Check() call in PyObject_Unicode() after the
__unicode__ call (after the PyErr_Clear() call) will implement this (but
does not fix Nick's bug). Running the test suite with this change
reveals no other problems.
Bye,
extended to sub-classes
as well.
So can we reach consensus on this, or do we need a
BDFL pronouncement?
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
> [...]
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to re
de,
click on the latest run, enter "ceval" in the "Filename" field,
click "Search" and click on the one line in the search result.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
with your request
exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
position 92: ordinal not in range(128)
I've used the distutils from current CVS and have
author=u"Walter Dörwald"
in my setup.py
Bye,
Walter Dörwald
__
> Zitat von Walter Dörwald <[EMAIL PROTECTED]>:
>
>> I've uploaded a new package to the new PyPI. Editing this
>> new packages gives me a unicode error. The URL is
>>
>> http://www.python.org/pypi?:action=submit_form&name=ll-ansistyle&version=0.6
UTF-8-SIG codec, this
should probably be relaxed to not require the BOM.
I've started writing such a codec. Making the BOM optional on decoding
definitely simplifies the implementation.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@
Martin v. Löwis sagte:
> Walter Dörwald wrote:
>> The stateful decoder has a little problem: At least three bytes
>> have to be available from the stream until the StreamReader
>> decides whether these bytes are a BOM that has to be skipped.
>> This means that if the f
__getitem__(self, key):
if key in self:
return dict.__getitem__(self, key)
else:
default = self.getdefault()
self[key] = default
return default
class multi_map(default_dict):
@staticmethod
def getdefault(self):
return []
class counting_di
quot;) | isort("uid") | \
ieval('"%s (%s)" % (_.name, _.gecos)'):
print p
The other part of the project is a curses based browser for the output
of these pipelines. See
http://styx.livinglogic.de/~walter/IPython/newdir.gif for a screenshot
of the result of i
atch (http://bugs.python.org/1101097) that should
fix this problem (at least for all codecs derived from
codecs.StreamReader/codecs.StreamWriter). Additionally it would make
stateful codecs more useful in the context for iterators/generators.
I'd like this patch to go into 2.5.
Bye,
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> Guido van Rossum wrote:
>>
>>> [...]
>>> Years ago I wrote a prototype; checkout sandbox/sio/.
>> However sio.DecodingInputFilter and sio.EncodingOutputFilter don't work
>> for encodings
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> M.-A. Lemburg wrote:
>>
>>> [...]
>>> Like I suggested in the patch discussion, such functionality could
>>> be factored out of the implementations of StreamReaders/Writers
>>> and put into
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> M.-A. Lemburg wrote:
>>> Walter Dörwald wrote:
>>>> [...]
>>>> So maybe
>>>> codecs.lookup() should return an instance of a subclass of tuple which
>>>> has the StatefulEncoder/De
_getitem__, which upto now has been
something simple and understandable.
Why don't we put the on_missing()/default_factory functionality into get()
instead?
d.get(key, default) does what it did before. d.get(key) invokes on_missing()
(and dict would have default_factory == type(None))
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>>>>> I'd suggest we keep codecs.lookup() the way it is and
>>>>> instead add new functions to the codecs module, e.g.
>>>>> codecs.getencoderobject() and codecs.getdecoderobject().
>>>>
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> M.-A. Lemburg wrote:
>>> Walter Dörwald wrote:
>>>> [...]
>>>>> Perhaps we should also deprecate codecs.lookup() in Py 2.5 ?!
>>>> +1, but I'd like to have a replacement for this, i.e. a
>
> The best I could do without hacking buildbot was to highlight the trunk
> "builder" links. This only works in Firefox, also because of IE's
> limited CSS2 support.
>
> More could be done if the HTML generation was modified, but that did
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>> I'd like to see vertical lines between the column.
>
> Can you please elaborate? Between which columns?
Something like this:
http://styx.livinglogic.de/~walter/python/buildbot.gif
>> Why is everything bold?
>
Neal Norwitz wrote:
> On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote:
>> Walter Dörwald wrote:
>>> I'd like to see vertical lines between the column.
>> I've done a version like that (still at http://www.benjiyork.com/pybb).
>
> I liked your curren
Hye-Shik Chang wrote:
> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> M.-A. Lemburg wrote:
>>> Walter Dörwald wrote:
>>>> Anyway, I've started implementing a patch that just adds
>>>> codecs.StatefulEncoder/codecs.StatefulDecoder.
't know about. The special method name ensures that it
is indeed the protocol Python is talking about, not some random method
(with next() being the exception). In the defaultdict case this isn't a
problem, because defaultdict is calling its own method.
Bye,
Walter Dörwald
_
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> Hye-Shik Chang wrote:
>>
>>> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>>> M.-A. Lemburg wrote:
>>>>> Walter Dörwald wrote:
>>>>>> Anyway, I&#
Anthony Baxter wrote:
> On Thursday 02 March 2006 01:48, Walter Dörwald wrote:
>> Any progress on this? I'd really like to get this into 2.5 and the
>> feature freeze is approaching fast!
>
> Remember, the feature freeze is as of beta1. Hopefully the major new
> fe
less error-prone
> and possible more efficient.
Another advantage might be using inline functions instead of macros with
do {foo} while(0).
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Calendar subclass.
That's because in 2.4 the module level interface was all there was.
> I don't see the attraction to any part of this.
Simple attribute access looks much more Pythonic to me than setters and gettes
(especially as the
>
> Yes, it would be best if Calendar had a property, so that sanity
> checks were performed when setting `firstweekday`, and also if the
> Calendar constructor performed that sanity check (which could happen
> "by magic" if `firstweekday` were a property).
Range chec
Nick Coghlan wrote:
> Walter Dörwald wrote:
>> [...]
>> Range checks should no longer be neccessary, as any value works now.
>
> But now all *clients* of the Calendar class are forced to deal with the fact
> that "firstweekday" may not be greater than seven.
&g
Greg Ewing wrote:
> Walter Dörwald wrote:
>
>> OK, the property setter does a "% 7" now. (But the global
>> setfirstweekday() still does a range check).
>
> Wouldn't it be better for the setter to raise an exception
> if it's out of range? It
David Goodger wrote:
> [regarding the examples in the last section of libcsv.tex]
>
> [Walter Dörwald]
>> These classes will have problems with various non-charmap encodings.
>> (E.g. the writer will write multiple BOMS for UTF-16). IMHO it would be
>> better to use
David Goodger wrote:
> [regarding the examples in the last section of libcsv.tex]
>
> [Walter Dörwald]
>> These classes will have problems with various non-charmap encodings.
>> (E.g. the writer will write multiple BOMS for UTF-16). IMHO it would be
>> better to use
Greg Ewing wrote:
> Walter Dörwald wrote:
>> Greg Ewing wrote:
>>
>>> Wouldn't it be better for the setter to raise an exception
>>> if it's out of range? It probably indicates a bug in the
>>> caller's code.
>>
>> The day be
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
If I'm not calling shared libraries from Python I can ignore ctypes. If
I'm not doing XML, I c
Anthony Baxter wrote:
> On Wednesday 19 April 2006 16:22, Walter Dörwald wrote:
>> If I'm not calling shared libraries from Python I can ignore
>> ctypes. If I'm not doing XML, I can ignore elementtree. If I'm not
>> doing SQL I can ignore pysqlite and if I&#x
Phillip J. Eby wrote:
> At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
>> With setuptools this doesn't work, because the package is distributed
>> over multiple egg-directories. AFAICR setuptools has a solution for
>> this, but only if the package __init__.py is
Fredrik Lundh wrote:
> Anthony Baxter wrote:
>
>> I also don't think it will be the "death" of distutils. I think that
>> over time the two pieces of code will become closer together -
>> hopefully for Python 3.0 we can formally merge the two.
>
> I was hoping that for Python 3.0, we could get ar
Neal Norwitz wrote:
> This is probably orthogonal to the problem, however, you may want to
> look into trying to speed up Python/errors.c. This link will probably
> not work due to sessions, but click on the latest run for python and
> Python/errors.c
>
> http://coverage.livinglogic.de/coverage/
A.M. Kuchling wrote:
> I didn't find an answer in the str.partition() thread in the archives
> (it's enormous, so easy to miss the right message), so I have two
> questions:
>
> 1) Is str.rpartition() still wanted?
>
> 2) What about adding partition() to the re module?
And what happens if the s
Guido van Rossum wrote:
> On 5/26/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> [...]
>> And what happens if the separator is an instance of a subclass?
>>
>> class s2(str):
>> def __repr__(self):
>> return "s2(%r)" % str(self)
>
H.Yamamoto wrote:
>> If you plan to make a checkin adding a feature (even a simple one),
>> you oughta let people know by responding to this message. Please get
>> the bug fixes in ASAP. Remember to add tests!
>
> Is there any chance to fix mbcs bug? I think this is critical...
> My patch is he
H.Yamamoto wrote:
> - Original Message -
> From: "Walter Dörwald" <[EMAIL PROTECTED]>
> To: "H.Yamamoto" <[EMAIL PROTECTED]>
> Cc: "python-dev"
> Sent: Friday, June 09, 2006 7:56 PM
> Subject: Re: [Python-Dev] beta1 coming re
Neal Norwitz wrote:
> All are missing parameters. I'm not sure of the proper signature, so
> I didn't fix these:
>
> Lib/encodings/punycode.py:217: No global (errors) found
> Lib/encodings/utf_8_sig.py:33: No global (errors) found
> Lib/encodings/uu_codec.py:109: No global (errors) found
Fixed
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>>>> The best way to throughly test the patch is of course to check it in. ;)
>>> Is it too risky? ;)
>> At least I'd like to get a second review of the patch.
>
> I've reviewed it, and am likely to che
I have a small patch http://bugs.python.org/1506645 that adds
resizeterm() and resize_term() to the curses module. Can this still go
in for beta1? I'm not sure, if it needs some additional configure magic.
Servus,
Walter
___
Python-Dev mailing list
P
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>> I have a small patch http://bugs.python.org/1506645 that adds
>> resizeterm() and resize_term() to the curses module. Can this still go
>> in for beta1? I'm not sure, if it needs some additional configure magic.
>
>
Scott Dial sagte:
> Walter Dörwald wrote:
>> Martin v. Löwis wrote:
>>> It does need a configure test, though.
>>
>> Unfortunately I have no idea how this whole configure business works!
>
> I got bored. I posted a comment to the bug, which will direct you to
Benji York wrote:
> Brett Cannon wrote:
>> But it does seem accurate; random checking of some modules that got high
>> but not perfect covereage all seem to be instances where dependency
>> injection would be required to get the tests to work since they were
>> based on platform-specific things
Titus Brown wrote:
> On Mon, Jun 19, 2006 at 08:37:30AM -0400, Benji York wrote:
> -> Brett Cannon wrote:
> -> >But it does seem accurate; random checking of some modules that got high
> -> >but not perfect covereage all seem to be instances where dependency
> -> >injection would be required to
ime.fromtimestamp(time.time()) gives you the same thing as
>> datetime.now().
>>
>
> In which case, it's also easy enough to get a datetime if you
> really want one. I personally would rather do that than complicate
> the use cases where a datetime isn't reall
try:
BLOCK
except:
exc = sys.exc_info()
raise
finally:
abc.__exit__(*exc)
literally would indicate the former.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev
Guido van Rossum wrote:
> On 7/7/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>>What is still unspecified (or at least not explicitely mentioned) in
>>the PEP is the lifetime of VAR in:
>>
>> with EXPR as VAR:
>> BLOCK
>
> It
Michael Hudson wrote:
> Walter Dörwald <[EMAIL PROTECTED]> writes:
> [...]
>>I.e. will VAR still exist after the end of the block with its value
>>the return value of __enter__() or will it revert to the previous
>>value (if any)?
>
> Eh, no. Where would yo
st of them are fixed. #1178484 is waiting for a final OK.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
on.org machines can probably handle the load of *one*
repository better then the SF machines that of several thousands.
* Connectivity to python.org is much better then to cvs.sf.net (at
least from here).
* Our company repository might move to svn in the near future, so a
Python svn reposito
at least we'd get proper treatment of "\n",
"\r" and "\r\n" line ends, but we'd loose u"\x1c", u"\x1d", u"\x1e",
u"\x85", u"\u2028" and u"\u2029" (which are line terminators according
t
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>This is caused by the chances to the codecs in 2.4. Basically the codecs
>>no longer rely on C's readline() to do line splitting (which can't work
>>for UTF-16), but do it themselves (via unicode.splitlines(
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>I think a maxsplit argument (just as for unicode.split()) would help too.
>
> Correct - that would allow to get rid of the quadratic part.
OK, such a patch should be rather simple. I'll give it a try.
> We should al
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>Martin v. Löwis wrote:
>>
>>>Walter Dörwald wrote:
>>>
>>>>I think a maxsplit argument (just as for unicode.split()) would help
>>>>too.
>>>
>>>Correct - that would
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>
>>I wonder if we should switch back to a simple readline() implementation
>>for those codecs that don't require the current implementation
>>(basically every charmap codec).
>
> That would be my preference as
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>At least it would remove the quadratic number of calls to
>>_PyUnicodeUCS2_IsLinebreak(). For each character it would be called only
>>once.
>
> Correct. However, I very much doubt that this is the cause of the
&g
Am 24.08.2005 um 21:15 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>
>>> Right. Not sure what people think whether this should still be
>>> supported, but I keep supporting it whenever I think of it.
>>>
>>
>> OK, so should we add
Am 24.08.2005 um 20:20 schrieb Greg Wilson:
>>> Walter Dörwald wrote:
>>>
>>>> At least it would remove the quadratic number of calls to
>>>> _PyUnicodeUCS2_IsLinebreak(). For each character it would be
>>>> called only
>>>> once
gt; decode('mac-roman') 22.8x as long
> decode('iso8859-1') 23.0x as long
>
> Perhaps this is an area that is ripe for optimization.
For charmap decoding we might be able to use an array (e.g. a tuple
(or an array.array?) of codepoints instead of dictionary.
Or w
Am 04.10.2005 um 21:50 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>> For charmap decoding we might be able to use an array (e.g. a
>> tuple (or an array.array?) of codepoints instead of dictionary.
>>
>
> This array would have to be sparse, of course.
For
Am 05.10.2005 um 00:08 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>>> This array would have to be sparse, of course.
>>>
>> For encoding yes, for decoding no.
>>
> [...]
>
>> For decoding it should be sufficient to use a unicode string
#x27;*53*1024; u=unicode(s)" "s.decode('mac-roman')"
1000 loops, best of 3: 623 usec per loop
Creating the decoding_map as a string should probably be done by
gencodec.py directly. This way the first import of the codec would be
faster too.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>> OK, here's a patch that implements this enhancement to
>> PyUnicode_DecodeCharmap(): http://www.python.org/sf/1313939
>
> Looks nice!
>
>> Creating the decoding_map as a string should probably be done
es in a single
> pass over the dictionary, so startup time should be fairly small
> (given that the dictionaries are currently built incrementally, anyway,
> due to the way dictionary literals work).
Bye,
Walter Dörwald
___
Python-Dev mailing list
P
write their own codecs
> if they need to modify an existing one and then hook it into
> the system using either a new codec search function or by
> adding an appropriate alias.
OK, so can someone update gencodec.py and recreate the charmap codecs?
BTW, is codecs.
ng an
existing one on the fly!
Of course we can't accept Pyrex code in the Python core, so it would be
great to rewrite the encoder as a patch to PyUnicode_EncodeCharmap().
This version must be able to cope with encoding tables that are random
strings without crashing.
We've alre
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I've checked in a whole bunch of newly generated codecs
>>which now make use of the faster charmap decoding variant added
>>by Walter a short while ago.
>>
>>Please let me know if you find any problems.
>
> I think we should work on eliminating t
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>
>>Martin v. Löwis wrote:
>>
>>>M.-A. Lemburg wrote:
>>>
>>>>I've checked in a whole bunch of newly generated codecs
>>>>which now make use of the faster charmap decoding variant adde
\u136c\u2082")
42
>>> float(u"\u0664\u09e8")
42.0
But not as literals:
# -*- coding: unicode-escape -*-
print \u136c\u2082
This gives (on the Mac):
File "encoding.py", line 3
print ፬₂
^
SyntaxError: invalid syntax
> [...]
Bye,
Walter Dör
[EMAIL PROTECTED] wrote:
> The Python source code repository is now converted to subversion;
> [...]
Thanks for doing this.
BTW, will there be daily tarballs, like the one available from:
http://cvs.perl.org/snapshots/python/python/python-latest.tar.gz
Bye,
Walter D
Am 27.10.2005 um 19:18 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>> Thanks for doing this.
>> BTW, will there be daily tarballs, like the one available from:
>> http://cvs.perl.org/snapshots/python/python/python-latest.tar.gz
>>
>
> Will be, yes
file".
Should they raise the same exception? Should this be fixed for 2.5?
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
Am 17.11.2005 um 22:03 schrieb Guido van Rossum:
> On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Currently StringIO.StringIO and cStringIO.StringIO behave differently
>> when iterating a closed stream:
>>
>> s = StringIO.StringIO("foo&
Am 18.11.2005 um 02:16 schrieb Guido van Rossum:
> On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Am 17.11.2005 um 22:03 schrieb Guido van Rossum:
>>
>>> On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>>> [...]
>>>>
Guido van Rossum wrote:
> On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>>Am 17.11.2005 um 22:03 schrieb Guido van Rossum:
>>
>>
>>>On 11/17/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>>
>>>>Currently StringIO.Strin
>>> import StringIO, cStringIO
>>> s = StringIO.StringIO()
>>> s.truncate(-42)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate
raise IOError(EINVAL, "Negative size not allowed")
IOError: [Errno 22] Negative si
Guido van Rossum wrote:
> On 11/18/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>> >>> import StringIO, cStringIO
>> >>> s = StringIO.StringIO()
>> >>> s.truncate(-42)
>>Traceback (most recent call last):
>> File "
Paul Svensson wrote:
> On Fri, 18 Nov 2005, Walter Dörwald wrote:
>
>> BTW, isatty() has a similar problem:
>>
>> >>> import StringIO, cStringIO
>> >>> s = StringIO.StringIO()
>> >>> s.close()
>> >>> s.isatty()
&g
15:51:22)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system("python < .")
35584
>>> os.system("python < /dev/null&q
me test_callbacks() is called
Can you move the call to codecs.register_error() out of test_callbacks()
and retry?
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Neal Norwitz wrote:
> On 11/25/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Can you move the call to codecs.register_error() out of test_callbacks()
>> and retry?
>
> It then leaks 3 refs on each call to test_callbacks().
This should be fixed now in r41555 a
101 - 200 of 212 matches
Mail list logo
