OT: teleporters (Was: General Question About Python)

> -Original Message- > From: Hendrik van Rooyen [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 13, 2007 9:47 PM > To: Torabisu; python-list@python.org > Subject: Re: General Question About Python > > "Torabisu" <[EMAIL PROTECTED]> wrote: &

Re: General Question About Python

"Torabisu" <[EMAIL PROTECTED]> wrote: > > Hendrik van Rooyen wrote: > > What do you want done? - I am only a thousand miles away... > > > > If I can just get my Python teleporter sorted out, distance will be no > problem... A little buggy at the moment though... Poor John, I told > him not

Re: General Question About Python

Hendrik van Rooyen wrote: > "Torabisu" <[EMAIL PROTECTED]> wrote: > > > > > > billie wrote: > > > Torabisu wrote: > > > > > > > Its quite weird, we're looking for Python skills but are battling to > > > > find at the moment... Normally Python on its own will probably not > > > > land you a job, b

Re: General Question About Python

"Torabisu" <[EMAIL PROTECTED]> wrote: > > billie wrote: > > Torabisu wrote: > > > > > Its quite weird, we're looking for Python skills but are battling to > > > find at the moment... Normally Python on its own will probably not > > > land you a job, but the last two companies I've worked for a

Re: General Question About Python

billie wrote: > Torabisu wrote: > > > Its quite weird, we're looking for Python skills but are battling to > > find at the moment... Normally Python on its own will probably not > > land you a job, but the last two companies I've worked for are doing > > indepth Python development, so hopefully t

Re: General Question About Python

Enteng wrote: > To those who program in python, what programs do you do? > Also what community projects are you involved in(OSS probably)? > Will mastering the language land me a job? Well, I few years ago I decided to learn Python to get a job and it worked. Of course, you should think of someth

Re: General Question About Python

Enteng wrote: > To those who program in python, what programs do you do? Some Unix TCP servers, some data-driven command line apps, and some web stuff. > Also what community projects are you involved in(OSS probably)? None that are Python-based, aside from the occasional patch to support new Pyt

Re: General Question About Python

Torabisu wrote: > Its quite weird, we're looking for Python skills but are battling to > find at the moment... Normally Python on its own will probably not > land you a job, but the last two companies I've worked for are doing > indepth Python development, so hopefully the tables are turning a bi

Re: General Question About Python

I think the best I've heard is, "Programming in Python is like writing poetry". Its really a beautiful language, so simple, short, powerful and to the point. We use it in conjunction with Django to implement a web based device management solution for our products. We've also written a multi-thre

Re: General Question About Python

Enteng wrote: > To those who program in python, what programs do you do? > Also what community projects are you involved in(OSS probably)? > Will mastering the language land me a job? > > I'm thinking about learning the language as a hobby. Just curious :) If you have any programming experience yo

General Question About Python

To those who program in python, what programs do you do? Also what community projects are you involved in(OSS probably)? Will mastering the language land me a job? I'm thinking about learning the language as a hobby. Just curious :) -- http://mail.python.org/mailman/listinfo/python-list

Re: General question about Python design goals

Quoth Mike Meyer <[EMAIL PROTECTED]>: | Donn Cave <[EMAIL PROTECTED]> writes: ... |> For me, conceptually, if an object can't be accessed |> sequentially, then it can't be mapped to a sequence. | | So you're saying that for should implicitly invoke list (or maybe | iter) on any object that it's pas

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >Donn Cave <[EMAIL PROTECTED]> writes: >> >> For me, conceptually, if an object can't be accessed >> sequentially, then it can't be mapped to a sequence. > >So you're saying that for should implicitly invoke list (or maybe >ite

Re: General question about Python design goals

Donn Cave <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> > wrote: >> Seriously. Why doesn't this have to be phrased as "for x in list((1, >> 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? > How could list(t) work, if for x in t di

Re: General question about Python design goals

Alex Martelli wrote: > Yep -- "time tuples" have also become pseudo-tuples (each element can be > accessed by name as well as by index) a while ago, and I believe there's > one more example besides stats and times (but I can't recall which one). Apart from time and os.stat all the uses seem to be

Re: General question about Python design goals

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > fwiw, the tuple and class implementation were both checked into > CVS in october 1990. > > maybe he's talking about ABC? No I think I'm just plain mistaken. For some reason I thought classes came much later. It was way before my time so I defer to

Re: General question about Python design goals

