I reported a pair of issues in diferent dates, last one was 3 days
ago. However, each time I save and verify the status, it dissapears
from the tracker. Why does it occur?
Thanks!
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/
2007/12/13, Noam Raphael <[EMAIL PROTECTED]>:
> Hello,
>
> Was it considered to drop the parentheses after "dict.keys()", to make
> it "dict.keys" (that is, to make it a property instead of a method
> with no arguments)? If it was, please forgive me - a few minutes of
> googling didn't find it.
Su
Hello,
Was it considered to drop the parentheses after "dict.keys()", to make
it "dict.keys" (that is, to make it a property instead of a method
with no arguments)? If it was, please forgive me - a few minutes of
googling didn't find it.
I now write (another?) ordered dict, and I thought that the
2007/12/13, Guilherme Polo <[EMAIL PROTECTED]>:
> 2007/12/13, Noam Raphael <[EMAIL PROTECTED]>:
> > Hello,
> >
> > Was it considered to drop the parentheses after "dict.keys()", to make
> > it "dict.keys" (that is, to make it a property instead of a method
> > with no arguments)? If it was, please
Vizcayno> I reported a pair of issues in diferent dates, last one was 3
Vizcayno> days ago. However, each time I save and verify the status, it
Vizcayno> dissapears from the tracker. Why does it occur?
I don't know. I passed your mail along to the people who manage the
tracker.
--
On Dec 13, 2007 1:24 AM, Noam Raphael <[EMAIL PROTECTED]> wrote:
> Was it considered to drop the parentheses after "dict.keys()", to make
> it "dict.keys" (that is, to make it a property instead of a method
> with no arguments)? If it was, please forgive me - a few minutes of
> googling didn't find
Noam Raphael wrote:
> I thought that the easiest
> way to get the key with a given index would be "d.keys[5]". But it
> means that d.keys is a collection of keys, not a method - and why not?
Half of your suggestion is being done -- d.keys() will create
and return an indexable view object, rather t
I wrote:
> d.keys() will create
> and return an indexable view object,
Sorry, that's not quite right -- it probably won't be
indexable, only iterable.
But the argument for keeping it as a method still
applies.
--
Greg
___
Python-3000 mailing list
Pytho
> I reported a pair of issues in diferent dates, last one was 3 days
> ago. However, each time I save and verify the status, it dissapears
> from the tracker. Why does it occur?
Can you report more details? When you did "Submit changes", did you get
a green box saying "issue XYZ created"? If so, w
In Python 2.x, having the byte string and unicode hash equally was
desirable, since u'' == ''. But since the bytes and str are always
considered unequal, in Python 3k, I think would be good idea to make
their hash unequal too. So, what do you think?
-- Alexandre
___
On Dec 13, 2007 3:42 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> In Python 2.x, having the byte string and unicode hash equally was
> desirable, since u'' == ''. But since the bytes and str are always
> considered unequal, in Python 3k, I think would be good idea to make
> their hash uneq
> In Python 2.x, having the byte string and unicode hash equally was
> desirable, since u'' == ''. But since the bytes and str are always
> considered unequal, in Python 3k, I think would be good idea to make
> their hash unequal too. So, what do you think?
To phrase Adam Olsen's observation in a
Thanks for the explanation. I'm sure that I will be able to live
(although miserably) with dict.keys(). ;)
Noam
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/m
On Dec 13, 2007 6:03 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > In Python 2.x, having the byte string and unicode hash equally was
> > desirable, since u'' == ''. But since the bytes and str are always
> > considered unequal, in Python 3k, I think would be good idea to make
> > their ha
Adam Olsen wrote:
> It's irrelevant. It's always possible to get the same hashes. We'd
> need a performance reason or the like to bother changing either of
> them.
And since there's no reason to think that storing bytes
and unicode in the same dict is likely to be a frequent
requirement, it prob
Hi,
I was wondering if it is yet known what the right way to open text files
in P3K will be?
According to the docs the signature for open() is:
open(filename[, mode[, bufsize]])
Is that going to stay the same and default to UTF-8 if "b" is not in the
mode (or if no mode is specified) and by
I don't think there is any chance that this will change in python 3000
but...
Why is the builtin types lowercase when the convention is for classes to be
in CamelCase? For example, frozenset versus UserDict. Was there any reason
that this is the way it is or is it just a "wart"?
___
Mark Summerfield wrote:
> Hi,
>
> I was wondering if it is yet known what the right way to open text files
> in P3K will be?
>
> According to the docs the signature for open() is:
>
> open(filename[, mode[, bufsize]])
The docs must be outdated. open() accepts more arguments:
open(file, mod
hashcollision wrote:
> I don't think there is any chance that this will change in python 3000
> but...
> Why is the builtin types lowercase when the convention is for classes to be
> in CamelCase? For example, frozenset versus UserDict. Was there any reason
> that this is the way it is or is it jus
19 matches
Mail list logo
