Re: Making immutable instances

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> "Giovanni Bajo" <[EMAIL PROTECTED]> writes: >> > Mike Meyer wrote: >> >> Note that this property of __slots__ is an implementation detail. You >> >> can&

Re: Making immutable instances

Ben Finney <[EMAIL PROTECTED]> writes: > I'm looking for a "consenting adults" restriction: classes will have > immutable instances only where it makes sense from the class protocol. > I'm not going to lose sleep over users who go looking for trouble. I think you're defining immutable differently

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: >> The usual response is "That's not the Python way." That's not calling >> someone dumb, just pointing out that they don't yet fully understand >> the Python way. > "That is not the Python way", is just saying "Python doesn't have it" > in other words. So

Re: return in loop for ?

Roy Smith <[EMAIL PROTECTED]> writes: > In any case, in a language which has exceptions, it's almost impossible to > really have true SESE, since an exception could be thrown from almost > anywhere. To be fair, there are those who use this to argue that > exceptions themselves are a bad thing.

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > - Because sets can only contain immutable values Not true. Sets can only contain *hashable* objects, which isn't the same thing. > This, of course, in turn raises the question ;-) Would it be desirable > to have an additional, more general set dat

Re: wxPython Licence vs GPL

"Martin P. Hellwig" <[EMAIL PROTECTED]> writes: >> "Martin P. Hellwig" <[EMAIL PROTECTED]> writes: >>> If the non-techie is still interested, I'll rave on about that I >>> understand why GPL is a good way to ensure availability of IP >>> especially if the software is a collaborated effort in the ac

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: >>>- Because sets can only contain immutable values > > Mike Meyer wrote: > >> Not true. Sets can only contain *hashable* objects, which isn't the >> same thing. > > I trusted the doco which defines a

Re: wxPython Licence vs GPL

"Martin P. Hellwig" <[EMAIL PROTECTED]> writes: > Those who can not afford the software are excluded for that end > product even though they may have worked on the source where 99,99% of > the restricted licensed software is based on. Well, they chose to make it available to others for reuse. But

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer schrieb: >> If the hash changes, you've screwed up the set. What it really should >> say is "collection of objects with fixed hashes", or words to that >> effect. Do you want to file a PR on this

Re: Python as Guido Intended

[EMAIL PROTECTED] writes: > "Mike Meyer" <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] writes: >> > Different programming styles are appropriate for different >> > tasks, different times and different places, different people. >> > And like

Re: Why is dictionary.keys() a list and not a set?

"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >>>I trusted the doco which defines a set as "an unordered collection of >>>immutable values" (http://docs.python.org/lib/types-set.html). >> If the hash changes, you&#

Re: wxPython Licence vs GPL

"Martin P. Hellwig" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > >> Well, they chose to make it available to others for reuse. But >> software "unavailable to those who can't afford it" is better than "no >> software at all"

Re: wxPython Licence vs GPL

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> On the other hand, so long as the price is lower than the cost of >> recreating the software for someone, then it's better for society as >> a whole if it exists

Re: Making immutable instances

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >>>> Note that this property of __slots__ is an implementation detail. >>>> You >>>> can't rely on it working in the future. >>> I don't "rely" on it

Re: Making immutable instances

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Björn Lindström wrote: > Why do you think we have a frozenset, for instance? By Mike's argument, we > shouldn't have it. Not *my* arguments, certainly. Not unless you're seriously misinterpreting them. http://www.mired.org

Re: Making immutable instances

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> And I have no problems with that. If you believe your class should >> throw an error if someone calls an instances pop() method when it's >> empty, do so. >> Likewise, if y

Re: Making immutable instances

Paul Rubin writes: > "Giovanni Bajo" <[EMAIL PROTECTED]> writes: >> > However, when you prevent a client from adding an attribute, you're >> > not merely making your objects immutable, you're making them >> > static. > No I don't believe that. If an object is immutable,

Re: Making immutable instances

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >>> Björn Lindström wrote: >>> Why do you think we have a frozenset, for instance? By Mike's >>> argument, we shouldn't have it. >> Not *my* arguments, certainly. Not un

Re: Why is dictionary.keys() a list and not a set?

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Christoph Zwerschke wrote: >> [EMAIL PROTECTED] schrieb: >> > You can already get a set from a dictionary's keys in an efficient manner: >> l = dict.fromkeys(range(10)) >> set(l) >> > Set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) >> Good point. I expe