Donn Cave <[EMAIL PROTECTED]> writes: > > There's a historical issue too: when tuples started first being > > used this way in Python, classes had not yet been introduced. > > When was that, old-timer? It was before my time, but I have the impression that classes arrived with 1.3 or somewhere aro

Re: General question about Python design goals

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: Seriously. Why doesn't this have to be phrased as "for x in list((1, 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? >>> because anything that supports [] can be iterated over. >> That's false. Anything t

Re: General question about Python design goals

Donn Cave wrote: > Paul Rubin wrote: > > > There's a historical issue too: when tuples started first being > > used this way in Python, classes had not yet been introduced. > > When was that, old-timer? According to Misc/HISTORY, > Python was first posted to alt.sources at version 0.9.0, > Febru

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > There's a historical issue too: when tuples started first being > used this way in Python, classes had not yet been introduced. When was that, old-timer? According to Misc/HISTORY, Python was first posted to alt.sour

Re: General question about Python design goals

Donn Cave <[EMAIL PROTECTED]> writes: > Right. After devoting a lengthy post to the defense of > tuples as a structured type, I have to admit that they're > not a very good one ... > Another theme that occasionally comes up in advice from the > learned has been "use a class". There's a historic

Re: General question about Python design goals

Mike Meyer wrote: >>> Seriously. Why doesn't this have to be phrased as "for x in list((1, >>> 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? >> because anything that supports [] can be iterated over. > > That's false. Anything that has __getitem__ supports []. To be > iterat

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: ... > So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? > > Seriously. Why doesn't this have to be phrased as "for x in list((1, > 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? How co

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Rocco Moretti <[EMAIL PROTECTED]> wrote: > People who argue that "frozen list" is not needed because we already > have the tuple type, while simultaneously arguing that tuples shouldn't > grow list methods because they are conceptually different from lists > wil

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > > Steve Holden <[EMAIL PROTECTED]> wrote: > >... > > > Presumably because it's necessary to extract the individual values > > > (though os.stat results recently became addressable by attribu

Re: General question about Python design goals

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? > because the syntax says so: > http://docs.python.org/ref/for.html In other words, "Because that's the way we do things." >> Seriously. Why doesn't this ha

Re: General question about Python design goals

On 2005-12-01, Steve Holden <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2005-12-01, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> >>>Mike Meyer wrote: >>> >>> So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? >>> >>>because the syntax says so: >>> >>>http://do

Re: General question about Python design goals

Fredrik Lundh wrote: > Rocco Moretti wrote: > I'm sure Antoon wouldn't object if lists were to be allowed as dictionary keys, which would eliminate the multiple castings for that situation. I wouldn't, either. >>> >>>so what algorithm do you suggest for the new dictionary im- >>>plemen

Re: General question about Python design goals

Rocco Moretti wrote: >>>I'm sure Antoon wouldn't object if lists were to be allowed as >>>dictionary keys, which would eliminate the multiple castings for >>>that situation. I wouldn't, either. >> >> so what algorithm do you suggest for the new dictionary im- >> plementation? > > One option is to

Re: General question about Python design goals

Fredrik Lundh wrote: > Rick Wotnaz wrote: > > >>I'm sure Antoon wouldn't object if lists were to be allowed as >>dictionary keys, which would eliminate the multiple castings for >>that situation. I wouldn't, either. > > so what algorithm do you suggest for the new dictionary im- > plementation?

Re: General question about Python design goals

Alex Martelli wrote: > Steve Holden <[EMAIL PROTECTED]> wrote: >... > > Presumably because it's necessary to extract the individual values > > (though os.stat results recently became addressable by attribute name as > > well as by index, and this is an indication of the originally intended > >

Re: General question about Python design goals

Rick Wotnaz wrote: > > Rick Wotnaz wrote: > > > >> I'm sure Antoon wouldn't object if lists were to be allowed as > >> dictionary keys, which would eliminate the multiple castings for > >> that situation. I wouldn't, either. > > > > so what algorithm do you suggest for the new dictionary im- > > p

Re: General question about Python design goals

Fredrik Lundh wrote: > Christoph Zwerschke wrote: > >>I think it is telling that you have to resort to a debate about >>bitboards vs. arrays in order to dismiss my simple use case for >>index() and count() as "unreal". > > kook. Thanks. Just to clarify: I was referring to the weakness of the ar

Re: General question about Python design goals

Steve Holden <[EMAIL PROTECTED]> wrote: ... > Presumably because it's necessary to extract the individual values > (though os.stat results recently became addressable by attribute name as > well as by index, and this is an indication of the originally intended > purpose of tuples). Yep -- "tim

