On 17/07/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
>def write(self, s: str):
>if self.closed:
>raise ValueError("write to closed file")
>if not hasattr(s, 'encode')
>raise TypeError("str expected, got %r" % s)
>...
>
> ? It explains what is
Christian Heimes wrote:
> What do you think about
>
> def write(self, s: str):
> if self.closed:
> raise ValueError("write to closed file")
> try:
> b = s.encode(self._encoding)
> except AttributeError:
> raise TypeError("str expected
Thanks! Can you add test_pickle to the wiki page?
(http://wiki.python.org/moin/Py3kStrUniTests)
On 7/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > That sounds like a good idea to try. It may break some more tests but
> > those are all indications of places tha
Guido van Rossum schrieb:
> Thanks! Can you add test_pickle to the wiki page?
> (http://wiki.python.org/moin/Py3kStrUniTests)
Done!
Martin
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscrib
On 7/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Thanks! Can you add test_pickle to the wiki page?
> > (http://wiki.python.org/moin/Py3kStrUniTests)
>
> Done!
But now I'm confused. I don't see the failure. Are you sure you
checked in what you did? In the py3
On 7/13/07, Michele Simionato <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby telecommunity.com> writes:
> > For what it's worth, the pkgutil
> > module already contains an even simpler generic function
> > implementation than simplegeneric, and is already in the stdlib
> > albeit undocumented.
>
> We
At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
>I have one remaining question for Phillip: why is your design
>"absolutely dependent on being able to modify functions in-place"?
>That dependency would appear to make it harder to port the design to
>other Python implementations whose function
On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> >I have one remaining question for Phillip: why is your design
> >"absolutely dependent on being able to modify functions in-place"?
> >That dependency would appear to make it harder to po
Hi,
It is intentional that the introspection broken for objects using
Py_FindMethod()? For example:
Python 3.0x (cpy_merge:56413:56414M, Jul 17 2007, 13:57:23)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>>> import cPickle
>>> dir(cPickle.Unpickler(file))
[]
>>> dir(cPickle.Pi
On 7/17/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It is intentional that the introspection broken for objects using
> Py_FindMethod()? For example:
>
>Python 3.0x (cpy_merge:56413:56414M, Jul 17 2007, 13:57:23)
>[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>>>> impo
At 03:53 PM 7/17/2007 -0700, Guido van Rossum wrote:
>On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> > >I have one remaining question for Phillip: why is your design
> > >"absolutely dependent on being able to modify functions in-pla
On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> >I have one remaining question for Phillip: why is your design
> >"absolutely dependent on being able to modify functions in-place"?
> It allows the framework to bootstrap via successive
Phillip J. Eby wrote:
> It allows the framework to bootstrap via successive
> approximation. Initially, the 'implies()' function is just a plain
> function, and then it later becomes a generic function. (And of
> course it gets called in between those two points.) The same happens
> for 'dis
At 09:04 PM 7/17/2007 -0400, Jim Jewett wrote:
>On 7/17/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 02:47 PM 7/17/2007 -0700, Guido van Rossum wrote:
> > >I have one remaining question for Phillip: why is your design
> > >"absolutely dependent on being able to modify functions in-place"?
>
At 01:37 PM 7/18/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > It allows the framework to bootstrap via successive
> > approximation. Initially, the 'implies()' function is just a plain
> > function, and then it later becomes a generic function. (And of
> > course it gets called in bet
> But now I'm confused. I don't see the failure. Are you sure you
> checked in what you did? In the py3k-struni branch?
Oops, no. The commit was rejected because it was not
whitespace-normalized correctly, and I didn't notice.
Now I tried again.
Martin
___
Building Py3k_struni under Cygwin I've noticed a few more tests failing than
the wiki shows.
These are using SVN revision 56413.
Some spurious errors seem to occur if Python/ is not remaned temporally. I
have not included those. (This is an oddity of the cygwin '.exe'
autohandling combined with
> When a source file contains a string literal with an out-of-range \U
> escape (e.g. "\U12345678"), instead of a syntax error pointing to the
> offending literal, I get this, without any indication of the file or
> line:
>
> UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in
> positi
> BTW I hope to see more core developers from Europe at EuroPython next year!
It's always difficult to get there for me, as it takes place during the
semester :-(
Regards,
Martin
___
Python-3000 mailing list
[email protected]
http://mail.python.or
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> When a source file contains a string literal with an out-of-range \U
> escape (e.g. "\U12345678"), instead of a syntax error pointing to the
> offending literal, I get this, without any indication of the file or
> line:
>
> UnicodeDecodeError: 'unic
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> When a source file contains a string literal with an out-of-range \U
> escape (e.g. "\U12345678"), instead of a syntax error pointing to the
> offending literal, I get this, without any indication of the file or
> line:
>
> UnicodeDecodeError: 'unic
21 matches
Mail list logo
