RE: What is proper way to require a method to be overridden?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Fuzzyman > Sent: Friday, January 05, 2007 4:05 PM > To: python-list@python.org > Subject: Re: What is proper way to require a method to be overridden? > > > Carl Banks wrote: > > jeremito wrote: > > > I am writing a class that is intended to be subclassed. What is the > > > proper way to indicate that a sub class must override a method? > > > > You can't (easily). > > > > Well... > > How about not defining it on the base class, but check in the > constructor that the attribute exists and that it is of type > FunctionType ? > > Fuzzyman > http://www.voidspace.org.uk/python/articles.shtml > > -- > http://mail.python.org/mailman/listinfo/python-list Greetings: Thomas Christopher's book "Python Programming Patterns" has an example of this that I like. On page 72 he shows code for a class, AbstractSet, which he later subclasses in ListSet and DictSet. Each of the methods intended for subclassing simply to raise a NotImplementedError, e.g.: def insert(self,x): raise NotImplementedError, "set.insert" In this way the superclass's interface is well defined (the methods and their parameters are all listed, but if invoked before they are overwritten, they abort with a useful error message. Pretty slick, IMHO. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
File Closing Problem in 2.3 and 2.4, Not in 2.5
Greetings: Please forgive me if this is the wrong place for this post. I couldn't find a more acceptable forum. If there is one, please point me in the right direction. I am part of a small team writing a table-driven automated testing framework for embedded software. The tables, which contain rows of keywords and data that drive the testing, are stored as plain-text "Comma-Separated Value" or .csv files. Each table can call other tables, which means that multiple files may be open at a time. The framework includes a Parser class. The program takes the name of the top-level table as a parameter, creates an instance of the Parser and passes the table name to it. The Parser instance opens the .csv file with that name, reads each line of the file (row of the table) and takes the appropriate action. When it encounters a row referencing another table, it creates a new Parser instance and passes it the name of the new table, suspending its own operation until the new Parser instance completes. In this way, a tree of Parser instances is created, each with a single open file object. (BTW, recursive and circular references are not allowed.) When each Parser instance comes to the end of its table, the instance is explicitly destroyed, presumably destroying any objects it holds, AND closing its open file. Because of the nature of the framework and the testing we do, this Parser tree never gets very tall: four or five levels at the most. The same table may be invoked dozens or hundreds of times, however, with different sets of data each time. This is where things go wrong. After about 500 table invocations, the framework starts refusing to process any more tables, responding with the following error: [Errno 24] Too many open files: 'HostCommandDevNotReady.csv' We can correct the behavior by explicitly closing each Parser's table file object before exiting the Parser code. This indicates that Python is failing to free up some file-related internal resource when the Parser object is destroyed. This behavior occurs on Python 2.3 and 2.4 for Windows, but not on Python 2.3 for Linux, and not on the Windows version of Python2.5. This is why I didn't just post a report to Bug Tracker: the problem seems to have been fixed. I did search through the archive of Windows related bugs, but found no mention of this type of a bug. What I want to know is: * has anyone else encountered a problem like this, * how was the problem corrected, * can the fix be retro-fitted to 2.5 and 2.4? Thanks in advance for any information you can provide. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: File Closing Problem in 2.3 and 2.4, Not in 2.5
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of John Machin > Sent: Saturday, January 06, 2007 11:09 PM > To: python-list@python.org > Subject: Re: File Closing Problem in 2.3 and 2.4, Not in 2.5 > > Martin v. Löwis wrote: > > Carroll, Barry schrieb: > > > What I want to know is: > > > > > > * has anyone else encountered a problem like this, * how was the > > > problem corrected, * can the fix be retro-fitted to 2.5 and 2.4? > > > > From your description, I suspect an error in your code. Your description > > indicates that you don't expect to have more than five files open > > simultaneously. Yet, the error message "Too many open files" occurs when > > you open many more files (in the order of hundreds of files). > > > > It is very unlikely that there is a bug in Python where it would fail to > > close a file when .close() is explicitly invoked on it (as your > > description suggests that you do), so if you get that error message, it > > can only mean that you fail to close some files. > > I don't understand: the OP's description suggests nothing of the sort > to me. What he said was: > """ > In this way, a tree of Parser instances is created, each with a single > open file object. (BTW, recursive and circular references are not > allowed.) When each Parser instance comes to the end of its table, the > instance is explicitly destroyed, presumably destroying any objects it > holds, AND closing its open file. > """ > which I interpret as: he is doing del parser_instance, and *presuming* > (incorrectly) that attributes of parser_instance (including an open > file object) are magically whisked away instantly, instead of > later/maybe. He later says he explicitly closed the files, which fixed > what he alleges (incorrectly) to be a bug. > > To the OP: > (1) The del statement doesn't "destroy" anything. It unbinds the name > from the object in the current namespace, and decrements the object's > reference count. Only if the reference count is then zero will the > janitor be called in. > (2) Check the reference count on the parser_instance just before you > del it. You could be retaining a reference somewhere. > (3) Explicitly close all non-lightweight objects like files (even > read-only ones) and sockets rather than hoping they will go away. > > HTH, > John John: Thank you. I was afraid I had been totally misunderstood. We have retained the explicit file close in the current version of the Parser code. I still have a question, however. Python 2.3 and 2.4 both produce the "Too many open files" error on Windows XP Pro, but Python 2.5 does not. Running on the 2.5 interpreter, our program process all the table invocations with no errors, a total of over 650 file opens. Also, Python 2.3 on RedHat Fedora core 1 runs our program to completion with no errors. (I know, we are running pretty ancient SW here. Constraints unrelated to this question make that necessary.) Do you know why the error would appear on some combinations of OS and interpreter and not on others? Thanks again for your help. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: File Closing Problem in 2.3 and 2.4, Not in 2.5
John: <<> > > Hi Barry, > > Please always reply on-list if the communication is non-private -- and > meaningful :-) Right. I noticed I hadn't "replied-to-all", so I resent the post to the mailing list. Slip of the mouse, no disrespect intended to the list ;^) > > I don't know; here are some things you could check out: > > (1) Windows XP versus *x: The limit on open file handles is 512 in > Windows XP; write yourself a reference-preserving [hint: append to a > list] multiple file opener on *x and see how many you get open. I have > vague recollections of the number 1024 being mentioned. By rough calculation, we had been through over 500 table invocations when the error message started showing up. That fits well enough with the number of Windows file handles. I'll check the Linux value. > > (2) Python 2.4 versus 2.5: Read the "what's new" doc, fire up your > googler, ... I read through the 2.5 release notes and didn't see anything that looked related. I may have been looking for the wrong thing. I'll check again. > IMHO, the attitude should be to program defensively so that you need > neither to know nor care about such implementation-specific concerns. > Operating systems these days give you enough file handles to do any > reasonable job. It's many moons since MS-DOS 2.n with its max 20 open > file handles made folks implement LRU caches for file handles. > > Simple rules about unwanted objects include: > (1) If an object has a free() or close() method, then call it! > (2) Unbind *all* references to the object. I tend to agree with you. I am not the lead programmer on this project, however, so my preferences do not always get implemented. This time, though, as I said, the explicit file close has been retained. > Have you checked out my point 2 (holding multiple references to your > Parser objects)? Not yet, but I will. > > Cheers, > John Again, thanks. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: File Closing Problem in 2.3 and 2.4, Not in 2.5 (Final report)
John et al: I've spent about a day investigating our "too many open files" error. I found the following: 1. Windows XP allows a Python 2.5 script to open 509 concurrent files. 2. RedHat Fedora Core 1 allows a Python 2.3 script to open 1022 concurrent files. 3. The Python 2.5 release notes and the "What's New in Python 2.5" doc do not mention any changes to the way in which file objects of reference counts are handled. 4. Other features of the framework also fail when this limit is reached. Specifically, our debugger subsystem suffers a fatal error if invoked near the point where the file errors start to occur. So more than just file objects are affected here. I've spent all the time I can spare chasing this bug. The lead programmer is convinced (I think) that we have a reference count problem somewhere, so perhaps he will persue it. If any more useful information comes up on this subject, I'll post it here. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: Free support for Python developers
Viktor: This is a great idea. Thank you I don't currently have a voice setup on my machine, but will try to get one as soon as possible. I would be pleased to trade English practice for Python support. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed > -Original Message- > From: Ferenczi Viktor [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 29, 2007 5:29 PM > To: [EMAIL PROTECTED] > Subject: Free support for Python developers > > I am pleased to announce the availability of python support for English > speaking developers. The service is free of charge. More information: > > http://python.cx.hu/support/ -- http://mail.python.org/mailman/listinfo/python-list
RE: File Closing Problem in 2.3 and 2.4, Not in 2.5 (Final report)
Hi, Gabriel, > -Original Message- > From: Gabriel Genellina [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 09, 2007 4:06 PM > To: python-list@python.org > Subject: RE: File Closing Problem in 2.3 and 2.4, Not in 2.5 (Final > report) > > At Tuesday 9/1/2007 20:31, Carroll, Barry wrote: > > >I've spent about a day investigating our "too many open files" error. I > >found the following: > > > > 1. Windows XP allows a Python 2.5 script to open 509 concurrent > >files. > > And do you actually need so many open files simultaneously? No. In fact, that was the original point of my post. We expected that the maximum number of file objects (open and otherwise) would never be more than five or six. We believed (apparently incorrectly) that destroying the table parser object would destroy its associated file object and close the referenced file. Here is the code that does this: ## def unloadtable(self, log=True): """Unload current table and pop prior processor from call stack. """ # SNIP # force clean up for unloaded table self.processor = None gc.collect() # pop prior processor from stack self.processor = self.pstack.pop() # SNIP ## The first assumption was correct: the file object is destroyed. The second assumption is apparently incorrect: the file handle is not released when the associated object is destroyed. These 'orphaned' file handles build up and when the OS handle limit is reached, "too many open files" errors show up. > Try to close them explicitly when you finish working on them - do > not rely on GC for closing files. This has *always* been the > recomended practice (except maybe, inside a short script that > finishes quickly). This is what we have done. The unloadtable function now looks like this: ## def unloadtable(self, log=True): """Unload current table and pop prior processor from call stack. """ # SNIP # force clean up for unloaded table self.processor.source.close() self.processor = None gc.collect() # pop prior processor from stack self.processor = self.pstack.pop() # SNIP ## > On Python 2.5 you can use the new `with` statement. > Not only that, the file errors don't appear when we run our program/table combination under 2.5. I can't explain the difference, unless the work done to implement the 'with' statement has an impact outside the scope of that feature. In any event, it does us no good. Other constraints on the test system require us to stick with Python 2.3, at least for the present. > > -- > Gabriel Genellina > Softlab SRL > > __ > Preguntá. Respondé. Descubrí. > Todo lo que querías saber, y lo que ni imaginabas, > está en Yahoo! Respuestas (Beta). > ¡Probalo ya! > http://www.yahoo.com.ar/respuestas > Thanks for your interest. Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
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: > > > > > > 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 to test it but oh well. > > OMG! - I have been feeding that unexpected heap of minced meat > to the cat... > > - Hendrik > Gentlemen: Y'all really need to be more careful. Much research has been done on matter teleportation, and there is ample documentation of the dangers involved. The logs of the USS Enterprise alone are rife with the horrible consequences of "transporters gone wild".(1) In addition, the historical records of the NSEA Protector contain a particularly gruesome account of a "digital conveyor" malfunction which caused the subject to turn inside out and then explode.(2) These experiments MUST be conducted under the most rigorous controls to prevent similar catastrophes. (Unless, you're using Perl programmers as test subjects, in which case it's okay. ;^) Humorously yours, Barry --- (1) "Star Trek: the Motion Picture": Roddenberry, Foster and Wise, 1979 (2) "Galaxy Quest": Howard, Gordon and Parisot, 1999 -- http://mail.python.org/mailman/listinfo/python-list
RE: *POLL* How many sheeple believe in the 911 fairy tale and willingto accept an Orwellian doublespeak and enslavement world ?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 10:23 AM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > > > ... buildings collapse all the time when you design to the cold-formed > > strength rather than the hot-formed strength of a material, then heat > > the material removing its tempered strength (which for steel occurs at > > much lower than usual flame temeratures). > > Actually, modern steel frame buildings have never collapsed from > kerosine fire. > Besides there are SERIOUS anomalies indicative of thermate and > explosives. > Yellow hot molten metal were seen trickling down less than hour after > the fires. > Red hot molten metal pools were seen in the rubble weeks after the > collapse. > The building and their contents pulverized to dust from the brisance of > very well > planted and hidden explosives. I was not aware that Alqaeda has > invisible man > technology past the security cameras. > > > And what did this rant have to do with any of the sci.* or programming > > newsgroups you posted it to? > > Your ignoramus is the exact reason why this has to be posted there. > > > David A. Smith > > And why did bldg 7 commit suicide. How was the boeing767 maneouvered > so close to the ground into pentagon? > > Where is the DNA to confirm the identities of 19 in the fairy tale? > > Do you work for the story writing agency ? > Ladies and Gentlemen: PLEASE take this discussion to a more appropriate forum. There are many forums where people will be happy to debate this: physics, firefighting, metallurgy, geopolitics, etc. This forum is about the Python programming language. Let's keep it that way. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: *POLL* How many sheeple believe in the 911 fairy tale and willingto accept an Orwellian doublespeak and enslavement world ?
> -Original Message- > From: Robert Hicks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 10:33 AM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > Please, none of the real facts points to anything else except what > actually happened. Two planes hit two towers and they came down. > Ladies and Gentlemen: PLEASE take this discussion to a more appropriate forum. There are many forums where people will be happy to debate this: physics, firefighting, metallurgy, geopolitics, etc. This forum is about the Python programming language. Let's keep it that way. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: *POLL* How many sheeple believe in the 911 fairy tale and willingto accept an Orwellian doublespeak and enslavement world ?
> -Original Message- > From: David Bostwick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 10:43 AM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > In article <[EMAIL PROTECTED]>, "Robert > Hicks" <[EMAIL PROTECTED]> wrote: > >Please, none of the real facts points to anything else except what > >actually happened. Two planes hit two towers and they came down. > > > > You're talking to the wind. This is a conspiracy precisely because people > deny the crackpots. Denial of their "evidence" proves that there is a > coverup. Logic is not involved, only belief that doesn't respond to > dissenting evidence. Ladies and Gentlemen: PLEASE take this discussion to a more appropriate forum. There are many forums where people will be happy to debate this: physics, firefighting, metallurgy, geopolitics, etc. This forum is about the Python programming language. Let's keep it that way. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: *POLL* How many sheeple believe in the 911 fairy tale and willingto accept an Orwellian doublespeak and enslavement world ?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 11:05 AM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > > Robert Hicks wrote: > > Please, none of the real facts points to anything else except what > > actually happened. Two planes hit two towers and they came down. > > The issue is the causality of the towers coming down. > > A magician pulls appears to cast a spell > and out comes a rabbit out of his hat. There will always be fools who > will accept this causality and others who know better the laws of > conservation. > Ladies and Gentlemen: PLEASE take this discussion to a more appropriate forum. There are many forums where people will be happy to debate this: physics, firefighting, metallurgy, geopolitics, etc. This forum is about the Python programming language. Let's keep it that way. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: *POLL* How many sheeple believe in the 911 fairy tale and willingto accept an Orwellian doublespeak and enslavement world ?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 11:12 AM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > > David Bostwick wrote: > > In article <[EMAIL PROTECTED]>, > "Robert Hicks" <[EMAIL PROTECTED]> wrote: > > >Please, none of the real facts points to anything else except what > > >actually happened. Two planes hit two towers and they came down. > > > > > > > You're talking to the wind. This is a conspiracy precisely because > people > > deny the crackpots. Denial of their "evidence" proves that there is a > > coverup. > > Quite the contrary. A million dollar reward was posted to come with a > consistent > explanation of the SERIOUS anomalies involved on that day. Professor > Steven > Jones research on Thermate is an EYE OPENER. He is a BRILLIANT > physicists. > > > Logic is not involved, only belief that doesn't respond to dissenting > evidence. > > Indeed, the 19 hijacker theory is a fairy tale based on illogical > forensic investigation. > As for dissent, Bush is on video record to utter, "Lets not tolerate > any conspiracy theories." > The video is floating on the internet for you to see if you had the IQ > to search for it. > Ladies and Gentlemen: PLEASE take this discussion to a more appropriate forum. There are many forums where people will be happy to debate this: physics, firefighting, metallurgy, geopolitics, etc. This forum is about the Python programming language. Let's keep it that way. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
OT: Apology
Greetings: I've been trying to get the contributors to this thread to move their discussion to a more appropriate forum, but the unintended result has been more spam on this forum. My apologies to the regular readers of this newsgroup. This will be my last public post on this subject. I just hope the other posters will follow suit. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 12:24 PM > To: python-list@python.org > Subject: Re: *POLL* How many sheeple believe in the 911 fairy tale and > willingto accept an Orwellian doublespeak and enslavement world ? > > > David Bostwick wrote: > > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] wrote: > > > > > >David Bostwick wrote: > > > > [...] > > > > >Indeed, the 19 hijacker theory is a fairy tale based on illogical > > >forensic investigation. > > >As for dissent, Bush is on video record to utter, "Lets not tolerate > > >any conspiracy theories." > > >The video is floating on the internet for you to see if you had the IQ > > >to search for it. > > > > > > > No, I think I'm smart enough to find it. I just don't care to waste > time on > > crackpot theories. Good ad hominem, though - "You disagree with me, so > you > > must be an idiot." Judging from where you posted this, you're the > clueless > > one. > > You dont have to waste any time. google seach is very fast. I already > posted links for you. These are even videos so if you are challenged > to read english prose, that wont be a handicap. > -- http://mail.python.org/mailman/listinfo/python-list
OT Annoying Habits (Was: when format strings attack)
Greetings:
Personally, I don't think top-posting is the most annoying newsgroup
habit. I think it's making a big fuss about minor inconveniences.
One of the nicest things about being human is the amazing flexibility of
our brains. For example, if a block of text isn't arranged in the order
we're used to, we can easily rearrange it mentally and read it anyway.
Oriental and Arabic peoples, for example, do this each time they read
something written in English. It's EASY, once you get used to it!
It took me about 3 seconds to realize that Mr. D'Aprano' Q&A session was
laid out bottom-to-top instead of top-to-bottom. After that, it made
perfect sense. While it was a excellent way to demonstrate his
argument, it failed to prove his point, because, while top-to-bottom may
be the way he reads things, it isn't the way _everyone_ reads things.
So, as far as I'm concerned, post your posts in whatever manner works
for you. If it's in English, I'll figure it out. If not, well, there's
always Babelfish. ;^)
Regards,
Barry
[EMAIL PROTECTED]
541-302-1107
We who cut mere stones must always be envisioning cathedrals.
-Quarry worker's creed
> -Original Message-
> From: Steven D'Aprano [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 19, 2007 11:30 AM
> To: python-list@python.org
> Subject: Re: when format strings attack
>
> On Fri, 19 Jan 2007 10:43:53 -0800, John Zenger wrote:
>
> > Perhaps it is not as severe a security risk, but pure Python
programs
> > can run into similar problems if they don't check user input for %
> > codes.
>
> Please don't top-post.
>
> A: Because it messes up the order that we read things.
> Q: Why?
> A: Top-posting.
> Q: What is the most annoying newsgroup habit?
>
>
> > Example:
> >
> k = raw_input("Try to trick me: ")
> > Try to trick me: How about %s this?
> j = "User %s just entered: " + k
> print j % "John"
> > Traceback (most recent call last):
> > File "", line 1, in ?
> > print j % "John"
> > TypeError: not enough arguments for format string
>
> That's hardly the same sort of vulnerability the article was talking
> about, but it is a potential bug waiting to bite.
>
> In a serious application, you should keep user-inputted strings
separate
> from application strings, and never use user strings unless they've
been
> made safe. See Joel Spolsky's excellent article about one way of doing
> that:
>
> http://www.joelonsoftware.com/articles/Wrong.html
>
>
>
> --
> Steven.
>
--
http://mail.python.org/mailman/listinfo/python-list
RE: OT Annoying Habits (Was: when format strings attack)
Hello again. First off, Aahz is absolutely right. It is my choice, just as it is his choice what to read and what to ignore. My reply was about the fuss, not the choice. Secondly, can someone point me to the Standard Usenet Convention that mandates against top-posting. This is not sarcasm; I would really like to see it. You see, I recently returned to Usenet after a LONG absence. When I was last a regular Usenet citizen the Internet was new, GUI interfaces were experimental and the World Wide Web didn't exist yet. Newsreader software was text-based. Top-posting was the common practice, because it was the most convenient: you didn't have to page through an arbitrarily large number of messages, most of which you'd already read umpteen times, to get to the new stuff you were interested in. So I'd really like to know what the standard is now. I like to know which rules I'm choosing to break. ;^) Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed > -Original Message- > From: Aahz [mailto:[EMAIL PROTECTED] > Sent: Friday, January 19, 2007 1:12 PM > To: python-list@python.org > Subject: Re: OT Annoying Habits (Was: when format strings attack) > > In article <[EMAIL PROTECTED]>, > Carroll, Barry <[EMAIL PROTECTED]> wrote: > > > >Personally, I don't think top-posting is the most annoying newsgroup > >habit. I think it's making a big fuss about minor inconveniences. =20 > > Thing is, nobody will ignore your posts for following standard Usenet > conventions, but some of us will definitely ignore your posts if you > don't. It's your choice how much attention you want. > -- > Aahz ([EMAIL PROTECTED]) <*> > http://www.pythoncraft.com/ > > Help a hearing-impaired person: http://rule6.info/hearing.html -- http://mail.python.org/mailman/listinfo/python-list
RE: OT Annoying Habits (Was: when format strings attack)
> -Original Message- > From: Aahz [mailto:[EMAIL PROTECTED] > Sent: Friday, January 19, 2007 3:29 PM > To: python-list@python.org > Subject: Re: OT Annoying Habits (Was: when format strings attack) > > In article <[EMAIL PROTECTED]>, > Carroll, Barry <[EMAIL PROTECTED]> wrote: > > > >Secondly, can someone point me to the Standard Usenet Convention that > >mandates against top-posting. This is not sarcasm; I would really like > >to see it. <> > > Funny, I've been on Usenet for more than fifteen years, continuously > (and long-windedly -- but that's another matter) and I've never seen a > Usenet group where top-posting was standard. Anyway, here's a good > resource: > > http://www.xs4all.nl/%7ewijnands/nnq/nquote.html > -- > Aahz ([EMAIL PROTECTED]) <*> > http://www.pythoncraft.com/ > > Help a hearing-impaired person: http://rule6.info/hearing.html My thanks to Aahz and the others who responded. I also did some Googling on my own. I found out that top-posting is the norm in the e-mail world. Bottom- and inline-posting are the norm in the newsgroup world. So I concede the point, and I'm bottom-posting like a good citizen. Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: Overloading assignment operator
> -Original Message- > From: Achim Domma [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 23, 2007 10:25 AM > To: python-list@python.org > Subject: Overloading assignment operator > > Hi, > > I want to use Python to script some formulas in my application. The user > should be able to write something like > > A = B * C > > where A,B,C are instances of some wrapper classes. Overloading * is no > problem but I cannot overload the assignment of A. I understand that > this is due to the nature of Python, but is there a trick to work around > this? > All I'm interested in is a clean syntax to script my app. Any ideas are > very welcome. > > regards, > Achim Hello, Achim, I asked this question (in a different context) some months ago on the Python tutor mailing list (tutor@python.org). The answer I got is summarized below. ** There is no assignment operator in Python, assignment is a ** binding of an object to a name. (Alan Gauld) * ... the assignment operator is used to assign an * object to a name in the current namespace... IOW, you cannot "overload * the assignment operator." (wesley chun) Mr. Chun went on to describe a way to accomplish something similar, using properties. I reprint it here, slightly rewritten to match your use case. * ...here is where * properties become useful. you can create a getter, setter, and even a * deleter and doc string if you want. here's how you use it... add the * following to your class: * def get_result(self): * return self.__result * * def set_result (self, expression): * self.__result = expression * * result = property(get_result, set_ result, doc='result of operations') * * - * * in actuality, the value is stored in self.__result, but access is via * self.result. this should give you what you need provided you are happy * with using "A.result = B * C" vs. "A = B * C", the latter of which * will never work the way you want. ... I have tested this using the admittedly simple-minded code snipped below. >> @BCARROLL[Python]|3> class Aclass: |.> def __init__(self): |.> __result = None |.> def get_result(self): |.> return self.__result |.> def set_result (self, result): |.> self.__result = result |.> result = property(get_result, set_result, doc='result of expression') |.> @BCARROLL[Python]|5> A = Aclass() @BCARROLL[Python]|7> a.result = 2*3 @BCARROLL[Python]|8> a.result <8> 6 @BCARROLL[Python]|9> a.result = 25.0 * 5.25 @BCARROLL[Python]|10> a.result <10> 131.25 @BCARROLL[Python]|11> >> HTH Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: Overloading assignment operator
> -Original Message- > From: Gabriel Genellina [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 23, 2007 9:24 PM > To: python-list@python.org > Subject: Re: Overloading assignment operator > > "Carroll, Barry" <[EMAIL PROTECTED]> escribió en el mensaje > news:[EMAIL PROTECTED] > > > * ... the assignment operator is used to assign an > > * object to a name in the current namespace... IOW, you cannot "overload > > * the assignment operator." > > (wesley chun) > This is the key concept, if you want to be able to "see" assignments, you > should work with a namespace (a dictionary is enough...) > > > * result = property(get_result, set_ result, doc='result of operations') > > > > I have tested this using the admittedly simple-minded code snipped > > below. <> > Notice that you can delete ALL those lines of code, leaving a bare: > > class Aclass: passs > > and you will get EXACTLY the same results. In this case -and this are not > my > words- properties are a waste of programmer time, processor time and disk > space. > Of course properties are very useful, but when you need to do something > "more" than just storing and retrieving a single value. > > -- > Gabriel Genellina Greetings: Gabriel is right, and my definitions of get_result and set_result were deficient. Something like this would have been better: * def get_result(self): *do_stuff_before_returning(self) *return self.__result * * def set_result (self, expression): *do_stuff_before_storing(self, expression) *self.__result = expression * Achim didn't go into the details of his result class(es), so I don't know what the do_stuff_* functions would actually do. Sorry for the omission. Regards, Barry -- http://mail.python.org/mailman/listinfo/python-list
RE: What is the dummy statement that do nothing in Python?
> -Original Message- > From: Dongsheng Ruan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 8:50 AM > To: python-list@python.org > Subject: What is the dummy statement that do nothing in Python? > > I remember that in python there is some kind of dummy statement that just > holds space and does nothing. > > I want it to hold the place after a something like if a>b: do nothing > > I can't just leave the space blank after if statement because there will > be > error message. > > Does anybody know what to insert there? > > Thanks! > > Greetings: Try 'pass': if a>b: pass else: dosomething() Regards, Barry [EMAIL PROTECTED] 541-302-1107 We who cut mere stones must always be envisioning cathedrals. -Quarry worker's creed -- http://mail.python.org/mailman/listinfo/python-list
RE: Sorting a list
> -Original Message-
> From: John Salerno [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 01, 2007 11:54 AM
> To: python-list@python.org
> Subject: Re: Sorting a list
>
> Bruno Desthuilliers wrote:
> > John Salerno a écrit :
> >> Hi everyone. If I have a list of tuples, and each tuple is in the form:
> >>
> >> (year, text) as in ('1995', 'This is a citation.')
> >>
> >> How can I sort the list so that they are in chronological order based
> >> on the year?
> >
> > Calling sort() on the list should just work.
>
> Amazing, it was that easy. :)
Hello, John.
Yeah. That's one of the things that drew me to Python: so many things you want
to do are just so *easy* in Python.
Regards,
Barry
[EMAIL PROTECTED]
541-302-1107
We who cut mere stones must always be envisioning cathedrals.
-Quarry worker's creed
--
http://mail.python.org/mailman/listinfo/python-list