Re: General question about Python design goals

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Rick Wotnaz wrote: > >> I'm sure Antoon wouldn't object if lists were to be allowed as >> dictionary keys, which would eliminate the multiple castings for >> that situation. I wouldn't, either. > > so what algorithm do you s

Re: General question about Python design goals

Rick Wotnaz wrote: > I'm sure Antoon wouldn't object if lists were to be allowed as > dictionary keys, which would eliminate the multiple castings for > that situation. I wouldn't, either. so what algorithm do you suggest for the new dictionary im- plementation? -- http://mail.python.org/ma

Re: General question about Python design goals

Aahz wrote: > This is one of those little things that happens in language evolution; > not everything gets done right the first time. But Python is developed > by volunteers: if you want this fixed, the first step is to submit a bug > report on SF (or go ahead and submit a patch if you have the e

Re: General question about Python design goals

Christoph Zwerschke wrote: > I think it is telling that you have to resort to a debate about > bitboards vs. arrays in order to dismiss my simple use case for > index() and count() as "unreal". kook. -- http://mail.python.org/mailman/listinfo/python-list

Re: General question about Python design goals

"Donn Cave" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: [...] > Tuples and lists really are intended to serve two fundamentally > different purposes. We might guess that just from the fact that > both are included in Python, in fact we hear it from Guido van > Rossum, and one might ad

Re: General question about Python design goals

Fredrik Lundh wrote: >>>Christoph Zwerschke wrote: >>Using linear arrays to represent chess boards is pretty common in >>computer chess. Often, the array is made larger than 64 elements to make >>sure moves do not go off the board but hit unbeatable pseudo pieces >>standing around the borders. But

Re: General question about Python design goals

[Since part of my post seems to have gotten lost in this thread, I figured I would repeat it] In article <[EMAIL PROTECTED]>, Aahz <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, >Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >> >>Or, another example, the index() method has start and

Re: General question about Python design goals

Steve Holden wrote: > Christoph Zwerschke wrote: >> I completely agree that his is the most frequent case. Still there are >> cases where tuples are used to keep homogenous values together (for >> instance, RGB values, points in space, rows of a matrix). In these >> cases it would be principally

Re: General question about Python design goals

On 12/1/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > I think this all boils down to the following: > > * In their most frequent use case where tuples are used as lightweight > data structures keeping together heterogenous values (values with > different types or meanings), index() and count

Re: General question about Python design goals

Mike Meyer wrote: > Paul Rubin writes: [...] > Did somebody actually use "Practicality beats purity" as an excuse for > not making list.count and string.count have the same arguments? If so, > I missed it. I certainly don't agree with that - count ought to work > right in

Re: General question about Python design goals

Christoph Zwerschke wrote: >> Christoph Zwerschke wrote: >> now, I'm no expert on data structures for chess games, but I find it hard to >> believe that any chess game implementer would use a data structure that re- >> quires linear searches for everything... > > Using linear arrays to represent c

Re: General question about Python design goals

Christoph Zwerschke wrote: > I think this all boils down to the following: > > * In their most frequent use case where tuples are used as lightweight > data structures keeping together heterogenous values (values with > different types or meanings), index() and count() do not make much sense. >

Re: General question about Python design goals

Antoon Pardon wrote: > On 2005-12-01, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > >>Mike Meyer wrote: >> >> >>>So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? >> >>because the syntax says so: >> >>http://docs.python.org/ref/for.html >> >> >>>Seriously. Why doesn't this hav

Re: General question about Python design goals

Fredrik Lundh wrote: > Christoph Zwerschke wrote: > now, I'm no expert on data structures for chess games, but I find it hard to > believe that any chess game implementer would use a data structure that re- > quires linear searches for everything... Using linear arrays to represent chess boards is

Re: General question about Python design goals

Chris Mellon schrieb: > First, remember that while your idea is obvious and practical and > straightforward to you, everybodys crummy idea is like that to them. > And while I'm not saying your idea is crummy, bear in mind that not > everyone is sharing your viewpoint. That's completely ok. What I

Re: General question about Python design goals

Christoph Zwerschke wrote: > It should be easy to imagine use cases now. > > Take for example, a chess game. You are storing the pieces in a > 64-tuple, where every piece has an integer value corresponding to its > value in the game (white positive, black negative). You can approximate > the value

Re: General question about Python design goals

I think this all boils down to the following: * In their most frequent use case where tuples are used as lightweight data structures keeping together heterogenous values (values with different types or meanings), index() and count() do not make much sense. I completely agree that his is the mos

Re: General question about Python design goals

On 2005-12-01, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > >> So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? > > because the syntax says so: > > http://docs.python.org/ref/for.html > >> Seriously. Why doesn't this have to be phrased as "for x in list((1

Re: General question about Python design goals

On 2005-12-01, Donn Cave <[EMAIL PROTECTED]> wrote: > Quoth [EMAIL PROTECTED]: >| Christoph Zwerschke wrote: > ... >|> Sorry, but I still do not get it. Why is it a feature if I cannot count >|> or find items in tuples? Why is it bad program style if I do this? So >|> far I haven't got any reasonab

Re: General question about Python design goals

Christoph Zwerschke wrote: > I understand what you want to say, but I would not use the terms > "homogenuous" or "heterogenous" since their more obvious meaning is that > all elements of a collection have the same type. http://www.google.com/search?q=duck+typing -- http://mail.python.org/m

Re: General question about Python design goals

Donn Cave schrieb: > As I'm sure everyone still reading has already heard, the natural usage > of a tuple is as a heterogenous sequence. I would like to explain this > using the concept of an "application type", by which I mean the set of > values that would be valid when applied to a particular c

Re: General question about Python design goals

On 29/11/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: > > on the other hand, it's also possible that there are perfectly usable ways > > to keep bikes and bike seats dry where Christoph works, but that he prefers > > not to use them because they're violating some design

Re: General question about Python design goals

Mike Meyer wrote: > So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? because the syntax says so: http://docs.python.org/ref/for.html > Seriously. Why doesn't this have to be phrased as "for x in list((1, > 2, 3))", just like you have to write list((1, 2, 3)).count(1), e

Re: General question about Python design goals

Mike Meyer wrote: > I get all that, I really do. I would phrase it as "a tuple is a set of > attributes that happen to be named by integers." count doesn't make > sense on the attributes of an object - so it doesn't make sense on a > tuple. index doesn't make sense on the attributes of an object -

Re: General question about Python design goals

"Donn Cave" <[EMAIL PROTECTED]> writes: > Tuples and lists really are intended to serve two fundamentally different > purposes. We might guess that just from the fact that both are included > in Python, in fact we hear it from Guido van Rossum, and one might add > that other languages also make th

Re: General question about Python design goals

Donn Cave <[EMAIL PROTECTED]> wrote: > Tuples and lists really are intended to serve two fundamentally > different purposes. > [...] > As I'm sure everyone still reading has already heard, the natural > usage of a tuple is as a heterogenous sequence. [...] A list of > command arguments is clearly h

Re: General question about Python design goals

Quoth [EMAIL PROTECTED]: | Christoph Zwerschke wrote: ... |> Sorry, but I still do not get it. Why is it a feature if I cannot count |> or find items in tuples? Why is it bad program style if I do this? So |> far I haven't got any reasonable explanation and I think there is no. | | I have no idea,

Re: General question about Python design goals

On 11/30/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > Paul Rubin wrote: > Look at the list.count() example at the start of this thread. > Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat > Python by an order of magnitude. A suitably factored imp

Re: General question about Python design goals

On 11/30/05, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Paul Rubin wrote: > >>Look at the list.count() example at the start of this thread. > >>Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat > >>Python by an order of magnitude. A suitably fact

Re: General question about Python design goals

Christoph Zwerschke wrote: > [EMAIL PROTECTED] wrote: > > Paul Rubin wrote: > >>Look at the list.count() example at the start of this thread. > >>Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat > >>Python by an order of magnitude. A suitably factored implementation > >>might ha

Re: General question about Python design goals

[EMAIL PROTECTED] wrote: > Paul Rubin wrote: >>Look at the list.count() example at the start of this thread. >>Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat >>Python by an order of magnitude. A suitably factored implementation >>might handle lists and strings with the exact sa

Re: General question about Python design goals

Paul Rubin writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> > An awful lot of the time in this newsgroup, "practicality beats >> > purity" translates as "the programmer can just be a lazy slob". >> You post that as if it were a bad thing. > Yes. The idea of using a pr

Re: General question about Python design goals

On 2005-11-29, Bengt Richter <[EMAIL PROTECTED]> wrote: > On 29 Nov 2005 08:27:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >>On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote: >>> Antoon Pardon wrote: >>> No I gave an example, you would implement differently. But even if

Re: General question about Python design goals

Paul Rubin wrote: > Look at the list.count() example at the start of this thread. > Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat > Python by an order of magnitude. A suitably factored implementation > might handle lists and strings with the exact same code and not incur > an

Re: General question about Python design goals

Mike Meyer <[EMAIL PROTECTED]> writes: > > An awful lot of the time in this newsgroup, "practicality beats > > purity" translates as "the programmer can just be a lazy slob". > > You post that as if it were a bad thing. Yes. The idea of using a program that someone else wrote, is that they do th

Re: General question about Python design goals

Paul Rubin writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> But a programming language (or UI) is not just a collection of syntax >> and and interfaces - it's an implementation. You need to keep in mind >> that "practicality beats purity". > An awful lot of the time i

Re: General question about Python design goals

Mike Meyer <[EMAIL PROTECTED]> writes: > But a programming language (or UI) is not just a collection of syntax > and and interfaces - it's an implementation. You need to keep in mind > that "practicality beats purity". An awful lot of the time in this newsgroup, "practicality beats purity" transl

Re: General question about Python design goals

Fredrik Lundh wrote: > on the other hand, it's also possible that there are perfectly usable ways > to keep bikes and bike seats dry where Christoph works, but that he prefers > not to use them because they're violating some design rule. Depends on how you understand "perfectly usable." My collegu

Re: General question about Python design goals

On 29 Nov 2005 08:27:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote: >> Antoon Pardon wrote: >> >>> >>> No I gave an example, you would implement differently. But even >>> if you think my example is bad, that would make it a bad argument >>

Re: General question about Python design goals

Steve Holden wrote: > > The bike shed effect is a good explanation and so true. About 8 years > > ago when I started to work at my current working place at the university > > I suggested that a bike shed should be provided for people like me. > > Since then, a lot of million euro projects have bee

Re: General question about Python design goals

Peter Hansen schrieb: > Christoph Zwerschke wrote: > >> Ok, these are nice aphorisms with some truth. But I had to think of >> the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein >> Genie überblickt das Chaos." ("Those who try to keep things tidy are >> just too lazy to search

Re: General question about Python design goals

On Tue, 29 Nov 2005 00:52:25 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Bengt Richter) writes: >>>Then feel free to submit patches for the docs. >> This is easy to say, and maybe the docs maintainers are accomodating, >> but I'd be the average reader wouldn't have a concept o

