On Sun, May 25, 2008 at 3:08 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Sun, May 25, 2008 at 12:21 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'll handle the PEP 3108 dbm package if nobody else is already at it.
>>
>
> I know I have not started the work.
>
>> Two questions thoug
On Tue, May 27, 2008 at 1:36 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2008 at 06:13:39PM +1000, Nick Coghlan wrote:
>> str([1, 2, 3]), str(list("123")) and str(["1, 2, 3"]) should all produce
>> distinctive output: calling repr() on container contents achieves this,
>> callin
On 5/26/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > The problem is classes where str(x) != repr(x), and how they get
> > messed up when a container holding (one of their) instances is
> > printed.
> This is NOT a bug, since str([1, 2, 3]) and str(list("123")) SHOULD produc
On 5/26/08, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> Jim Jewett writes:
> > The only reason for this change is that __repr__ gets used when
> > __str__ *should* be used instead.
> That's not what the advocates say.
I still haven't seen a use case where it *should* be using repr *and*
On 5/27/08, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Mon, May 26, 2008 at 8:13 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > The problem is classes where str(x) != repr(x), and how they get
> > messed up when a container holding (one of their) instances is
> > printed.
> class A:
> >>
On 5/27/08, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-27 05:02, Stephen J. Turnbull wrote:
> > ... repr() Spanish and Chinese users are going to feel more or less
> > differently from Americans about which characters should be escaped.
> I'm not sure that's always the case, but users
[+python-3000]
On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
<[EMAIL PROTECTED]> wrote:
> Strings are currently iterable and it was stated multiple times that this is a
> good idea and shouldn't change. While I still don't think that that's a good
> idea I would like to propose a solution for
On 5/26/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > The problem isn't that I want to be able to write code that acts the
> > old way; the problem is that I want to ensure all code running on my
> > system acts the old way.
> This is for Py3k - you'll be lucky if your old code runs at all, let
On Tue, May 27, 2008 at 2:33 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I say that repr should (insetad) start recognizing when it was called
> in place of __str__, and should revert back to __str__ when it
> recurses down to the next level.
That sounds like a PEP you should write, which, if acce
On Tue, May 27, 2008 at 03:04:02PM -0500, Jeffrey Yasskin wrote:
> On Tue, May 27, 2008 at 2:33 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > I say that repr should (insetad) start recognizing when it was called
> > in place of __str__, and should revert back to __str__ when it
> > recurses down to
On Tue, May 27, 2008 at 3:42 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [+python-3000]
>
> On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher
> <[EMAIL PROTECTED]> wrote:
>> Basically *the* problematic situation with iterable strings is something like
>> a `flatten` function that flattens out
On Tue, May 27, 2008 at 2:03 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/26/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> > The problem isn't that I want to be able to write code that acts the
>> > old way; the problem is that I want to ensure all code running on my
>> > system acts the old w
Hi,
when doing some final checking of the new turtle module I ran into the
following problem, which I'd like to discuss with the intention to clarify
how to handle problems that result more or less from suboptimal design
decisions of the module to replace.:
(1) As requested I added an __all__ va
Guido van Rossum schrieb:
On Sun, May 25, 2008 at 3:08 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
On Sun, May 25, 2008 at 12:21 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
Hi,
I'll handle the PEP 3108 dbm package if nobody else is already at it.
I know I have not started the work.
Two qu
The old turtle.py explicitly says
from math import * # Also for export
so I think it's desirable to keep this behavior. My intent with that
line was that an absolute beginner could put "from turtle import *" in
their interactive session and be able to use both the turtle code and
the high-school
On Tue, May 27, 2008 at 1:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>>
>> On Sun, May 25, 2008 at 3:08 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>>
>>> On Sun, May 25, 2008 at 12:21 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
Hi,
I'll handle t
Guido van Rossum schrieb:
I'm not sure I disagree. I see the return value as an enum, only one
use for which is to import it. (If you wanted to just use the module,
why not use anydbm?) I'd prefer to keep the return strings the same
(no 'dbm.' prefix) and fix the code that uses whichdb.
So add
On Tue, May 27, 2008 at 2:16 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
I'm not sure I disagree. I see the return value as an enum, only one
use for which is to import it. (If you wanted to just use the module,
why not use anydbm?) I'd prefer to keep th
Guido van Rossum schrieb:
Or is there an expected future use case where the returned value would
be something in a *different* package?
There was in the past, with the now-defunct bsddb185 module which was
not used by anydbm.
Returning a module object would seem the least attractive version
Guido van Rossum schrieb:
The old turtle.py explicitly says
from math import * # Also for export
so I think it's desirable to keep this behavior. My intent with that
line was that an absolute beginner could put "from turtle import *" in
their interactive session and be able to use both the tu
Stefan Behnel wrote:
Hi,
while implementing Py_buffer support in Cython, I noticed (the hard way,
throught a segfault), that the buffer pointer passed into getbuffer() can be
NULL, e.g. when calling memoryview.tobytes(). According to PEP 3118 (first
paragraph below the getbuffer() signature), th
On Tue, May 27, 2008 at 2:37 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
>> Or is there an expected future use case where the returned value would
>> be something in a *different* package?
>
> There was in the past, with the now-defunct bsddb185 module
In the light of that, I'm not opposed to relaxing the 100%
compatibility requirement.
On Tue, May 27, 2008 at 2:40 PM, Gregor Lingl <[EMAIL PROTECTED]> wrote:
>
>
> Guido van Rossum schrieb:
>>
>> The old turtle.py explicitly says
>>
>> from math import * # Also for export
>>
>> so I think it's de
On 5/27/08, Benji York wrote:
> Guido van Rossum wrote:
> > Armin Ronacher wrote:
> >> Basically *the* problematic situation with iterable strings is something
> >> like
> >> a `flatten` function that flattens out every iterable object except of
> strings.
> > I'm not against this, but so far
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An object cannot know in general
w
Jim Jewett wrote:
So I suggest that he or she use str, rather than repr -- and that we
fix containers to make this possible.
And hope that every other author of a Python container class on the
planet does the same thing?
Recursing downwards with str() instead of repr() will break as soon as
Blake Winton wrote:
Nick Coghlan wrote:
While it could be argued that if you want unambiguous output you
should be invoking repr() on the container instead of str(), I'm still
seeing many more downsides than upsides to the idea of making str() on
the builtin containers display their contents w
M.-A. Lemburg wrote:
AFAIK, eval(repr(obj)) is no longer a requirement... simply because
it has always only worked for a small subset of objects and in
reality, you wouldn't want to call eval() on anything too often
due to the security implications.
Yes, I actually think that sentence in the d
On 5/27/08, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Blake Winton wrote:
> > But which downsides do you see that aren't solved by the use of repr to
> get unambiguous output?
> The fact that calling str() on containers has been unambiguous for years.
> All I'm saying is that no compelling use c
Blake Winton wrote:
Seriously, I can write:
>>> print 1, "1", Decimal("1")
and get as my output:
1 1 1
Yes, but you've explicitly told it to print that,
so presumably it's what you want in that case.
Equally, you need to be explicit about how you want
a list printed.
--
Greg
___
On 5/27/08, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Blake Winton wrote:
> > Seriously, I can write:
> > >>> print 1, "1", Decimal("1")
> > and get as my output:
> > 1 1 1
> Yes, but you've explicitly told it to print that,
> so presumably it's what you want in that case.
> Equally, you need
Jim Jewett wrote:
PEP 3138 says that repr should start printing unicode glyphs.
I say that repr should (insetad) start recognizing when it was called
in place of __str__, and should revert back to __str__ when it
recurses down to the next level.
But we *don't* all agree that the only case whe
Travis Oliphant wrote:
Obviously, if you
haven't provided a Py_buffer structure to fill in, then you are only
asking to lock the object's buffer from other access.
What's the use case for that? Why would you ever want
to lock an object if you don't intend to access it?
BTW, I seem to remember
Jim Jewett wrote:
Again, what is the advantage of having str(x) be redundant to repr(x)
in the case of containers?
I think you're misrepresenting the situation when you
describe it that way.
Guido didn't sit down and think "I know, let's make
str(lst) do the same as repr(lst)." He thought
"It'
Proposal to add __str__ method to iterables:
Proposed behavior of the __str__ method for iterables is that it
returns the result of "".join(str(i) for i in self).
Justification:
Notice this difference in the behavior of filter* and a list
comprehension:
>>> filter(lambda c: c!="a", "abra
35 matches
Mail list logo