Re: Why is dictionary.keys() a list and not a set?

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> Not all tuples can be elements of a set. Elements of a set have to be >> hashable. Tuples compute their hash by hashing their contents. If >> their contents aren't hashable, the tuple isn't hashable, and hence >> can't be an element of a set. If th

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > As a general note, I think it would be good to place the exact > description in a footnote, since speaking about hashable objects, > __hash__ and __cmp__ will certainly frighten off newbies and make it > hard to read even for experienced users. The

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-24, Mike Meyer schreef <[EMAIL PROTECTED]>: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>>> The usual response is "That's not the Python way." That's not calling >>>&g

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: > Well this is, is one thing I have a problem with. > > The python people seem to be more concerned with fighting things > that could be used counter the python philosophy, than search for > things that enable working in the python philosophy. And what's w

Re: Making immutable instances

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> There isn't a standard serialize method in Python, so I don't know how >> you want to define it. >> I can think of perfectly reasonable definitions >> of se

Re: wxPython Licence vs GPL

"Paul Boddie" <[EMAIL PROTECTED]> writes: > Ed Jensen wrote: > [On proprietary ports of Python...] >> Show me the harm done. > We'll have to wait and see what happens. There's a risk that versions > of Python with different semantics or characteristics to the original > could cause the development

Re: Which License Should I Use?

"mojosam" <[EMAIL PROTECTED]> writes: > I will be doing the bulk of the coding on my own time, because I need > to be able to take these tools with me when I change employers. > However, I'm sure that in the course of using these tools, I will need > to spend time on the job debugging or tweaking t

Re: Which license should I use?

[EMAIL PROTECTED] (Björn Lindström) writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> IANAL, but I don't believe the GPL helps in this situation. It places >> conditions on redistributing the code; it doesn't force you to >> redistribute modifieed code. Y

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer schrieb: >> Ok, how about this for dictionaries/sets: >> Any hashable object can be used as a dictionary key (set >> member). Immutable >> objects, except for tuples that contain a non-hashable object, ar

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > The mutability - or immutability - of an object is irrelevant to > > the question of whether or not they can be a dictionary key/set > > element. The critical property is that they are hash

Re: Making immutable instances

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Thu, 24 Nov 2005 11:44:16 -0500, Mike Meyer wrote: >> In Python, I can even fix >> it so *your* code uses my wrapped version: >> >> import Finney >> class Addable(Finnney.Immutable): pass >> Finney.

Re: wxPython Licence vs GPL

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Thu, 24 Nov 2005 16:00:29 -0500, Mike Meyer wrote: > The GPL doesn't restrict distribution. I don't understand where > people get this bizarre view of the GPL from.> It happens because people say things like: >

Re: Making immutable instances

Steven D'Aprano <[EMAIL PROTECTED]> writes: > "Hmmm, the class designer didn't want me adding attributes to instances... > maybe he had a good reason for that..." When it was suggested that a facility for doing this be added to the language, I asked for a use case for it. Nobodies come up with a r

Re: wxPython Licence vs GPL

Steven D'Aprano <[EMAIL PROTECTED]> writes: > But if you *do* redistribute it, then you must live up to conditions in > the licence. If you aren't willing to do that, use software with a > different licence. That's a restriction on redistribution. > The only restriction is that you can't give th

Re: Python as Guido Intended

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Those two statements say the same thing. Part of the Python philosphy, >> from "import this", is that there should only be one obvious way to do >> it. By enabl

Re: Making immutable instances

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: >> If you've got a use case, I'd be interested in hearing it. > frozenset perhaps? If it were needed once, it could be needed again. That's not a use case,

Re: Which License Should I Use?

Steve Holden <[EMAIL PROTECTED]> writes: > Simply assuming that because you have developed the code "in your own > time" you have sole rights to it, or even a right to redistribute, is > likely to lead to trouble and I would recommend against that course of > action. The employment agreement may s

Re: Why is dictionary.keys() a list and not a set?

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > I think you're trying to tweak the wrong definition. Types are > > immutable if their instances are immutable. > I'm not trying to tweak it, but to gain more clarity about what is &g

Re: Making immutable instances

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Sat, 26 Nov 2005 04:59:59 -0500, Mike Meyer wrote: >> Steven D'Aprano <[EMAIL PROTECTED]> writes: >>> On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: >>>> If you've got a use case, I&#x

Re: Why is dictionary.keys() a list and not a set?

"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >>>class mylist1(list): >>> def __hash__(self): return 0815 >>> >>>class mylist2(list): >>> def __hash__(self): return id(self) >>> >>>In the