Re: General question about Python design goals

Christoph Zwerschke wrote: > Fredrik Lundh schrieb: [...] >>I suggest you look up the phrase "bike shed effect". next, go read some >>recent PEP:s to see what's really going on in the Python design universe. > > > The bike shed effect is a good explanation and so true. About 8 years > ago when

Re: General question about Python design goals

Mike Meyer wrote: > Christoph Zwerschke wrote: >>A programming language is not a "work of art". If you are an artist, >>you may break symmetry and introduce all kinds of unexpected >>effects. Actually, as an artist, you purposfully want to provoke >>astonishment. But if I am using a programming lan

Re: General question about Python design goals

On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: > >> >> No I gave an example, you would implement differently. But even >> if you think my example is bad, that would make it a bad argument >> for tuples having list methods. That is not the same as being >> a good argu

Re: General question about Python design goals

[EMAIL PROTECTED] (Bengt Richter) writes: >>Then feel free to submit patches for the docs. > This is easy to say, and maybe the docs maintainers are accomodating, > but I'd be the average reader wouldn't have a concept of how a "patch" > should be prepared. >From what's been said here before, the

Re: General question about Python design goals

On 27 Nov 2005 21:01:49 -0800, [EMAIL PROTECTED] (Aahz) wrote: >In article <[EMAIL PROTECTED]>, >Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >>Aahz wrote: >>> Christoph deleted his own attribution: For instance, I just wanted to use the index() method on a tuple which does not wo

