Annotated list callers: q = d[a,b,c] is deque simple sugar for from collections import deque q = deque( a, b, c ) might also do s = s[a,b,c] for s = set([a,b,c])
maybe d{a,b,c}? whatever, I think in python3 there will be {a,b,c} as short syntax for set([a,b,c]).
Yes, impartiality being hard to come by. Is it a deque or a set? d{a,b,c} could allow you flexibility. Don't generalize too -far-, though. This could be used anywhere, akin to r"a\bc", but don't allow users to 'cook their own'. Plenty of room but needs say so with official support. Queue.Queue, Collections.Deque, Collections.DefaultDict, set, UserGeom.Point?[1], that's all I can think of. [1] r{ p{0,0}, p{10,10} } FTR for the record, how often it's used today doesn't tell how often it will be used with convenienter syntax, impartiality still being hard to come by.
"Aaron Brady" <castironpi@comcast.net> wrote:
It's the set syntax for Python 3.0. Getting deque syntax, or a prefix for arbitrary types that are rarely used is not going to happen. There was already huge resistance to the set syntax, and those are used easily 10 times more than deques. In terms of having a syntax for deques, I honestly don't see the problem with deque([a,b,c]). It has all of 6 more characters to type than your proposed d{a,b,c} syntax, without cluttering up the language with yet another bit of syntax that can be replaced with a 2 line function... def d(*args): return deque(args) Repeat this to yourself until you realize that it's the only sane approach to Python language design: not every X line function should be made into a builtin or syntax. - Josiah
Duh, so why don't we pick out some choice N-line functions? And make those syntax. Let me know if this gets "too heated" for n/g postings, and I'll take it outside[1]. We tend to have loves; we know not what. [1]Future topics include the evolution of English from Proto-Indoeuropean, past Latin, why English is good, and hence why Python should take out some good reservations, and be like English. It's a language that gets -used-. Regular yet idiomatic, like Python could be. Dream where? Lifespan of languages is looking at a couple to few decades- not ten minutes, nor ten centuries. Let's look at leadership. You want to talk precedent?
"Ian D. Bollinger" <ian.bollinger@gmail.com> wrote:
Even with syntax, the content of the deque needs to be loaded on the stack for either a 'stack to deque' operation (like the equivalent stack to list or stack to tuple operations), or a stack to list to deque operation. And unless you are creating huge deques in-line, starting from a list won't incur any significant memory overhead as short lists (0, 4, 8, 16, etc.) are usually handled by Python's small memory allocator. If you really want to prove it to yourself that it doesn't matter, try benchmarking the difference between... d = deque(()) d = deque([]) d = deque((1,2,3,4,5,6,7,8,9,10)) d = deque([1,2,3,4,5,6,7,8,9,10]) - Josiah
Point very well taken. Gas mileage extrapolates to two things here. Running time and coding-time[1] "miles" per backend dev-time and clutter-time. Even if it's free, it's still free clutter. Guido's demonstrating efficiency pretty advisedly. [1] How expensive is it, per instance and in total, to write deque([a,b,c]) instead of d<a,b,c>?
Aaron Brady wrote:
[1] How expensive is it, per instance and in total, to write deque([a,b,c]) instead of d<a,b,c>?
I'ld be more interested in how expensive it is, per instance and in total, to _read_ deque([a,b,c]) instead of d<a,b,c>? Speaking as someone who reads way more code than they write, I find the extra verbosity of "deque" to be quite helpful, and one fewer thing I have to try to remember when reading someone else's code. Later, Blake.
maybe d{a,b,c}? whatever, I think in python3 there will be {a,b,c} as short syntax for set([a,b,c]).
Yes, impartiality being hard to come by. Is it a deque or a set? d{a,b,c} could allow you flexibility. Don't generalize too -far-, though. This could be used anywhere, akin to r"a\bc", but don't allow users to 'cook their own'. Plenty of room but needs say so with official support. Queue.Queue, Collections.Deque, Collections.DefaultDict, set, UserGeom.Point?[1], that's all I can think of. [1] r{ p{0,0}, p{10,10} } FTR for the record, how often it's used today doesn't tell how often it will be used with convenienter syntax, impartiality still being hard to come by.
"Aaron Brady" <castironpi@comcast.net> wrote:
It's the set syntax for Python 3.0. Getting deque syntax, or a prefix for arbitrary types that are rarely used is not going to happen. There was already huge resistance to the set syntax, and those are used easily 10 times more than deques. In terms of having a syntax for deques, I honestly don't see the problem with deque([a,b,c]). It has all of 6 more characters to type than your proposed d{a,b,c} syntax, without cluttering up the language with yet another bit of syntax that can be replaced with a 2 line function... def d(*args): return deque(args) Repeat this to yourself until you realize that it's the only sane approach to Python language design: not every X line function should be made into a builtin or syntax. - Josiah
Duh, so why don't we pick out some choice N-line functions? And make those syntax. Let me know if this gets "too heated" for n/g postings, and I'll take it outside[1]. We tend to have loves; we know not what. [1]Future topics include the evolution of English from Proto-Indoeuropean, past Latin, why English is good, and hence why Python should take out some good reservations, and be like English. It's a language that gets -used-. Regular yet idiomatic, like Python could be. Dream where? Lifespan of languages is looking at a couple to few decades- not ten minutes, nor ten centuries. Let's look at leadership. You want to talk precedent?
"Ian D. Bollinger" <ian.bollinger@gmail.com> wrote:
Even with syntax, the content of the deque needs to be loaded on the stack for either a 'stack to deque' operation (like the equivalent stack to list or stack to tuple operations), or a stack to list to deque operation. And unless you are creating huge deques in-line, starting from a list won't incur any significant memory overhead as short lists (0, 4, 8, 16, etc.) are usually handled by Python's small memory allocator. If you really want to prove it to yourself that it doesn't matter, try benchmarking the difference between... d = deque(()) d = deque([]) d = deque((1,2,3,4,5,6,7,8,9,10)) d = deque([1,2,3,4,5,6,7,8,9,10]) - Josiah
Point very well taken. Gas mileage extrapolates to two things here. Running time and coding-time[1] "miles" per backend dev-time and clutter-time. Even if it's free, it's still free clutter. Guido's demonstrating efficiency pretty advisedly. [1] How expensive is it, per instance and in total, to write deque([a,b,c]) instead of d<a,b,c>?
Aaron Brady wrote:
[1] How expensive is it, per instance and in total, to write deque([a,b,c]) instead of d<a,b,c>?
I'ld be more interested in how expensive it is, per instance and in total, to _read_ deque([a,b,c]) instead of d<a,b,c>? Speaking as someone who reads way more code than they write, I find the extra verbosity of "deque" to be quite helpful, and one fewer thing I have to try to remember when reading someone else's code. Later, Blake.
participants (10)
-
Aaron Brady -
Adam Atlas -
Blake Winton -
Georg Brandl -
George Sakkis -
Ian D. Bollinger -
Josiah Carlson -
Mathias Panzenböck -
Neil Toronto -
Paul Hankin