Re: wxPython Licence vs GPL

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Sat, 26 Nov 2005 04:46:15 -0500, Mike Meyer wrote: >> Steven D'Aprano <[EMAIL PROTECTED]> writes: >>> But if you *do* redistribute it, then you must live up to conditions in >>> the licence. If y

New docs for set elements/dictionary keys (Was: Why is dictionary.keys() a list and not a set?)

"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >>>This is not true. The second definition of __hash__ does not meet >>>the specifications: >> The specification isn't on the __hash__ method, but on objects. > What does it

Re: CGI question

Dan Stromberg <[EMAIL PROTECTED]> writes: > On Sat, 26 Nov 2005 13:26:11 +0100, Fredrik Lundh wrote: >> Dan Stromberg wrote: >>> What's the best way of converting this: >>> 'hide\\?http://www.dedasys.com/articles/programming_language_economics.html\x012005-07-20 >>> 14:48' >>> ...to something easil

Re: Nested list comprehensions

[EMAIL PROTECTED] writes: > Hey guys: > [(i,j,k) for i in range(1,j) for j in range(1,k) for k in range(1,5)] > [(1, 1, 1), (1, 1, 2), (1, 1, 3), (1, 1, 4), (1, 2, 1), (1, 2, 2), (1, > 2, 3), (1, 2, 4), (1, 3, 1), (1, 3, 2), (1, 3, 3), (1, 3, 4), (2, 1, > 1), (2, 1, 2), (2, 1, 3), (2, 1, 4), (

Re: wxPython Licence vs GPL

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Sat, 26 Nov 2005 18:18:44 -0500, Mike Meyer wrote: >> So that's the basis of the disagreement. I'm using "restriction" with >> the intent of communicating it's normal english meaning, > Your m

Re: Which License Should I Use?

"Andrew Koenig" <[EMAIL PROTECTED]> writes: > I'm pretty sure that there was a change to the copyright laws a few years > ago (perhaps as part of the DMCA), that made it clear that you own > everything you produce, unless you're a W-2 employee or there is a written > agreement to the contrary.

Re: New docs for set elements/dictionary keys

"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> Personally, I think we'd be better off to come up with a term for this >> property that doesn't have a commonly understood meaning that has such >> broad areas of disagreement

Re: New docs for set elements/dictionary keys

"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Me, personally, I had your definition in mind: hashable should indicate > "returns a value constant over time and consistent with comparison". > > I suggested that most people would consider "hashable" to mean: > hash() returns a value. To those peopl

Re: New docs for set elements/dictionary keys

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> Any object for which hash() returns an appropriate value(1) can be >> used as a dictionary key/set element. Lists, sets and dicts are not >> hashable, and can not be used. Tuples can be used if all

Death to tuples!

It seems that the distinction between tuples and lists has slowly been fading away. What we call "tuple unpacking" works fine with lists on either side of the assignment, and iterators on the values side. IIRC, "apply" used to require that the second argument be a tuple; it now accepts sequences, a

Re: type of form field

"Ajar" <[EMAIL PROTECTED]> writes: > Is there any way to retrieve the type(checkbox,radio...) of the form > field from cgi.FieldStorage. I tried something like form['name'].type, > but this field seems to be None for all the form fields There isn't. cgi.FieldStorage parses data sent via an HTTP re

Re: return in loop for ?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Mon, 28 Nov 2005 10:02:19 +0100, Sybren Stuvel wrote: >> Duncan Booth enlightened us with: >>> I would have thought that no matter how elaborate the checking it is >>> guaranteed there exist programs which are correct but your verifier >>> cannot pro

Re: Precision for equality of two floats?

Anton81 <[EMAIL PROTECTED]> writes: > When I do simple calculation with float values, they are rarely exactly > equal even if they should be. What is the threshold and how can I change > it? Implementation dependent, because floats use an underlying C type, and there's no portable way to do that.

Re: Death to tuples!

Steven Bethard <[EMAIL PROTECTED]> writes: > Dan Bishop wrote: >> Mike Meyer wrote: >> >>>Is there any place in the language that still requires tuples instead >>>of sequences, except for use as dictionary keys? >> The % operator for strings. And in

Re: Death to tuples!

Peter Hansen <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> It seems that the distinction between tuples and lists has slowly been >> fading away. What we call "tuple unpacking" works fine with lists on >> either side of the assignment, and iterators on t

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: > Op 2005-11-25, Mike Meyer schreef <[EMAIL PROTECTED]>: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>> Well this is, is one thing I have a problem with. >>> The python people seem to be more concerned with f

Re: Death to tuples!

[EMAIL PROTECTED] writes: > Mike> Tuples have the problem that they are immutable, except when > Mike> they're not (or for proper values of immutable, your > Mike> choice). They're hashable, except when they're not. Or > Mike> equivalently, they can be used as dictionary keys - or s

Re: return in loop for ?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Which means you can't create a verifier which will verify all >> programs. Is there a reason to believe that you can't have a verifier >> with three possible out

Re: return in loop for ?

Paul Rubin writes: > I don't know about the BCPL type verifier but every statically typed > language verifies certain assertions about the types of expressions > and this is useful. BCPL is untyped. You can perform any operation on any variable. You can use the floating

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: New docs for set elements/dictionary keys

Christoph Zwerschke <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> Christoph Zwerschke wrote: >>>I think that is not so bad. How about this simplification: >>> >>>Any hashable object(1) can be used as a dictionary key/set >>>element. Lis

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: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: >> You see, you can make languages more powerful by *removing* things >> from it. > You cast this in way to general terms. The logic conclusion > from this statements is that the most powerfull language > is the empty language. The only way you reach that

Re: Death to tuples!

Duncan Booth <[EMAIL PROTECTED]> writes: > Dan Bishop wrote: >>> Is there any place in the language that still requires tuples instead >>> of sequences, except for use as dictionary keys? >> >> The % operator for strings. And in argument lists. >> >> def __setitem__(self, (row, column), value):

Re: Which License Should I Use?

"Andrew Koenig" <[EMAIL PROTECTED]> writes: > "Mike Meyer" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Definitely not. The most recent change to the copyright laws made >> works of music recorded to fullfill a contract &quo

Re: ncurses' Dark Devilry

Jeremy Moles <[EMAIL PROTECTED]> writes: > Basically what I'm looking for is a way to refresh a portion of a > curses-controlled "window" without affecting the current location of the > cursor or having to manually move it and move it back. Have you looked into using curses window feature?

Re: Making immutable instances

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> When it was suggested that a facility for doing this be added to the >> language, I asked for a use case for it. Nobodies come up with a >> reason for placing such restriction

Re: General question about Python design goals

Paul Rubin <http://[EMAIL PROTECTED]> 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

Re: General question about Python design goals

Paul Rubin <http://[EMAIL PROTECTED]> 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

Re: Making immutable instances

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Letting the class author declare whether or not the client can add >> attributes is wrong for the same reasons - and in the same places - >> that letting the class author dec

Re: Making immutable instances

[EMAIL PROTECTED] writes: > I am puzzled, and could have read what you want wrong. Are you saying > you want something like this : > > a={} > a.something = "I want to hang my stuff here, outside the intended use > of dict" Exactly. For a use case, consider calling select.select on lists of file ob

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-11-29, Mike Meyer <[EMAIL PROTECTED]> wrote: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>>> You see, you can make languages more powerful by *removing* things >>>> from it. >>>

Re: python speed

"Harald Armin Massa" <[EMAIL PROTECTED]> writes: >>Faster than assembly? LOL... :) > why not? Of course, a simple script like "copy 200 bytes from left to > right" can be handoptimized in assembler and run at optimum speed. > Maybe there is even a special processor command to do that. Chances are

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> [EMAIL PROTECTED] writes: >> > I am puzzled, and could have read what you want wrong. Are you saying >> > you want something like this : >> > a={} >> > a.something = "I want to hang my stuff here,

Re: HTML parsing/scraping & python

Sanjay Arora <[EMAIL PROTECTED]> writes: > We are looking to select the language & toolset more suitable for a > project that requires getting data from several web-sites in real- > timehtml parsing/scraping. It would require full emulation of the > browser, including handling cookies, automat

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Well, in this case, would it be simple for the OP that if he wants to > disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior. Using it to get that effect is abuse of the feature, and may well quit work

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> [EMAIL PROTECTED] writes: >> > Well, in this case, would it be simple for the OP that if he wants to >> > disallow this attaching additional things, just use __slot__. >> That's *documented* as an implementat

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Quoting the frequently used term "Practicality beats purity". If I have > a practical problem/needs now and it solves it, why not use it ? In other words, you have a use case. Cool. Please tell us what it is - at least if it's better than "I think that's bad style."

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: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > I know what happens, I would like to know, why they made this choice. > One could argue that the expression for the default argument belongs > to the code for the function and thus should be executed at call time. > Not at definion time. Just as other exp

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> [EMAIL PROTECTED] writes: >> > Quoting the frequently used term "Practicality beats purity". If I have >> > a practical problem/needs now and it solves it, why not use it ? >> In other words, you have

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

Re: python speed

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> If you wire everything down, you can always hand-code assembler that >> will be faster than HLL code > but that doesn't mean that your hand-coded assembler will always be faster > than an

Re: HTML parsing/scraping & python

"Fuzzyman" <[EMAIL PROTECTED]> writes: > The standard library module for fetching HTML is urllib2. Does urllib2 replace everything in urllib? I thought there was some urllib functionality that urllib2 didn't do. > There is a project called mechanize, built by John Lee on top of > urllib2 and othe

Re: Python as Guido Intended

Antoon Pardon <[EMAIL PROTECTED]> writes: >> We don't talk much about how you produce buffer >> overfows in Python, but people have asked for that as well. Adding >> ways to write hard-to-read code is frowned upon. And so on. > Do you mean people have asked for the possibility that

Re: Automate webpage refresh

DarkBlue <[EMAIL PROTECTED]> writes: > I am trying to write a script (python2.3) which will be used > with linux konqueror to retrive 2 webpages alternatively every 2 minutes. > > My question is how can I send alternative args (the url) > to the same invocation of konqueror which I started with >

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 anythi

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>> I know what happens, I would like to know, why they made this choice. >>> One could argue that the expre

Re: Making immutable instances

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Lots of people seem to want immutable instances. Nobody seems to have >> a use case for them. > What is the use case for immutable strings? Why shouldn't strings be &g

Re: Making immutable instances

Ben Finney <[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> wrote: >> Lots of people seem to want immutable instances. Nobody seems to >> have a use case for them. > Perhaps you missed my release announcement of the 'enum' package that > expl

Re: Instances behaviour

"Mr.Rech" <[EMAIL PROTECTED]> writes: > Suppose I have a bunch of classes that represent slightly (but > conceptually) different object. The instances of each class must behave > in very similar manner, so that I've created a common class ancestor > (let say A) that define a lot of special method (

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> That's not a use case, that's a debugging aid. The same logic applies >> to adding type declarations, private/public/etc. declerations, and >> similar B&D language features. It's generally considered that it&

Re: Making immutable instances

Ben Finney <[EMAIL PROTECTED]> writes: > > "Since the values of an enumeration are directly reflected in the > values and attributes, Enum instances are immutable to preserve > this relationship" This justifies making the attributes immutable. But that's old hat - I had that use case l

Re: Making immutable instances

[EMAIL PROTECTED] writes: > Mike Meyer wrote: >> > By design, this is a "don't use" feature so it would be very hard to >> > find a "use case" ;-) >> But I can think of use cases for instances with no mutable attributes, >> which is a

Re: Making immutable instances

Ben Finney <[EMAIL PROTECTED]> writes: > Mike Meyer <[EMAIL PROTECTED]> wrote: >> Ben Finney <[EMAIL PROTECTED]> writes: >> > "Since the values of an enumeration are directly reflected in >> > the values and attributes, Enum instances ar

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: >>> Well there are two possibilities I can think of: >>> >>> 1) >>> arg_default = ... >>> def f(arg = arg_default): >>> ... >> >> Yuch. Mostly because it doesn't work: >> >> arg_default = ... >> def f(arg = arg_default): >> ... >> >> arg_default =

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: >> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: Antoon Pardon wrote: >>>I think one could argue that since '[]'

Re: Why use #!/usr/bin/env python rather than #!python?

Carsten Haese <[EMAIL PROTECTED]> writes: > (3) assumes that whatever shell the user is running looks up the shebang > executable in the path, which bash, just to name one example, does not > do. For the record, on a modern Unix system, #! isn't handled by the shell; it's handled by the kernel. #!

Re: Setting PYTHONPATH from Makefile

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > I have a Makefile target that uses a python script, like: > > %.abc: %.def > python myscript.py > > The problem is that myscript.py and some modules that myscript.py > imports are not in the current directory, but in another place in the > f

Re: Setting PYTHONPATH from Makefile

Inyeol Lee <[EMAIL PROTECTED]> writes: > On Fri, Dec 02, 2005 at 07:33:20PM -0500, Mike Meyer wrote: >> > The problem is that myscript.py and some modules that myscript.py >> > imports are not in the current directory, but in another place in the >> > filesystem

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)).coun

<    1   2   3   4   5   6   7   8   9   10   >