While playing around with true & floor division in Py3k...
Python 3.0a4+ (py3k:62126, Apr 3 2008, 16:28:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x=2+0j
>>> y=3+0j
>>> x / y
(0.3+0j)
>>> x//y
Tr
Found this behavior in py3k, a4...
Python 3.0a4+ (py3k:62126, Apr 3 2008, 16:28:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> r=range(10)
>>> import pickle
>>> pickle.dumps(r)
b'\x80\x03cbuiltins\nrange\nq\x00)\x81
Issue created. Sorry if this list is not meant for posting bugs.
Just trying to help out :)
http://bugs.python.org/issue2582
Thanks
--Anand
On Tue, Apr 8, 2008 at 5:58 PM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> Found this behavior in py3k, a4...
>
> Python 3.0a4+ (py3k:62126, A
Hello,
Anand Balachandran Pillai wrote:
> While playing around with true & floor division in Py3k...
>
> Python 3.0a4+ (py3k:62126, Apr 3 2008, 16:28:40)
> [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> x=2+0j
>
Hi,
There seems to be inconsistency in the way the new range(...)
type implements equality and inequality operators.
In Python 2.x, range(...) of course returns lists and when you
equate lhs of two range(...) functions over the same range, you
get True, since we are comparing equal lists.
P
Hi,
On Tue, Apr 8, 2008 at 6:50 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
> Anand Balachandran Pillai wrote:
> > While playing around with true & floor division in Py3k...
> >
> > Python 3.0a4+ (py3k:62126, Apr 3 2008, 16:28:40)
> > [GCC 4.1.2 20070626 (Red Hat 4.1
Anand Balachandran Pillai wrote:
> Issue created. Sorry if this list is not meant for posting bugs.
> Just trying to help out :)
>
> http://bugs.python.org/issue2582
Most core developers also subscribe to a python-bugs-list mailing
list, and receive any new issue.
Thanks for helping,
--
Amaur
On Tue, Apr 8, 2008 at 7:25 AM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> There seems to be inconsistency in the way the new range(...)
> type implements equality and inequality operators.
>
> In Python 2.x, range(...) of course returns lists and when you
> equate lhs of
Guido van Rossum wrote:
> I'll wait for others to jump on this bandwagon... IMO the tempfile
> object would be better off not to bother with caching at all...
I may have found a slightly more convincing example after spending a
fairly enlightening evening browsing through the source code for
weak
On Mon, Apr 7, 2008 at 4:19 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:04 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 7, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > -0.5 from me. For half of the names that the PEP prop
On Tue, Apr 8, 2008 at 12:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But I am pretty sure IronPython does not support frames access.
Really? I thought you had to pay for it (your code runs slower if they
see you use it), but that they bent over backwards to provide it.
> > OTOH I would g
Is there a reason this is not implemented, though? It's seems to me
they should be equivalent.
[snip]
--
Cheers,
Benjamin Peterson
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
h
On Mon, Apr 7, 2008 at 6:19 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:04 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 7, 2008 at 4:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > -0.5 from me. For half of the names that the PEP prop
On Tue, Apr 8, 2008 at 1:34 PM, Benjamin Peterson
<[EMAIL PROTECTED]> > Another thought: Even if other
implementations provide these
> functions, it doesn't really mean they are compatible. Allowing each
> implementation to have their own interpreter module can clear up
> confusion regarding ho
On Tue, Apr 8, 2008 at 1:27 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> Is there a reason this is not implemented, though? It's seems to me
> they should be equivalent.
Where's the use case?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Apr 8, 2008 at 4:07 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 1:34 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> > Another thought: Even if other
>
> implementations provide these
> > functions, it doesn't really mean they are compatible. Allowing each
> >
On Tue, Apr 8, 2008 at 4:29 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 1:27 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> > Is there a reason this is not implemented, though? It's seems to me
> > they should be equivalent.
>
> Where's the use case?
Educatio
On Tue, Apr 8, 2008 at 2:25 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 8, 2008 at 4:07 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 8, 2008 at 1:34 PM, Benjamin Peterson
> > <[EMAIL PROTECTED]> > Another thought: Even if other
> >
> > implementations p
On Tue, Apr 8, 2008 at 4:43 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 2:34 PM, Benjamin Peterson
>
> <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 8, 2008 at 4:29 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On Tue, Apr 8, 2008 at 1:27 PM, Benjamin Peterson
> >
On Tue, Apr 8, 2008 at 2:34 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 4:29 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 8, 2008 at 1:27 PM, Benjamin Peterson
> > <[EMAIL PROTECTED]> wrote:
> > > Is there a reason this is not implemented, thoug
On Tue, Apr 8, 2008 at 2:49 PM, Benjamin Peterson
<[EMAIL PROTECTED]> > range is one of the first functions
introduced in teaching Python.
That's only because educators were raised on Pascal for loops.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Adam Olsen wrote:
> Killing threads at arbitrary points really is that dangerous.
I'm not talking about killing an arbitrary thread, but
a particular thread that I've designed with the idea of
killing it in mind.
And I'm not really talking about killing it, either,
just having a way of tapping it
Terry Reedy wrote:
> Unfortunately, *any* text printed for any object *could* have been the
> value of a string object.
That's true, but it's sufficiently unlikely that a string
such as "" could have accidentally arisen some
other way that I don't lose any sleep over it. If weird
things seem to b
2008/4/8, Greg Ewing <[EMAIL PROTECTED]>:
> That's true, but it's sufficiently unlikely that a string
> such as "" could have accidentally arisen some
> other way that I don't lose any sleep over it. If weird
> things seem to be happening in some particular case, I'll
> put a repr() in to find
On Tue, Apr 8, 2008 at 4:46 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Killing threads at arbitrary points really is that dangerous.
>
> I'm not talking about killing an arbitrary thread, but
> a particular thread that I've designed with the idea of
> killing it in mind.
On Tue, Apr 8, 2008 at 4:49 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/4/8, Greg Ewing <[EMAIL PROTECTED]>:
> > That's true, but it's sufficiently unlikely that a string
> > such as "" could have accidentally arisen some
> > other way that I don't lose any sleep over it. If weird
>
2008/4/8, Guido van Rossum <[EMAIL PROTECTED]>:
> Seems to be mass confusion all around. My proposal is:
>
> repr(int) ==
> str(int) == 'int'
>
> For user-defined classes, a module name will always be present, e.g.
> for class C defined in __main__:
>
> repr(C) ==
> str(c) == '__main__.C'
Guido van Rossum wrote:
> Seems to be mass confusion all around. My proposal is:
>
> repr(int) ==
> str(int) == 'int'
>
> repr(C) ==
> str(c) == '__main__.C'
Can I take a step back and ask why exactly we're considering
doing this? In what use cases is the current result
of str() considered too
On Tue, Apr 8, 2008 at 5:34 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Seems to be mass confusion all around. My proposal is:
> >
> > repr(int) ==
> > str(int) == 'int'
> >
>
> > repr(C) ==
> > str(c) == '__main__.C'
>
> Can I take a step back and ask why exa
On Tue, Apr 8, 2008 at 7:00 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
> And don't tell me that I shouldn't be using isinstance().
Of course you shouldn't, obviously you just don't really _get_ Python...!
(!-)
Alex
___
Python-3000 mailing
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| There's another reason it bothers me. If a string like
| "" turns up in otherwise normal output, it's
| a fairly clear indication that I've somehow ended up
| printing something that was never meant to be printed.
Which t
Still this seems like a bad thing to break backward compatibility with.
However I cannot really provide a use-case apart from what Benjamin
has said -> Teaching. It is not a common use-case to equate ranges
in code and that is bad coding anyway.
Hopefully, this will be well documented at 3.0 relea
32 matches
Mail list logo