Re: General question about Python design goals

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > A programming language is not a "work of art". If you are an artist, > you may break symmetry and introduce all kinds of unexpected > effects. Actually, as an artist, you purposfully want to provoke > astonishment. But if I am using a programming la

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: >Aahz wrote: >>Christoph wrote: >>>Aahz wrote: Christoph wrote: > >For instance, I just wanted to use the index() method on a tuple which >does not work. ... Because Guido believes that tuples

Re: General question about Python design goals

Christoph Zwerschke wrote: > there should be comma after "ist", Sorry, *before* "ist". I should probably stop posting for today... -- Christoph -- http://mail.python.org/mailman/listinfo/python-list

Re: General question about Python design goals

Peter Hansen <[EMAIL PROTECTED]> writes: > Christoph Zwerschke wrote: > > Ok, these are nice aphorisms with some truth. But I had to think of > > the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein > > Genie überblickt das Chaos." ("Those who try to keep things tidy are > > just to

Re: General question about Python design goals

Peter Hansen schrieb: > Christoph Zwerschke wrote: > >> Ok, these are nice aphorisms with some truth. But I had to think of >> the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein >> Genie überblickt das Chaos." ("Those who try to keep things tidy are >> just too lazy to search f

Re: General question about Python design goals

Christoph Zwerschke wrote: > Ok, these are nice aphorisms with some truth. But I had to think of the > German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein Genie > überblickt das Chaos." ("Those who try to keep things tidy are just too > lazy to search for searching - a genius survey

