[Python-3000] Is it possible that some issues reported in the tracker can loose or be deleted?
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/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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. Such thing wasn't considered, I doubt it will. > > I now write (another?) ordered dict, and 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? > d.keys()[5] won't work on python 3.0 aswell because it returns a view now. > If backwards compatibility is a problem, we can make d.keys return the > same object that d.keys() currently returns, and add to the dict_keys > object a calling operation which raises a warning and returns itself. > > Of course, d.values and d.items are the same. > > Have a good day, > Noam > ___ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/ggpolo%40gmail.com > -- -- Guilherme H. Polo Goncalves ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Dropping the parentheses after dict.keys?
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 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? If backwards compatibility is a problem, we can make d.keys return the same object that d.keys() currently returns, and add to the dict_keys object a calling operation which raises a warning and returns itself. Of course, d.values and d.items are the same. Have a good day, Noam ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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 forgive me - a few minutes of > > googling didn't find it. > > Such thing wasn't considered, I doubt it will. You know, that is a very well-reasoned explanation. > > > > I now write (another?) ordered dict, and 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? > > > > d.keys()[5] won't work on python 3.0 aswell because it returns a view now. > Let me clarify myself. I just meant to say that I think that "for x in d.keys" looks better than "for x in d.keys()", and that if you create a dict subclass which has ordering, "d.keys[5]" looks really better than "d.keys()[5]". Noam ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Is it possible that some issues reported in the tracker can loose or be deleted?
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. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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 it. Yes, it was considered, and rejected over a combination of backwards compatibility and concerns that for some user-defined sequences it would be expensive to compute and hence wrong to look like a mere attribute. (The backwards compatibility concerns weren't merely of breaking every line of code in existence -- we can fix that with the 2to3 tool; they were also over user expectations.) > I now write (another?) ordered dict, and 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? > > If backwards compatibility is a problem, we can make d.keys return the > same object that d.keys() currently returns, and add to the dict_keys > object a calling operation which raises a warning and returns itself. > > Of course, d.values and d.items are the same. I'm not going to argue over your API choice for your own class, but I have to take a firm stance regarding changes to the core language and its builtins at this point. We had an extensive period for submission and review of change proposals, which ended in April. While we are still making some adjustments, we are limiting changes at this point to what appears necessary based on actual experience with the alpha releases, and your proposal doesn't fall in that category. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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 than a list. Keeping it as a method rather than a property makes sense, since it still involves the creation of an object rather than just providing access to something already existing. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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 Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Is it possible that some issues reported in the tracker can loose or be deleted?
> 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, what was the number XYZ? If not, did you get instead a red box giving some error message? If so, what was the error message? Without those details, it will be impossible to determine what happened. Just try again in case you cannot remember. The tracker will not ever lose any issues. Regards, Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Should str and bytes hash equally?
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 ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Should str and bytes hash equally?
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 unequal too. So, what do you think? 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. -- Adam Olsen, aka Rhamphoryncus ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Should str and bytes hash equally?
> 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 different way: *Why* do you think it would be good idea? Do you think it would make things more correct, or more efficient? If neither, what other desirable effect would that change have? Regards, Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Dropping the parentheses after dict.keys?
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/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Should str and bytes hash equally?
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 hash unequal too. So, what do you think?
>
> To phrase Adam Olsen's observation in a different way: *Why* do you
> think it would be good idea? Do you think it would make things more
> correct, or more efficient? If neither, what other desirable effect
> would that change have?
>
I first thought that would avoid the somehow odd behavior that appears
when mixing unicode and byte strings in dictionaries:
>>> d = {}
>>> d = {'spam': 0}
>>> d[u'spam'] = 1
>>> d
{'spam': 1}
But then, I realized this wasn't a problem anymore, in Python 3k,
since unicode string (str) and byte string (bytes) are always unequal.
However, that is not why I proposed to make the hashes unequal. I was
worry that people would be tempted to use this equality property as an
easy way (but wrong) to compare strings:
>>> hash('hello') == hash(b'hello')
True
I do realize now that it is really a weak argument. And, I don't think
anymore that it justifies changing the hashing functions.
-- Alexandre
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Should str and bytes hash equally?
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 probably won't affect anything much. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] the right way to open text files in P3K?
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 bytes if "b" is present? Or will the signature change to match the one provided by codecs? codecs.open(filename, mode[, encoding[, errors[, buffering]]]) using the logic described above regarding mode? Or some other way? Thanks! -- Mark Summerfield, Qtrac Ltd., www.qtrac.eu ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Why lowercase?
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"? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] the right way to open text files in P3K?
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, mode='r', buffering=None, encoding=None, errors=None, newline=None, closefd=True) > 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 bytes if "b" is present? The new IO library is using UTF-8 as default encoding for text mode unless a different encoding is given. The open() function and the IO streams are much closer to the codecs package. help(open) isn't very helpful in 3.0a2 and earlier. I fixed the doc string shortly after the release. import io; help(io.open) gives you the real open function. Please note that the IO library is mostly written in Python, see Lib/io.py Christian ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Why lowercase?
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 just a "wart"? Frozenset is a built-in type and not a class. All built-in types like dict and float are spelled in lower case. UserDict is a relict from the past and scheduled for removal. It's functionality is replaced by the subclass-able dict type and ABCs. Python 3.0 will be wart free. Christian ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