Re: General question about Python design goals

Fredrik Lundh schrieb: > Christoph Zwerschke wrote: > >>What about design goals such as: >> >>- orthogonality >>- coherence, consistency >>- principle of least astonishment ("Python fits my brain") >>- simplicity ("kiss" principle) >>- aesthetics, symmetry >> >>Actually, which priority have the ab

Re: General question about Python design goals

Aahz wrote: >Christoph wrote: >>Aahz wrote: >>>Christoph wrote: For instance, I just wanted to use the index() method on a tuple which does not work. ... >>> >>>Because Guido believes that tuples should be primarily used as >>>lightweight replacements for C structs. Therefore they have mi

Re: General question about Python design goals

Fredrik Lundh schrieb: > Christoph Zwerschke wrote: >>But the problem is that the tutorials and manuals give the impression >>that the difference between lists and tuples is only mutablity versus >>immutability. > > both the tutorial and the FAQ discusses the difference in terms of use > cases and

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Sebastien Douche <[EMAIL PROTECTED]> wrote: > >I use this thread to asking on python conception : why python have so >many builtins ? >I cannot understand why we use a builtins for open a file. Is it a old >decision ? If anyone have a pointer of this or can explain

Re: General question about Python design goals

Aahz wrote: > You're wrong. I don't have time/energy to look up the relevant posts, > but Guido has been extremely clear in the past that tuples are *NOT* > going to grow methods. Ah, I misread some of those other posts. Still, at least that is consistent with saying that it wasn't worth spending

Re: General question about Python design goals

Christoph Zwerschke wrote: > But the problem is that the tutorials and manuals give the impression > that the difference between lists and tuples is only mutablity versus > immutability. both the tutorial and the FAQ discusses the difference in terms of use cases and recommended usage. > Maybe I

Re: General question about Python design goals

In article <[EMAIL PROTECTED]>, Paul Boddie <[EMAIL PROTECTED]> wrote: > >In this case, I rather agree with the pragmatic responses earlier in >the thread: that it was probably an oversight that tuples lack the >count, index and (arguably) sorted methods, and that patches would >probably be welcome

Re: General question about Python design goals

Antoon Pardon wrote: > Duncan Booth wrote: > > But you aren't illustrating that at all. You came up with an example which > > showed, at least to me, a good argument why tuples should *not* have list > > methods. For what it's worth, I don't agree with that analysis, but anyway... > No I gave an

Re: General question about Python design goals

Antoon Pardon wrote: > > No I gave an example, you would implement differently. But even > if you think my example is bad, that would make it a bad argument > for tuples having list methods. That is not the same as being > a good argument against tuples having list methods. Tuples don't have li

Re: General question about Python design goals

Duncan Booth wrote: > > I'm just illustrating that some list-like methods with tuples > > could be usefull. > > > But you aren't illustrating that at all. "But assume that I have some other use case" -- http://mail.python.org/mailman/listinfo/python-list

Re: General question about Python design goals

Op 2005-11-28, Duncan Booth schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> I'm sure I could come up with an other example where I would like >> to have both some list method and use it as a dictionary key and >> again people could start about that implementation having some >> flaws and g

Re: General question about Python design goals

Antoon Pardon wrote: > I'm sure I could come up with an other example where I would like > to have both some list method and use it as a dictionary key and > again people could start about that implementation having some > flaws and give better implementations. > > I'm just illustrating that some

Re: General question about Python design goals

Op 2005-11-28, Duncan Booth schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: > >> So suppose I want a dictionary, where the keys are colours, represented >> as RGB triplets of integers from 0 to 255. A number of things can be >> checked by index-like methods. >> >> e.g. >> >> def iswhite(c

  1   2   >