Re: A Beginner's Doubt
On Thu, Jun 20, 2013 at 1:31 AM, Rick Johnson wrote: > On Wednesday, June 19, 2013 8:58:19 AM UTC-5, augus...@gmail.com wrote: >> This is my first post in this group and the reason why I >> came across here is that, despite my complete lack of >> knowledge in the programming area, I received an order >> from my teacher to develop a visually interactive program, > > Ah teachers, you gotta love them! High on a power trip. > Drunk on tenure. Most of which are overpaid and > under-worked. Can't work with them, can't fire them! Just FYI, Augustof, Rick is one of our resident trolls. Don't take his words to heart :) He knows his stuff when it comes to Tkinter though, so you'll want to read his posts but ignore the emotion. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Error running xmlrpc Client and server under different Python versions
Hello. I need to run xmlrpc Server under Python 3.3 and Client under Python 2.7. But when I try to do so, I receive the following exception: ":global name 'xmlrpclib' is not defined" What is the reason for such an exception. As far as I understand xmlrpc is language independent. Please help. Regards, Slava -- http://mail.python.org/mailman/listinfo/python-list
Re: Error running xmlrpc Client and server under different Python versions
On 20/06/2013 08:36, stanislav.boriso...@gmail.com wrote: Hello. I need to run xmlrpc Server under Python 3.3 and Client under Python 2.7. But when I try to do so, I receive the following exception: ":global name 'xmlrpclib' is not defined" What is the reason for such an exception. As far as I understand xmlrpc is language independent. Please help. Regards, Slava See http://www.python.org/dev/peps/pep-3108/#xmlrpc-package -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Error running xmlrpc Client and server under different Python versions
On 20 Jun 2013 08:46, wrote: > > Hello. > > I need to run xmlrpc Server under Python 3.3 and Client under Python 2.7. But when I try to do so, I receive the following exception: > > ":global name 'xmlrpclib' is not defined" Somewhere in your code you are trying to use the name 'xmlrpclib' but it was not imported or otherwise assigned to. Search through your code to find the usage. > What is the reason for such an exception. As far as I understand xmlrpc is language independent. Please help. The fact that it is language independent is irrelevant since this is a code error. Cheers -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't feed the troll...
Op 19-06-13 20:40, Ian Kelly schreef: > On Wed, Jun 19, 2013 at 4:57 AM, Antoon Pardon > wrote: >> I don't remember making such a claim. What I do remember is >> you among others claiming that the problem was not (so much) >> the troll (Nikos) but the others. > Count me among those who feel this way. Well You are entitled to your judgement, but so are those who feel differently. For now I don't see a reason to favor your judgement over others. >> And your last conclusion is unsound. You forget to include the >> fact that once a troll appeared, people reacting badly to the >> troll is also to be expected. So with regards to this aspect >> there is no difference between the troll and the responders, >> both being expected and so no ground to put the preponderance >> of blame on the responders. > No, I don't agree with that at all. Trolls are to be expected because > there will always be those out in the world who want to have a little > fun and have no regard for either the list or those who use it. There > is nothing to be done about that. On the other hand, the flamers > responding to the trolls are regular contributers to the list who > presumably do care about keeping the list courteous, respectful, > welcoming and enjoyable to participate in. Toward that end, I do not > think it is at all unreasonable to expect posters not to throw those > principles out the window just because a troll showed up. There are two problems with your reasoning. The first is that you are equivocating on "expect". "Expect" can mean you will be surprised if it doesn't happen but it can also mean you will feel indignant or disappointed or something similar when it doesn't happen. Now I won't feel surprise when a troll turns up and I also won't feel surprise when the troll attracts flamers and it is my guess this is the meaning you use when you write trolls are to be expected. I doubt you want to express indignation or disappointment with the prospect of no trolls showing up. But then you seem to switch meaning when you talk about the flamers. There it sure looks like you are expressing indignation at the prospect of community members not upholding the principles you find important. The second problem is that I find it a one sided view. If you want a courteous, respectful, welcoming and enjoyable to participate in list, shouldn't you also be careful in not encouraging trollish behaviour? Being courteous to or cooperating with someone behaving trollishly, is IMO enabling that kind of behaviour and so those doing so, seem to already throw those priciples out the window because they are cooperating with the troll who is making this list less courteous, respectful, welcoming and enjoyable to participate in for a significant number of people. There is also the aspect that you can only try to keep something if you have the feeling it is still present. If contributers start feeling this list is no longer the hospitable place it once was, they feel less inclined to do the effort themselves. If you'd like people not to throw out certain principles you'd better make sure they don't feel those principles have already been thrown out. >> Well others don't appreciate you drawing the lines for them >> either. If you think others have no business drawing the line >> for what is acceptable on this mailinglist/newsgroup then you >> have no business drawing such a line yourself. > Ultimately there is no enforcement on this list, and all of us must > draw our own lines. The question then is: will one draw the line > somewhere that is respectful of the list and promotes positive > contributions, or somewhere that will push others toward kill-filing > one and/or giving up on the list altogether? Indeed, and how is it promoting positive contributions if you answer trollish contributions about the same way as you do interesting contributions? > So their ideal solution is to flame him until he goes away, with the > result being that the threads don't exist to begin with? If it's > difficult to filter "valuable contributions" from a thread while > trying to ignore every other post, think how much harder it will be to > got those same "valuable contributions" from a thread that doesn't > exist in the first place. Those valuable contributions will then probably turn up in an other thread. One that isn't a resource hog for all contributors. >> I don't know it is that clear. I have the impression it can be >> rather effective in cases where the whole community makes it >> clear trolls are not welcome. Of course if part of the community >> is more bothered by those making trolls feel unwelcome than by >> the trolls themselves, such strive will of course attract them. > I don't think you understand the troll mindset. They don't care > whether the community does or does not welcome them, because they > don't view themselves as part of the community. They just want > affirmation and attention, which is exactly what they get when > some
Re: Idea for key parameter in all() builting, would it be feasible?
> If you're getting this via the mailing list, just hit Reply, and then > > change the To: address to python-list@python.org - that's the simplest > > (assuming you don't have a Reply To List feature, but you wouldn't be > > saying the above if you had one). That way, you get a citation line, > > quoted text is marked, and it's taken a minimum of effort. I guess it was pretty late last night but I didn't notice the huge post reply button *palmface*. > Awesome! Hey, if you *can* switch to Py3, do try to. It has heaps of > > improvements, and it has a future. :) > > > > ChrisA Also I realized that aside from using map or the better alternative imap, an even better way to go might be a generator expression. Completely forgot about those. So with a slightly less trivial example than the first >>> all(map(lambda x: n%x, xrange(2, n))) could be better written as >>> all(n%x for n in xrange(2, n)) which is roughly 10 times faster and memory efficient, plus syntax is cleaner. And roughly 1.5 times faster than imap which isn't much but prevents having to import itertools. But I discovered a new itertools tool and my sieve was successful. def primeset(upper): return set([2]+range(3,upper,2)).difference(set.union(*[set(xrange(p+p,upper,p)) for p in [n for n in xrange(3,int(pow(upper, 0.5)+1)) if all(n%x for x in xrange(2, int(pow(n, 0.5)+1)))]])) Here is the more sane version of the one-liner above. def primeset(upper): def isprime(n): # brute force trial division for d in xrange(2, int(pow(n, 0.5)+1)): if n%d == 0: return False return True # Initial set of only odd numbers except for 2 numbers = set([2]+range(3, upper, 2)) # List of prime numbers up to square root of upper using brute force. primes = [n for n in xrange(2, int(pow(upper,0.5)+1)) if isprime(n)] # Multiples of all the prime numbers in the list above. all_multiples = (set(xrange(p+p,upper,p)) for p in primes) # This was allot faster than reduce(set.union, all_multiples) multiples = set.union(*all_multiples) # And the sieving action. return numbers.difference(multiples) Rough benchmarks: >>> timer(primeset, 10**6) 1.0981476384030202 >>> # straight forward Eratosthenes sieve >>> timer(primes, 10**6) 0.5887037628822327 -- http://mail.python.org/mailman/listinfo/python-list
Re: Idea for key parameter in all() builting, would it be feasible?
Op 19-06-13 18:14, russ.po...@gmail.com schreef: > all(map(lambda x: bool(x), xrange(10**9))) Since you already have your answer, I just like to get your attention to the fact the the lambda is superfluous here. Your expression above is equivallent to all(map(bool, xrange(10**9))) -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On 20/06/2013 07:26, Steven D'Aprano wrote: On Wed, 19 Jun 2013 18:46:59 -0700, Rick Johnson wrote: On Thursday, June 13, 2013 2:11:08 AM UTC-5, Steven D'Aprano wrote: Gah! That's twice I've screwed that up. Sorry about that! Yeah, and your difficulty explaining the Unicode implementation reminds me of a passage from the Python zen: "If the implementation is hard to explain, it's a bad idea." The *implementation* is easy to explain. It's the names of the encodings which I get tangled up in. You're off by one below! ASCII: Supports exactly 127 code points, each of which takes up exactly 7 bits. Each code point represents a character. 128 codepoints. Latin-1, Latin-2, MacRoman, MacGreek, ISO-8859-7, Big5, Windows-1251, and about a gazillion other legacy charsets, all of which are mutually incompatible: supports anything from 127 to 65535 different code points, usually under 256. 128 to 65536 codepoints. UCS-2: Supports exactly 65535 code points, each of which takes up exactly two bytes. That's fewer than required, so it is obsoleted by: 65536 codepoints. etc. UTF-16: Supports all 1114111 code points in the Unicode charset, using a variable-width system where the most popular characters use exactly two- bytes and the remaining ones use a pair of characters. UCS-4: Supports exactly 4294967295 code points, each of which takes up exactly four bytes. That is more than needed for the Unicode charset, so this is obsoleted by: UTF-32: Supports all 1114111 code points, using exactly four bytes each. Code points outside of the range 0 through 1114111 inclusive are an error. UTF-8: Supports all 1114111 code points, using a variable-width system where popular ASCII characters require 1 byte, and others use 2, 3 or 4 bytes as needed. Ignoring the legacy charsets, only UTF-16 is a terribly complicated implementation, due to the surrogate pairs. But even that is not too bad. The real complication comes from the interactions between systems which use different encodings, and that's nothing to do with Unicode. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Jun 20, 12:38 am, Rick Johnson wrote: > On Wednesday, June 19, 2013 2:17:35 PM UTC-5, Ahmed Abdulshafy wrote: > > I'm reading the Python.org tutorial right now, and I found > > this part rather strange and incomprehensible to me> > > > Important warning: The default value is evaluated only > > once. This makes a difference when the default is a > > mutable object such as a list, dictionary, or instances of > > most classes > > > def f(a, L=[]): > > L.append(a) > > return L > > > print(f(1)) > > print(f(2)) > > print(f(3)) > > > This will print > > > [1] > > [1, 2] > > [1, 2, 3] > > > How the list is retained between successive calls? And > > why? > > By the evil hands of an illogical consistency. > > Have you ever heard the old adage: "The road to hell is > paved in good intentions"? Well, apparently the original > designers of the language called in sick the day that class > was taught. It's unfortunate because the same functionality > that this "intention" claims to solve can be reproduced > easily, and in a less astonishing manner, by the programmer > himself. > > http://en.wikipedia.org/wiki/Principle_of_least_astonishment Every language has gotchas. This is one of python's. If you are a beginning python programmer, really the best answer is: Just dont do it! Dont do what? Dont use mutable arguments as function defaults. And when you feel that you need to, use Steven's trick: use a immutable indicator 'None' for the mutable []. Once you cross the noob stage you can check that its a standard gotcha: Just run a search for 'python gotcha default []' Its even been discussed repeatedly on the python-ideas list Heres a correction suggestion: http://mail.python.org/pipermail/python-ideas/2007-January/73.html Here's Terry Reedy's nicely explaining the 'why-of-the-how' : http://mail.python.org/pipermail/python-ideas/2009-May/004680.html FWIW here is a conceptual/philosophical explanation of your confusion: There are 2 fundamental ways for approaching the programming task -- functional and imperative. In FP, the primary requirement is that the behavior of a function should be entirely determinable by its arguments. In Imp. P, computation proceeds by changing state. Now from the time of Backus turing award http://amturing.acm.org/award_winners/backus_0703524.cfm it is known that the two philosophies are mutually incompatible. Now python is in a rather unique position in this respect: it supports many of the features of modern FPLs and one can almost do functional programming in it. In a few cases the imperative/Object-based internals leak out, this is one of those cases. That such leakage will occasionally happen see: http://www.joelonsoftware.com/articles/LeakyAbstractions.html And you've had a little excess of the FP koolaid read : http://blog.languager.org/2012/08/functional-programming-philosophical.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
In article <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>, rusi wrote: > > > def f(a, L=[]): > > > L.append(a) > > > return L > Every language has gotchas. This is one of python's. One of our pre-interview screening questions for Python programmers at Songza is about this. I haven't been keeping careful statistics, but I'd guess only about 50% of the candidates get this right. -- http://mail.python.org/mailman/listinfo/python-list
New line conversion with Popen attached to a pty
Hi,
Sorry if this appears twice, I sent it to the mailing list earlier and the mail
seems to have been swallowed by the black hole of email vagaries.
We have a class which executes external processes in a controlled environment
and does "things" specified by the client program with each line of output. To
do this we have been attaching stdout from the subprocess.Popen to a pseudo
terminal (pty) made with pty.openempty and opened with os.fdopen. I noticed
that we kept getting a bunch of extra new line characters.
This is all using python 2.6.4 in a centos6 environment.
After some investigation I realised we needed to use universal_newline support
so I enabled it for the Popen and specified the mode in the fdopen to be rU.
Things still seemed to be coming out wrong so I wrote up a test program boiling
it down to the simplest cases (which is at the end of this message). The output
I was testing was this:
Fake\r\nData\r\n
as seen through hexdump -C:
> hexdump -C output.txt
46 61 6b 65 0d 0a 44 61 74 61 0d 0a |Fake..Data..|
000c
Now if I do a simple subprocess.Popen and set the stdout to subprocess.PIPE,
then do p.stdout.read() I get the correct output of
Fake\nData\n
When do the Popen attached to a pty I end up with
Fake\n\nData\n\n
Does anyone know why the newline conversion would be incorrect, and what I
could do to fix it? In fact if anyone even has any pointers to where this might
be going wrong I'd be very helpful, I've done hours of fiddling with this and
googling to no avail.
One liner to generate the test data:
python -c 'f = open("output.txt", "w"); f.write("Fake\r\nData\r\n"); f.close()'
Test script:
#!/usr/bin/env python2.6.4
import os
import pty
import subprocess
import select
import fcntl
class TestRead(object):
def __init__(self):
super(TestRead, self).__init__()
self.outputPipe()
self.outputPty()
def outputPipe(self):
p1 = subprocess.Popen(
("/bin/cat", "output.txt"),
stdout=subprocess.PIPE,
universal_newlines=True
)
print "1: %r" % p1.stdout.read()
def outputPty(self):
outMaster, outSlave = pty.openpty()
fcntl.fcntl(outMaster, fcntl.F_SETFL, os.O_NONBLOCK)
p2 = subprocess.Popen(
("/bin/cat", "output.txt"),
stdout=outSlave,
universal_newlines=True
)
with os.fdopen(outMaster, 'rU') as pty_stdout:
while True:
try:
rfds, _, _ = select.select([pty_stdout], [], [], 0.1)
break
except select.error:
continue
for fd in rfds:
buf = pty_stdout.read()
print "2: %r" % buf
if __name__ == "__main__":
t = TestRead()
Thanks,
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Jun 20, 6:19 pm, Roy Smith wrote: > In article > <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>, > > rusi wrote: > > > > def f(a, L=[]): > > > > L.append(a) > > > > return L > > Every language has gotchas. This is one of python's. > > One of our pre-interview screening questions for Python programmers at > Songza is about this. I haven't been keeping careful statistics, but > I'd guess only about 50% of the candidates get this right. See http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD480.html (search forward to 'disastrous blending' ) No I am not saying that such knowledge is not required in the 'real world' However I do feel that just as a view of literature that does not go beyond gothic horror is a poor view; and just because for languages like C (even more C++) expertise more or less equivales gothicness, for a cleaner world like python we should distinguish the seedy areas we know about but avoid and the clean areas we live in. Clearly flagging gotchas as such helps in that direction. In short (and to the OP): If you did NOT find this confusing, it would be cause for more concern :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On 20 June 2013 04:11, Cameron Simpson wrote: > Also, opening-and-not-closing a set of brackets is almost the only > way in Python to make this kind of error (syntax at one line, actual > mistake far before). > > See if your editor has a show-the-matching-bracket mode. > If you suspect you failed to close a bracket, one approach is to > go _below_ the syntax error (or right on it) and type a closing > bracket. Then see where the editor thinks the opening one is. Thanks for that, that's quite an ingenious technique. -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Thursday, June 20, 2013 1:26:17 AM UTC-5, Steven D'Aprano wrote: > The *implementation* is easy to explain. It's the names of > the encodings which I get tangled up in. Well, ignoring the fact that you're last explanation is still buggy, you have not actually described an "implementation", no, you've merely generalized ( and quite vaguely i might add) the technical specification of a few encoding. Let's ask Wikipedia to enlighten us on the subject of "implementation": # Define: Implementation # # In computer science, an implementation is a realization # # of a technical specification or algorithm as a program, # # software component, or other computer system through # # computer programming and deployment. Many# # implementations may exist for a given specification or # # standard. For example, web browsers contain # # implementations of World Wide Web Consortium-recommended # # specifications, and software development tools contain # # implementations of programming languages.# Do you think someone could reliably implement the alphabet of a new language in Unicode by using the general outline you provided? -- again, ignoring your continual fumbling when explaining that simple generalization :-) Your generalization is analogous to explaining web browsers as: "software that allows a user to view web pages in the range www.*" Do you think someone could implement a web browser from such limited specification? (if that was all they knew?). Since we're on the subject of Unicode: One the most humorous aspects of Unicode is that it has encodings for Braille characters. Hmm, this presents a conundrum of sorts. RIDDLE ME THIS?! Since Braille is a type of "reading" for the blind by utilizing the sense of touch (therefore DEMANDING 3 dimensions) and glyphs derived from Unicode are restrictively two dimensional, because let's face it people, Unicode exists in your computer, and computer screens are two dimensional... but you already knew that -- i think?, then what is the purpose of a Unicode Braille character set? That should haunt your nightmares for some time. -- http://mail.python.org/mailman/listinfo/python-list
Re: About GIL Questions!
On 20 June 2013 05:13, Thanatos xiao wrote: > Hey everyone! > Recently I see the python source code, but i still not understand about gil. > first, why single core quicker multi-core ? Chris Angelico touched on your other points, but not this as clearly; Python threads run on one thread because they have to. It is not because they're faster. Python theoretically would be faster if its threads could run multicore, but it's really hard to make that work. See http://pypy.org/tmdonate.html for an example of the acrobatics it would take to get a propper GIL-free Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On 2013-06-20, Joshua Landau wrote: > On 20 June 2013 04:11, Cameron Simpson wrote: >> Also, opening-and-not-closing a set of brackets is almost the >> only way in Python to make this kind of error (syntax at one >> line, actual mistake far before). >> >> See if your editor has a show-the-matching-bracket mode. >> If you suspect you failed to close a bracket, one approach is >> to go _below_ the syntax error (or right on it) and type a >> closing bracket. Then see where the editor thinks the opening >> one is. > > Thanks for that, that's quite an ingenious technique. The auto-indent feature of Vim catches this type of syntax error, and I imagine other good autoindent support will do the same. After I press enter and the following line's indent isn't what I expect, it is nearly always due to a missing bracket, quote or colon. So if you press enter and the autoindent is unexpected, don't just press space or backspace to fix it. It's usually a sign of an earlier syntax error, so look for that first. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On 2013.06.20 08:40, Rick Johnson wrote: > One the most humorous aspects of Unicode is that it has > encodings for Braille characters. Hmm, this presents a > conundrum of sorts. RIDDLE ME THIS?! > > Since Braille is a type of "reading" for the blind by > utilizing the sense of touch (therefore DEMANDING 3 > dimensions) and glyphs derived from Unicode are > restrictively two dimensional, because let's face it people, > Unicode exists in your computer, and computer screens are > two dimensional... but you already knew that -- i think?, > then what is the purpose of a Unicode Braille character set? Two dimensional characters can be made into 3 dimensional shapes. Building numbers are a good example of this. We already have one Unicode troll; do we really need you too? -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On 20 June 2013 04:11, Cameron Simpson wrote:
> I use vi/vim and it both shows the matching bracket when the cursor
> is on one and also have a keystroke to bounce the curser between
> this bracket and the matching one.
>
> If you suspect you failed to close a bracket, one approach is to
> go _below_ the syntax error (or right on it) and type a closing
> bracket. Then see where the editor thinks the opening one is.
I use this technique sometimes and it works if the unclosed bracket is
still in view.
If you use vim then you can do [( i.e. type '[' followed by '(' in
normal mode. It will jump backwards to the first unmatched opening
bracket. Use ]) to find the next unmatched closing bracket. You can
also do [{ and ]} for curly brackets. I'm not sure how to do square
brackets - [[ and ]] are used for navigating between functions.
Oscar
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote: > Every language has gotchas. This is one of python's. So are we purposely injecting illogic into our language just to be part of some "cool crowd" of programming languages with gotchas. "You thought intuitiveness was a virtue? Haha, we gotcha!" Or maybe this is reminiscent of the fraternity hazing rituals of days gone by: *POP* "Thank you Sir, may i have another?" > If you are a beginning python programmer, really the best > answer is: Just dont do it! Dont do what? Dont use > mutable arguments as function defaults. Once you cross the > noob stage you can check that its a standard gotcha: Just > run a search for 'python gotcha default []' > > And when you feel that you need to, use Steven's trick: > use a immutable indicator 'None' for the mutable []. Once > you cross the noob stage you can check that its a standard > gotcha: Just run a search for 'python gotcha default []' > Its even been discussed repeatedly on the python-ideas > list Your attempting to excuse an inexcusable language flaw by pointing out that the effects of the flaw can be avoided by using a workaround. And, to add insult to injury, you provide no good reason for the flaw to exist: "Just do x, y, and z and shut up. Yes we made a mistake but we are not about to admit our mistake and the onerous will be on all the noobs to re-invent the workaround each time" To me that is unacceptable. > Heres a correction suggestion: [...] Here's Terry Reedy's > nicely explaining the 'why-of-the-how' : [...] FWIW here > is a conceptual/philosophical explanation of your > confusion: There are 2 fundamental ways for approaching > the programming task -- functional and imperative. All these "explanations" ignore a fundamental fact about subroutines[1]. A call to a subroutine should exists as a unique transaction within the entire program. It is expected to optionally take inputs, and optionally return an output (depending on the definition). When the subroutine is completed, all inputs and local variables are expected to be destroyed. If the programmer wants a return value, he need simply ask. Data persistence is not a function of subroutines! Finally, a subroutine should never have side effects UNLESS the programmer explicitly ask for a side effect. However, the Python flaw of allowing mutable sequence arguments to persist between successive calls of a subroutine is breaking the entire definition of a subroutine, and for what noble purpose i ask? What purpose is SO important that you change a well established interface in a totally unintuitive manner? If your answer is that recursion is easier, then i say that is foolish because a programmer can keep a reference to a mutable sequence OUTSIDE the subroutine and you can save the "gotchas" for Guido's next birthday party. [1]: http://en.wikipedia.org/wiki/Subroutine -- http://mail.python.org/mailman/listinfo/python-list
Re: Idea for key parameter in all() builting, would it be feasible?
On Thursday, June 20, 2013 12:45:27 PM UTC+2, Antoon Pardon wrote: > Op 19-06-13 18:14, russ.po...@gmail.com schreef: > > > > > all(map(lambda x: bool(x), xrange(10**9))) > > > > Since you already have your answer, I just like to get your attention > > to the fact the the lambda is superfluous here. Your expression > > above is equivallent to > > > > all(map(bool, xrange(10**9))) That's true, I didn't notice that. Although it was a trivial example I was setting up from the actual code and couldn't think of what to shove inside lambda so bool got the short straw. The latest example I showed was actually. >>> all(map(lambda x: n%x, xrange(2, n))) -- http://mail.python.org/mailman/listinfo/python-list
Re: dynamic if statement
On Tuesday, June 18, 2013 10:10:42 AM UTC-4, upper...@gmail.com wrote: > I am new to python and struggling with creating a dynamic if statement. > > > > I have a set of queries that are run against various databases/tables. The > result is all the same in that I always get back the same field names. > > > > What I want to do is total the results differently based on the table. so for > instance > > > > I query fld1, fld2, fld3, qty, qty2 from table1 > > then I loop thru the results > > if fld1 = 'a' add qty to some_total1 > > > > I query fld1, fld2, fld3, qty, qty2 from table2 > > then I loop thru the results > > if fld2 = 'b' add qty to some_total1 > > > > I query fld1, fld2, fld3, qty, qty2 from table3 > > then I loop thru the results > > if fld3 = 'c' add qty2 to some_total1 > > > > I created a database pair that contains (table1,fld1 = 'a',add qty to > some_total1) > > (table2,fld2 = 'b',qty to some_total1) > > (table3,fld3 = 'c',qty2 to some_total1) > > > > So I know which table I am using, I query my list pair but I cant see how to > build the if statement using the results from the query. > > > > something like this would be the result > > var1 = "fld1 = 'a'" > > result = "add qty to some_total1" > > > > if var1: > > result thanks for the help.. with a bit of tweaking i got it working as needed -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Thursday, June 20, 2013 9:04:50 AM UTC-5, Andrew Berg wrote: > On 2013.06.20 08:40, Rick Johnson wrote: > > then what is the purpose of a Unicode Braille character set? > Two dimensional characters can be made into 3 dimensional shapes. Yes in the real world. But what about on your computer screen? How do you plan on creating tactile representations of braille glyphs on my monitor? Hey, if you can already do this, please share, as it sure would make internet porn more interesting! > Building numbers are a good example of this. Either the matrix is reality or you must live inside your computer as a virtual being. Is your name Tron? Are you a pawn of Master Control? He's such a tyrant! -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Fri, Jun 21, 2013 at 1:12 AM, Rick Johnson wrote: > On Thursday, June 20, 2013 9:04:50 AM UTC-5, Andrew Berg wrote: >> On 2013.06.20 08:40, Rick Johnson wrote: > >> > then what is the purpose of a Unicode Braille character set? >> Two dimensional characters can be made into 3 dimensional shapes. > > Yes in the real world. But what about on your computer > screen? How do you plan on creating tactile representations of > braille glyphs on my monitor? Hey, if you can already do this, > please share, as it sure would make internet porn more > interesting! I had a device for creating embossed text. It predated Unicode by a couple of years at least (not sure how many, because I was fairly young at the time). It was made by a company called Epson, it plugged into the computer via a 25-pin plug, and when it was properly functioning, it had a ribbon of ink that it would bash through to darken the underside of the embossed text. But sometimes that ribbon slipped out of position, and we had beautifully-hammered ASCII text, unsullied by ink. And since the device did graphics too, it could be used for the entire Unicode character set if you wanted. Not sure that it would improve your porn any, but I've no doubt you could try if you wanted. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Thu, Jun 20, 2013 at 11:40 PM, Rick Johnson wrote: > Your generalization is analogous to explaining web browsers > as: "software that allows a user to view web pages in the > range www.*" Do you think someone could implement a web > browser from such limited specification? (if that was all > they knew?). Wow. That spec isn't limited, it's downright faulty. Or do you really think that (a) there is such a thing as the "range www.*", and that (b) that "range" has anything to do with web browsers? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Fri, Jun 21, 2013 at 12:49 AM, Rick Johnson
wrote:
> When the subroutine is completed, all inputs and local
> variables are expected to be destroyed. If the programmer
> wants a return value, he need simply ask. Data persistence
> is not a function of subroutines!
Funny, C violates your description too.
int counter()
{
static int count;
return ++count;
}
Function defaults in Python, being implemented as attributes on the
function object, are very similar in nature to static variables in C.
They're constructed once at function creation time, they're available
to that function (okay, C doesn't have any concept of "reaching into"
a function from the outside, Python does), they out-last any
particular execution of that function.
> Finally, a subroutine
> should never have side effects UNLESS the programmer
> explicitly ask for a side effect.
Bogus.
http://www.postgresql.org/docs/current/static/sql-createfunction.html
By default, a function is assumed to have side effects. The
programmer/sysadmin has to explicitly ask for PostgreSQL to treat the
function as NOT having side effects (the IMMUTABLE attribute, or
possibly its weaker cousin STABLE).
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Idea for key parameter in all() builting, would it be feasible?
On Fri, Jun 21, 2013 at 12:49 AM, Russel Walker wrote: > On Thursday, June 20, 2013 12:45:27 PM UTC+2, Antoon Pardon wrote: >> Op 19-06-13 18:14, russ.po...@gmail.com schreef: >> >> > >> >> all(map(lambda x: bool(x), xrange(10**9))) >> >> Since you already have your answer, I just like to get your attention >> to the fact the the lambda is superfluous here. Your expression >> above is equivallent to >> >> all(map(bool, xrange(10**9))) > > That's true, I didn't notice that. Although it was a trivial example I was > setting up from the actual code and couldn't think of what to shove inside > lambda so bool got the short straw. Yeah, I've been guilty of that fairly often - making a trivial example that can be trivialized even more. Sometimes all you need to do is acknowledge it with a comment and move on, other times the additional trivialization is a clue to the actual problem :) In this particular case, all() will boolify anyway, so you don't even need map. But that would completely destroy your example: all(xrange(10**9)) # Doesn't help with figuring out the original issue! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On Thu, Jun 20, 2013 at 11:55 PM, Neil Cerutti wrote:
> On 2013-06-20, Joshua Landau wrote:
>> On 20 June 2013 04:11, Cameron Simpson wrote:
>>> Also, opening-and-not-closing a set of brackets is almost the
>>> only way in Python to make this kind of error (syntax at one
>>> line, actual mistake far before).
>>>
>>> See if your editor has a show-the-matching-bracket mode.
>>> If you suspect you failed to close a bracket, one approach is
>>> to go _below_ the syntax error (or right on it) and type a
>>> closing bracket. Then see where the editor thinks the opening
>>> one is.
>>
>> Thanks for that, that's quite an ingenious technique.
>
> The auto-indent feature of Vim catches this type of syntax error,
> and I imagine other good autoindent support will do the same.
> After I press enter and the following line's indent isn't what I
> expect, it is nearly always due to a missing bracket, quote or
> colon.
>
> So if you press enter and the autoindent is unexpected, don't
> just press space or backspace to fix it. It's usually a sign of
> an earlier syntax error, so look for that first.
Yes, though editors (like everything else!) can be buggy - SciTE, for
instance, has a bug with handling two adjacent braces in C code:
void dummy_function() {}
//SciTE will indent after that line
But autoindentation is a *hugely* valuable feature, because it gives
INSTANT feedback. You hit enter, the line is indented, you expected no
indent, problem found. And I've even used it as a means of probing -
if there's a problem in this area somewhere, I just go to the middle
of the area, hit enter to insert a blank line, and see if the
indentation is wrong. If it is, the problem's in the top half, else
the problem's in the bottom half. That is: The problem is in the
top-if-indentation-wrong-else-bottom half, using Python's ternary
syntax. Or the (indentation-wrong? top: bottom) half, in C notation.
Or... okay, I'll stop now.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Looking for a scalable Python cloud platform ? Go try Clever Cloud!
If you'are looking for hosting some Python in the cloud, let me introduce you to http://python-cloud.com/ This PaaS platform can automatically scale up and down your application regarding your traffic. You can also finely customize if you want vertical, horizontal or both types of scalability. The consequence of this scaling is that you pay as you go: you only pay for your real consumption and not the potential one. Deployment via git. Non AWS, hosted in tier-4+ datacenters. Free trial! Disclosure: I work at Clever Cloud. -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
Le jeudi 20 juin 2013 13:43:28 UTC+2, MRAB a écrit : > On 20/06/2013 07:26, Steven D'Aprano wrote: > > > On Wed, 19 Jun 2013 18:46:59 -0700, Rick Johnson wrote: > > > > > >> On Thursday, June 13, 2013 2:11:08 AM UTC-5, Steven D'Aprano wrote: > > >> > > >>> Gah! That's twice I've screwed that up. Sorry about that! > > >> > > >> Yeah, and your difficulty explaining the Unicode implementation reminds > > >> me of a passage from the Python zen: > > >> > > >> "If the implementation is hard to explain, it's a bad idea." > > > > > > The *implementation* is easy to explain. It's the names of the encodings > > > which I get tangled up in. > > > > > You're off by one below! > > > > > > ASCII: Supports exactly 127 code points, each of which takes up exactly 7 > > > bits. Each code point represents a character. > > > > > 128 codepoints. > > > > > Latin-1, Latin-2, MacRoman, MacGreek, ISO-8859-7, Big5, Windows-1251, and > > > about a gazillion other legacy charsets, all of which are mutually > > > incompatible: supports anything from 127 to 65535 different code points, > > > usually under 256. > > > > > 128 to 65536 codepoints. > > > > > UCS-2: Supports exactly 65535 code points, each of which takes up exactly > > > two bytes. That's fewer than required, so it is obsoleted by: > > > > > 65536 codepoints. > > > > etc. > > > > > UTF-16: Supports all 1114111 code points in the Unicode charset, using a > > > variable-width system where the most popular characters use exactly two- > > > bytes and the remaining ones use a pair of characters. > > > > > > UCS-4: Supports exactly 4294967295 code points, each of which takes up > > > exactly four bytes. That is more than needed for the Unicode charset, so > > > this is obsoleted by: > > > > > > UTF-32: Supports all 1114111 code points, using exactly four bytes each. > > > Code points outside of the range 0 through 1114111 inclusive are an error. > > > > > > UTF-8: Supports all 1114111 code points, using a variable-width system > > > where popular ASCII characters require 1 byte, and others use 2, 3 or 4 > > > bytes as needed. > > > > > > > > > Ignoring the legacy charsets, only UTF-16 is a terribly complicated > > > implementation, due to the surrogate pairs. But even that is not too bad. > > > The real complication comes from the interactions between systems which > > > use different encodings, and that's nothing to do with Unicode. > > > > > > And all these coding schemes have something in common, they work all with a unique set of code points, more precisely a unique set of encoded code points (not the set of implemented code points (byte)). Just what the flexible string representation is not doing, it artificially devides unicode in subsets and try to handle eache subset differently. On this other side, that is because it is impossible to work properly with multiple sets of encoded code points that all these coding schemes exist today. There are simply no other way. Even "exotic" schemes like "CID-fonts" used in pdf are based on that scheme. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Fri, Jun 21, 2013 at 2:27 AM, wrote: > And all these coding schemes have something in common, > they work all with a unique set of code points, more > precisely a unique set of encoded code points (not > the set of implemented code points (byte)). > > Just what the flexible string representation is not > doing, it artificially devides unicode in subsets and try > to handle eache subset differently. > UTF-16 divides Unicode into two subsets: BMP characters (encoded using one 16-bit unit) and astral characters (encoded using two 16-bit units in the D800::/5 netblock, or equivalent thereof). Your beloved narrow builds are guilty of exactly the same crime as the hated 3.3. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
Rick Johnson wrote: > > Since we're on the subject of Unicode: > >One the most humorous aspects of Unicode is that it has >encodings for Braille characters. Hmm, this presents a >conundrum of sorts. RIDDLE ME THIS?! > >Since Braille is a type of "reading" for the blind by >utilizing the sense of touch (therefore DEMANDING 3 >dimensions) and glyphs derived from Unicode are >restrictively two dimensional, because let's face it people, >Unicode exists in your computer, and computer screens are >two dimensional... but you already knew that -- i think?, >then what is the purpose of a Unicode Braille character set? > >That should haunt your nightmares for some time. >From http://www.unicode.org/versions/Unicode6.2.0/ch15.pdf "The intent of encoding the 256 Braille patterns in the Unicode Standard is to allow input and output devices to be implemented that can interchange Braille data without having to go through a context-dependent conversion from semantic values to patterns, or vice versa. In this manner, final-form documents can be exchanged and faithfully rendered." http://files.pef-format.org/specifications/pef-2008-1/pef-specification.html#Unicode I wish you a pleasant sleep tonight. Bye, Andreas -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
You know Rick, you are good at python, you are better at polemics. If only you would cut the crap I would (be able to) agree with you. See below On Jun 20, 7:49 pm, Rick Johnson wrote: > On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote: > > Every language has gotchas. This is one of python's. > > So are we purposely injecting illogic into our language just > to be part of some "cool crowd" of programming languages with > gotchas. > > "You thought intuitiveness was a virtue? Haha, we gotcha!" Python (and all the other 'cool' languages) dont have gotchas because someone malevolently put them there. In most cases, the problem is seen too late and the cost of changing entrenched code too great. Or the problem is clear, the solution is not etc etc. > > Or maybe this is reminiscent of the fraternity hazing rituals > of days gone by: > > *POP* > "Thank you Sir, may i have another?" > > > If you are a beginning python programmer, really the best > > answer is: Just dont do it! Dont do what? Dont use > > mutable arguments as function defaults. Once you cross the > > noob stage you can check that its a standard gotcha: Just > > run a search for 'python gotcha default []' > > > And when you feel that you need to, use Steven's trick: > > use a immutable indicator 'None' for the mutable []. Once > > you cross the noob stage you can check that its a standard > > gotcha: Just run a search for 'python gotcha default []' > > Its even been discussed repeatedly on the python-ideas > > list > > Your attempting to excuse an inexcusable language flaw by > pointing out that the effects of the flaw can be avoided by > using a workaround. And, to add insult to injury, you > provide no good reason for the flaw to exist: > > "Just do x, y, and z and shut up. Yes we made a mistake > but we are not about to admit our mistake and the onerous > will be on all the noobs to re-invent the workaround each > time" > > To me that is unacceptable. > > > Heres a correction suggestion: [...] Here's Terry Reedy's > > nicely explaining the 'why-of-the-how' : [...] FWIW here > > is a conceptual/philosophical explanation of your > > confusion: There are 2 fundamental ways for approaching > > the programming task -- functional and imperative. > > All these "explanations" ignore a fundamental fact about > subroutines[1]. > > A call to a subroutine should exists as a unique transaction > within the entire program. It is expected to optionally take > inputs, and optionally return an output (depending on the > definition). > > When the subroutine is completed, all inputs and local > variables are expected to be destroyed. If the programmer > wants a return value, he need simply ask. Data persistence > is not a function of subroutines! Finally, a subroutine > should never have side effects UNLESS the programmer > explicitly ask for a side effect. > > However, the Python flaw of allowing mutable sequence > arguments to persist between successive calls of a > subroutine is breaking the entire definition of a > subroutine, and for what noble purpose i ask? What purpose > is SO important that you change a well established interface > in a totally unintuitive manner? > > If your answer is that recursion is easier, then i say that > is foolish because a programmer can keep a reference > to a mutable sequence OUTSIDE the subroutine and you can > save the "gotchas" for Guido's next birthday party. > > [1]:http://en.wikipedia.org/wiki/Subroutine You are saying in different language what I said: Functional programming is a good idea, imperative programming is a bad idea. >From the invention of subroutines (ie 50 years) PL designers are hearing this truth but somehow or other fail to listen; for more details see http://blog.languager.org/2012/11/imperative-programming-lessons-not.html -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On 20/06/2013 17:37, Chris Angelico wrote: On Fri, Jun 21, 2013 at 2:27 AM, wrote: And all these coding schemes have something in common, they work all with a unique set of code points, more precisely a unique set of encoded code points (not the set of implemented code points (byte)). Just what the flexible string representation is not doing, it artificially devides unicode in subsets and try to handle eache subset differently. UTF-16 divides Unicode into two subsets: BMP characters (encoded using one 16-bit unit) and astral characters (encoded using two 16-bit units in the D800::/5 netblock, or equivalent thereof). Your beloved narrow builds are guilty of exactly the same crime as the hated 3.3. UTF-8 divides Unicode into subsets which are encoded in 1, 2, 3, or 4 bytes, and those who previously used ASCII still need only 1 byte per codepoint! -- http://mail.python.org/mailman/listinfo/python-list
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]
Νίκος schreef:
Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:
Names are *always* linked to objects, not to other names.
a = []
b = a # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before
I see, thank you Steven.
But since this is a fact how do you create complicated data structures
that rely on various variables pointing one to another liek we did in
C++(cannot recall their names) ?
You almost never need to do that in Python. But if you really want to,
out of curiosity, you can. For example, you could create a simple singly
linked list like this:
>>> class Node(object):
def __init__(self, value):
self.value = value
self.next = None
>>> first = Node(1)
>>> second = Node(2)
>>> first.next = second
You could iterate over it like this:
>>> def iterate_linked_list(node):
while node:
yield node.value
node = node.next
>>> for v in iterate_linked_list(first):
print v
--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise
r...@roelschroeven.net
--
http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On Fri, Jun 21, 2013 at 3:17 AM, MRAB wrote: > On 20/06/2013 17:37, Chris Angelico wrote: >> >> On Fri, Jun 21, 2013 at 2:27 AM, wrote: >>> >>> And all these coding schemes have something in common, >>> they work all with a unique set of code points, more >>> precisely a unique set of encoded code points (not >>> the set of implemented code points (byte)). >>> >>> Just what the flexible string representation is not >>> doing, it artificially devides unicode in subsets and try >>> to handle eache subset differently. >>> >> >> >> UTF-16 divides Unicode into two subsets: BMP characters (encoded using >> one 16-bit unit) and astral characters (encoded using two 16-bit units >> in the D800::/5 netblock, or equivalent thereof). Your beloved narrow >> builds are guilty of exactly the same crime as the hated 3.3. >> > UTF-8 divides Unicode into subsets which are encoded in 1, 2, 3, or 4 > bytes, and those who previously used ASCII still need only 1 byte per > codepoint! Yes, but there's never (AFAIK) been a Python implementation that represents strings in UTF-8; UTF-16 was one of two options for Python 2.2 through 3.2, and is the one that jmf always seems to be measuring against. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
Rick Johnson writes: > On Thursday, June 20, 2013 9:04:50 AM UTC-5, Andrew Berg wrote: > > On 2013.06.20 08:40, Rick Johnson wrote: > > > > then what is the purpose of a Unicode Braille character set? > > Two dimensional characters can be made into 3 dimensional shapes. > > Yes in the real world. But what about on your computer screen? How > do you plan on creating tactile representations of braille glyphs on > my monitor? Hey, if you can already do this, please share, as it > sure would make internet porn more interesting! Search for braille display on the web. A wikipedia article also led me to braille e-book. (Or search for braille porn, since you are so inclined - the concept turns out to be already out there on the web.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote: > Python (and all the other 'cool' languages) dont have gotchas because > someone malevolently put them there. > In most cases, the problem is seen too late and the cost of changing > entrenched code too great. > Or the problem is clear, the solution is not etc etc. Or, in many MANY cases, the choice was the right one, but isn't obvious to everyone. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Jun 20, 10:19 pm, Chris Angelico wrote: > On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote: > > Python (and all the other 'cool' languages) dont have gotchas because > > someone malevolently put them there. > > In most cases, the problem is seen too late and the cost of changing > > entrenched code too great. > > Or the problem is clear, the solution is not etc etc. > > Or, in many MANY cases, the choice was the right one, but isn't > obvious to everyone. > > ChrisA Ha! If you've ever taught a first programming class you would know how frequent is the complaint (said by a beginning student in a loud confident voice): THE COMPILER HAS A BUG! -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, Jun 20, 2013 at 11:19 AM, Chris Angelico wrote:
> On Fri, Jun 21, 2013 at 3:12 AM, rusi wrote:
>> Python (and all the other 'cool' languages) dont have gotchas because
>> someone malevolently put them there.
>> In most cases, the problem is seen too late and the cost of changing
>> entrenched code too great.
>> Or the problem is clear, the solution is not etc etc.
>
> Or, in many MANY cases, the choice was the right one, but isn't
> obvious to everyone.
I think it's worth pointing out that changing function defaults to
late-binding would merely change the nature of the gotcha, not eliminate it.
words = ("one", "two", "red", "blue", "fish")
def join_strings(strings=words):
return ' '.join('%s %s' % (s, strings[-1]) for s in strings[:-1])
# Later:
words = open("gettysburg_address.txt", "r").read().split()
# Oops, the default argument of join_strings just changed.
Additionally, with late-binding semantics the default values would no
longer be default *values*. They would be initialization code
instead, which sort of flies in the face of the idea that late-binding
would somehow be better for functional programming -- if the default
expressions have no side effects and since they don't depend on the
function arguments, why should they need to run more than once? If
the goal is indeed to make the the functions more functional, then the
proper solution would be to keep the binding early but just disallow
mutable defaults altogether -- which is tricky to achieve in Python,
so we simply emulate it with the advice "don't use mutable function
defaults".
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thursday, June 20, 2013 10:38:34 AM UTC-5, Chris Angelico wrote: > Function defaults in Python, being implemented as > attributes on the function object, are very similar in > nature to static variables in C. Oh wait a minute. i think it's becoming clear to me now! Python functions are objects that take arguments, of which (the arguments) are then converted to attributes of the function object. Ah-Ha! Urm, but wait! We already have a method to define Objects. Heck, I can even create my own callable objects if i want! Observe: py> class FuncAdd(object): ... def __init__(self, ivalue): ... self.ivalue = ivalue ... def __call__(self, numeric): ... return self.ivalue + numeric ... py> fa = FuncAdd(10) py> fa(10) 20 py> fa(20) 30 I can even emulate (quite easily) this idea of "persistence of function arguments" with mutables too, Yippee! py> class ArgPersist(object): ... def __init__(self, lst): ... self.lst = lst ... def __call__(self, arg): ... self.lst.append(arg) ... return self.lst ... py> fp = ArgPersist([1,2,3]) py> fp(4) [1, 2, 3, 4] py> fp([5,6,7]) [1, 2, 3, 4, [5, 6, 7]] But then, i can even do it WITHOUT creating an object definition: py> mutable = [] py> def expandMutable(arg): ... mutable.append(arg) ... py> expandMutable(1) py> mutable [1] py> expandMutable([2,3,4]) py> mutable [1, [2, 3, 4]] ANY of those approaches are much less confusing than the current flaw and do not violate the least astonishment law.. I'm quite Okay with Python functions being first class objects, however, i am not okay with violating the fundamental nature of subroutines, especially when that violation can offer no clear and arguable benefits and is in fact unreasonably esoteric in nature. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thursday, June 20, 2013 12:12:01 PM UTC-5, rusi wrote: > Python (and all the other 'cool' languages) dont have > gotchas because someone malevolently put them there. In > most cases, the problem is seen too late and the cost of > changing entrenched code too great. Okay. So now you are admitting the problem. That is a good start. Thanks for being honest. > Or the problem is clear, the solution is not etc etc. Both the problem and solution are clear, however, the will to execute the solution remains to be seem. Are you telling me we can justify breaking backwards compatibility for the sake of "print"[1] but we cannot justify breaking it for this monstrosity? Come on Rusi, you've gone too far with the comedy now. [1]: FYI I personally think print as function is the correct implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Jun 20, 10:57 pm, Ian Kelly wrote: > If > the goal is indeed to make the the functions more functional, then the > proper solution would be to keep the binding early but just disallow > mutable defaults altogether -- which is tricky to achieve in Python, > so we simply emulate it with the advice "don't use mutable function > defaults". Nicely put. "Imperative programming is a bad idea; FP is a good idea" is an attractive religious dogma. When put into practice with full religious zeal, we then need something like monads to make realistic programming possible. Which then becomes a case of "remedy worse than disease". Which is why I prefer to keep FP in the limbo region between ideology and technology -- http://mail.python.org/mailman/listinfo/python-list
Does upgrade from 2.7.3 to 2.7.5 require uninstall?
Do I need to uninstall Python 2.7.3 before installing Python 2.7.5? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Does upgrade from 2.7.3 to 2.7.5 require uninstall?
On Thu, 20 Jun 2013 11:35:49 -0700, Wanderer wrote: > Do I need to uninstall Python 2.7.3 before installing Python 2.7.5? > > Thanks that will depend on your operating system an possibly the variety of python -- I don't even butter my bread. I consider that cooking. -- Katherine Cebrian -- http://mail.python.org/mailman/listinfo/python-list
Re: Does upgrade from 2.7.3 to 2.7.5 require uninstall?
On 20/06/2013 19:35, Wanderer wrote: Do I need to uninstall Python 2.7.3 before installing Python 2.7.5? No. -- http://mail.python.org/mailman/listinfo/python-list
Problems with pkg_resources
I'm trying to get setup to work on pylint source. I've installed pylint, logilab-common and astroid in the usual manner, specifying --user to get them into my private space: python setup.py install --user If I attempt to import astroid from a Python prompt, everything's fine: % PYTHONPATH=/home/skipm/.local/lib/python2.7/site-packages python Python 2.7.2 (default, Oct 17 2012, 03:11:33) [GCC 4.4.6 [TWW]] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import astroid >>> astroid.__file__ '/home/skipm/.local/lib/python2.7/site-packages/astroid-0.24.3-py2.7.egg/astroid/__init__.pyc' but pylint can't find it: % PYTHONPATH=/home/skipm/3rdParty/astroid pylint Traceback (most recent call last): File "/home/skipm/.local/bin/pylint", line 6, in from pkg_resources import load_entry_point File "/opt/TWWfsw/distribute06/lib/python27/pkg_resources.py", line 2709, in working_set.require(__requires__) File "/opt/TWWfsw/distribute06/lib/python27/pkg_resources.py", line 686, in require needed = self.resolve(parse_requirements(requirements)) File "/opt/TWWfsw/distribute06/lib/python27/pkg_resources.py", line 584, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: logilab-astroid>=0.24.3 How do I work around this problem? I'd rather be hacking on pylint than struggling with distutils. Thx, Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Does upgrade from 2.7.3 to 2.7.5 require uninstall?
On Thursday, June 20, 2013 2:47:52 PM UTC-4, MRAB wrote: > On 20/06/2013 19:35, Wanderer wrote: > > > Do I need to uninstall Python 2.7.3 before installing Python 2.7.5? > > > > > No. You're right. I had no problems. FYI the operating system is Windows 7. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: A few questiosn about encoding
On 20/06/2013 17:27, wxjmfa...@gmail.com wrote: Le jeudi 20 juin 2013 13:43:28 UTC+2, MRAB a écrit : On 20/06/2013 07:26, Steven D'Aprano wrote: On Wed, 19 Jun 2013 18:46:59 -0700, Rick Johnson wrote: On Thursday, June 13, 2013 2:11:08 AM UTC-5, Steven D'Aprano wrote: Gah! That's twice I've screwed that up. Sorry about that! Yeah, and your difficulty explaining the Unicode implementation reminds me of a passage from the Python zen: "If the implementation is hard to explain, it's a bad idea." The *implementation* is easy to explain. It's the names of the encodings which I get tangled up in. You're off by one below! ASCII: Supports exactly 127 code points, each of which takes up exactly 7 bits. Each code point represents a character. 128 codepoints. Latin-1, Latin-2, MacRoman, MacGreek, ISO-8859-7, Big5, Windows-1251, and about a gazillion other legacy charsets, all of which are mutually incompatible: supports anything from 127 to 65535 different code points, usually under 256. 128 to 65536 codepoints. UCS-2: Supports exactly 65535 code points, each of which takes up exactly two bytes. That's fewer than required, so it is obsoleted by: 65536 codepoints. etc. UTF-16: Supports all 1114111 code points in the Unicode charset, using a variable-width system where the most popular characters use exactly two- bytes and the remaining ones use a pair of characters. UCS-4: Supports exactly 4294967295 code points, each of which takes up exactly four bytes. That is more than needed for the Unicode charset, so this is obsoleted by: UTF-32: Supports all 1114111 code points, using exactly four bytes each. Code points outside of the range 0 through 1114111 inclusive are an error. UTF-8: Supports all 1114111 code points, using a variable-width system where popular ASCII characters require 1 byte, and others use 2, 3 or 4 bytes as needed. Ignoring the legacy charsets, only UTF-16 is a terribly complicated implementation, due to the surrogate pairs. But even that is not too bad. The real complication comes from the interactions between systems which use different encodings, and that's nothing to do with Unicode. And all these coding schemes have something in common, they work all with a unique set of code points, more precisely a unique set of encoded code points (not the set of implemented code points (byte)). Just what the flexible string representation is not doing, it artificially devides unicode in subsets and try to handle eache subset differently. On this other side, that is because it is impossible to work properly with multiple sets of encoded code points that all these coding schemes exist today. There are simply no other way. Even "exotic" schemes like "CID-fonts" used in pdf are based on that scheme. jmf I entirely agree with the viewpoints of jmfauth, Nick the Greek, rr, Xah Lee and Ilias Lazaridis on the grounds that disagreeing and stating my beliefs ends up with the Python Mailing List police standing on my back doorsetep. Give me the NSA or GCHQ any day of the week :( -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: New line conversion with Popen attached to a pty
jfhar...@gmail.com wrote:
> Hi,
>
> Sorry if this appears twice, I sent it to the mailing list earlier and the
> mail seems to have been swallowed by the black hole of email vagaries.
>
> We have a class which executes external processes in a controlled
> environment and does "things" specified by the client program with each
> line of output. To do this we have been attaching stdout from the
> subprocess.Popen to a pseudo terminal (pty) made with pty.openempty and
> opened with os.fdopen. I noticed that we kept getting a bunch of extra new
> line characters.
Mixing subprocess and explicit select() looks a bit odd to me. Perhaps you
should do it completely without subprocess. Did you consider pexpect?
> This is all using python 2.6.4 in a centos6 environment.
>
> After some investigation I realised we needed to use universal_newline
> support so I enabled it for the Popen and specified the mode in the fdopen
> to be rU. Things still seemed to be coming out wrong so I wrote up a test
> program boiling it down to the simplest cases (which is at the end of this
> message). The output I was testing was this:
>
> Fake\r\nData\r\n
> as seen through hexdump -C:
>
>> hexdump -C output.txt
> 46 61 6b 65 0d 0a 44 61 74 61 0d 0a |Fake..Data..|
> 000c
>
> Now if I do a simple subprocess.Popen and set the stdout to
> subprocess.PIPE, then do p.stdout.read() I get the correct output of
>
> Fake\nData\n
>
> When do the Popen attached to a pty I end up with
>
> Fake\n\nData\n\n
>
> Does anyone know why the newline conversion would be incorrect, and what I
> could do to fix it? In fact if anyone even has any pointers to where this
> might be going wrong I'd be very helpful, I've done hours of fiddling with
> this and googling to no avail.
>
> One liner to generate the test data:
>
> python -c 'f = open("output.txt", "w"); f.write("Fake\r\nData\r\n");
> f.close()'
>
> Test script:
>
> #!/usr/bin/env python2.6.4
> import os
> import pty
> import subprocess
> import select
> import fcntl
>
> class TestRead(object):
>
> def __init__(self):
> super(TestRead, self).__init__()
> self.outputPipe()
> self.outputPty()
>
> def outputPipe(self):
> p1 = subprocess.Popen(
> ("/bin/cat", "output.txt"),
> stdout=subprocess.PIPE,
> universal_newlines=True
> )
> print "1: %r" % p1.stdout.read()
>
> def outputPty(self):
> outMaster, outSlave = pty.openpty()
> fcntl.fcntl(outMaster, fcntl.F_SETFL, os.O_NONBLOCK)
>
> p2 = subprocess.Popen(
> ("/bin/cat", "output.txt"),
> stdout=outSlave,
> universal_newlines=True
> )
>
> with os.fdopen(outMaster, 'rU') as pty_stdout:
> while True:
> try:
> rfds, _, _ = select.select([pty_stdout], [], [], 0.1)
> break
> except select.error:
> continue
>
> for fd in rfds:
> buf = pty_stdout.read()
> print "2: %r" % buf
>
> if __name__ == "__main__":
> t = TestRead()
The "universal newlines" translation happens on the python level whereas the
subprocesses communicate via OS means (pipes). Your pty gets "\r\n", leaves
"\r" as is and replaces "\n" with "\r\n". You end up with "\r\r\n" which is
interpreted by "universal newlines" mode as a Mac newline followed by a DOS
newline.
I see two approaches to fix the problem:
(1) Add an intermediate step to change newlines explicitly:
p = subprocess.Popen(
["/bin/cat", "output.txt"],
stdout=subprocess.PIPE
)
q = subprocess.Popen(
#["dos2unix"],
["python", "-c", "import sys, os;
sys.stdout.writelines(os.fdopen(sys.stdin.fileno(), 'rU'))"],
stdin=p.stdout,
stdout=outSlave)
(2) Fiddle with terminal options, e. g.
attrs = termios.tcgetattr(outSlave)
attrs[1] = attrs[1] & (~termios.ONLCR) | termios.ONLRET
termios.tcsetattr(outSlave, termios.TCSANOW, attrs)
p = subprocess.Popen(
("/bin/cat", "output.txt"),
stdout=outSlave,
)
Disclaimer: I found this by try-and-error, so it may not be the "proper"
way.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On 20Jun2013 15:33, Oscar Benjamin wrote: | On 20 June 2013 04:11, Cameron Simpson wrote: | > I use vi/vim and it both shows the matching bracket when the cursor | > is on one and also have a keystroke to bounce the curser between | > this bracket and the matching one. | > | > If you suspect you failed to close a bracket, one approach is to | > go _below_ the syntax error (or right on it) and type a closing | > bracket. Then see where the editor thinks the opening one is. | | I use this technique sometimes and it works if the unclosed bracket is | still in view. Standing on a bracket, the '%' key jumps to the matching bracket. No need for it to be in view. Cheers, -- Cameron Simpson "Vy can't ve chust climb?" - John Salathe -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with the "for" loop syntax
On 20Jun2013 13:55, Neil Cerutti wrote: | On 2013-06-20, Joshua Landau wrote: | > On 20 June 2013 04:11, Cameron Simpson wrote: | >> Also, opening-and-not-closing a set of brackets is almost the | >> only way in Python to make this kind of error (syntax at one | >> line, actual mistake far before). | >> | >> See if your editor has a show-the-matching-bracket mode. | >> If you suspect you failed to close a bracket, one approach is | >> to go _below_ the syntax error (or right on it) and type a | >> closing bracket. Then see where the editor thinks the opening | >> one is. | > | > Thanks for that, that's quite an ingenious technique. | | The auto-indent feature of Vim catches this type of syntax error, | and I imagine other good autoindent support will do the same. Interesting. I use autoindent but grew up with it for prose. I hadn't realised vim's support inderstaood python indentation. I'll have to pay more attention... -- Cameron Simpson Do I have it all? Yes. Do I want more? Yeah, sure.- Demi Moore -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote:
> In article
> <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>,
> rusi wrote:
>
>> > > def f(a, L=[]):
>> > > L.append(a)
>> > > return L
>
>> Every language has gotchas. This is one of python's.
>
> One of our pre-interview screening questions for Python programmers at
> Songza is about this. I haven't been keeping careful statistics, but
> I'd guess only about 50% of the candidates get this right.
What exactly is the question? Because it's not always a bug to use a
mutable default, there are good uses for it:
def func(arg, cache={}):
...
Now you can pass your own cache as an argument, otherwise the function
will use the default. The default cache is mutable, and so will remember
values from one invocation to the next.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
In article <51c39b88$0$2$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > On Thu, 20 Jun 2013 09:19:48 -0400, Roy Smith wrote: > > > In article > > <447dd1c6-1bb2-4276-a109-78d7a067b...@d8g2000pbe.googlegroups.com>, > > rusi wrote: > > > >> > > def f(a, L=[]): > >> > > Â Â L.append(a) > >> > > Â Â return L > > > >> Every language has gotchas. This is one of python's. > > > > One of our pre-interview screening questions for Python programmers at > > Songza is about this. I haven't been keeping careful statistics, but > > I'd guess only about 50% of the candidates get this right. > > > What exactly is the question? Because it's not always a bug to use a > mutable default, there are good uses for it: It's a screening question; I'd rather not reveal all the details (it's really annoying when you find your screening questions posted to stack overflow). But, yes, I understand that there are good uses. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 21/06/2013 4:07 AM, Rick Johnson wrote: Okay. So now you are admitting the problem. That is a good start. Thanks for being honest. If you think mutable default arguments is a "problem", then you don't really understand Python. The only "gotcha" here is in people's heads. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote: > On Thursday, June 20, 2013 10:38:34 AM UTC-5, Chris Angelico wrote: >> Function defaults in Python, being implemented as attributes on the >> function object, are very similar in nature to static variables in C. > > Oh wait a minute. i think it's becoming clear to me now! If only that were true, but I fear that you're just looking for an argument. > Python functions are objects that take arguments, of which (the > arguments) are then converted to attributes of the function object. Arguments in general are *not* converted to attributes. If you call a function func(x=1, y=2), arguments 1 and 2 are not stored as attributes anywhere. That would be silly, since 1 and 2 become local variables and there is no point in storing them for later use since they don't get used later. Only default values for parameters are stored for later use. They have to be stored *somewhere*, and Python chooses to store them as an attribute of the function object, where they can be easily inspected, rather than by storing them inside some undocumented and hidden location locked up in a binary blob. Even if Python chose late binding instead of early binding for function defaults, the default would *still* need to be stored somewhere. The only difference is that with early binding, the default value is calculated once, and the object stored, while with late binding the default value is re-calculated over and over again, every time it is needed, and a piece of code that calculates the default value is stored. > Ah-Ha! Urm, but wait! We already have a method to define Objects. Heck, > I can even create my own callable objects if i want! [snip] Yes, you can create callable objects by defining a __call__ method. That's okay. It is pure slander, invented by Perl programmers, that Python gives you "only one way to do it". Python has functions for 99% of your subroutine needs, and for more complex cases where your subroutine needs to store permanent data and make them available to the caller, you have class-based callables. But really, using a class-based callable is a PITA. You have to define a class, write an __init__ method, write a __call__ method, instantiate the class, store the instance, and call it. 99% of the time a function will do the job more easily, especially now that Python supports closures. [...] > But then, i can even do it WITHOUT creating an object definition: > > py> mutable = [] > py> def expandMutable(arg): > ... mutable.append(arg) > ... [...] The biggest, most obvious problem with the expandMutable approach is that it relies on a global variable. I find it implausible that you, an experienced programmer, is unaware of the dangers of global variables. "Global variables considered harmful" has been a well-known principle of programming dating back to the 1970s. > ANY of those approaches are much less confusing than the current flaw Confusing for whom? Beginners, who don't know the first thing about Python? Programmers who are experienced with some other language but have no clue about what these weird __init__ and __call__ methods do? Programmers with 40 years experience who don't know anything about object- oriented code? People who have been immersed in Python coding for 15 years? Every feature is confusing to *some* people and not others. > and do not violate the least astonishment law.. That's a misuse of the Principle of Least Astonishment. Not just a misuse, but in fact you've got it backwards: late binding of default variables would violate the principle of least astonishment. Python functions are created *once*, when defined. The cost of building the function -- compiling the source code to byte code, assembling the pieces into a function object, binding it to a name -- happens once and once only, not every time you call the function. So it is reasonable to expect that since the function is defined once, so are any default arguments. There are two obvious arguments against late binding: efficiency, and consistency. Late binding is less efficient: if the code that defines the default is expensive, you have to pay that cost once, that can't be avoiding. But late binding makes you pay it again and again and again: def f(arg, value=time.sleep(100)+5): # simulate an expensive default ... I have no doubt that if Python recalculated the default every time, you would be arguing that this is surprising and painful and that Python ought to calculate the value once and cache it somewhere. The other gotcha with late binding is that because the default is recalculated each time, it can surprise you by changing unexpectedly: def f(arg, value=x+5): ... If the value of x changes, so does the value of the default. This may surprise you. (It would certainly surprise me.) > I'm quite Okay with > Python functions being first class objects, however, i am not okay with > violating t
Re: Does upgrade from 2.7.3 to 2.7.5 require uninstall?
On 6/20/2013 2:44 PM, Alister wrote: On Thu, 20 Jun 2013 11:35:49 -0700, Wanderer wrote: Do I need to uninstall Python 2.7.3 before installing Python 2.7.5? Thanks that will depend on your operating system an possibly the variety of python "Python 2.7.3' and 'Python 2.7.5' are by trademark PSF CPython implementations of the Python 2.7 language. The Windows installers *replace* previous micro releases because the new bugfix release is presumed to be better than any before. When that turns out to be sufficiently false, there is a new bugfix release as soon as possible to remove the regressions. Hence 2.7.4 was quickly replaced by 2.7.5 (and same for recent 3.2 and 3.3 releases). (Such regressions, as with any bug, expose deficiencies in the test suite, which also get corrected.) I presume that *nix package managers also replace, but have not used them. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, 20 Jun 2013 11:57:34 -0600, Ian Kelly wrote: > Additionally, with late-binding semantics the default values would no > longer be default *values*. They would be initialization code instead, > which sort of flies in the face of the idea that late-binding would > somehow be better for functional programming -- if the default > expressions have no side effects and since they don't depend on the > function arguments, why should they need to run more than once? If the > goal is indeed to make the the functions more functional, then the > proper solution would be to keep the binding early but just disallow > mutable defaults altogether -- which is tricky to achieve in Python, so > we simply emulate it with the advice "don't use mutable function > defaults". Well said! At the risk of having twice as many gotchas, and at making the implementation become even more complex, I would very slightly lean towards allowing some sort of syntactic sugar for late binding default values just to shut people up about this issue. Here's my syntax plucked out of thin air: def func(arg, x=expression, !y=expression): ... where y=expression is late-bound, and the above is compiled to: def func(arg, x=expression, y=None): if y is None: y = expression ... Then Ranting Rick can bitch and moan about how this violates "Explicit is better than implicit". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 2013-06-21 01:08, Steven D'Aprano wrote: > Here's my syntax plucked out of thin air: > > def func(arg, x=expression, !y=expression): > ... > > where y=expression is late-bound, and the above is compiled to: > > def func(arg, x=expression, y=None): > if y is None: > y = expression > ... I think it would have to translate to something like _temp_semaphore = object() def func(arg, x=expression, y=_temp_semaphore): if y is _temp_semaphore: y = expression ... because there are times you want to be able to pass None as a legit value in such a case (speaking from the trenches after getting stung by exactly that case on multiple occasions). -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, 20 Jun 2013 07:49:37 -0700, Rick Johnson wrote: > When the subroutine is completed, all inputs and local variables are > expected to be destroyed. If the programmer wants a return value, he > need simply ask. Data persistence is not a function of subroutines! > Finally, a subroutine should never have side effects UNLESS the > programmer explicitly ask for a side effect. Correct. And by using a default value, you are explicitly asking for a side-effect, namely, "use this object as the default" (not, "use this expression, and re-evaluate it at call-time"). That some people do not comprehend the *consequences* of doing so is not Python's fault, any more that it is Python's fault when people write: a = b = [] a.append(1) and then are surprised that b is no longer empty. That doesn't happen with x = y = 0 x += 1 therefore Python is buggy, yes? No. In short, your invalid understanding of Python's execution model is your lack of knowledge, not a bug in Python to be fixed. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Finding all instances of a string in an XML file
I have XML which looks like:
The "Property X" string appears twice times and I want to output the "path"
that leads to all such appearances. In this case the output would be:
LEVEL_1 {}, LEVEL_2 {"ATTR": "hello"}, ATTRIBUTE {"NAME": "Property X",
"VALUE": "2"}
LEVEL_1 {}, LEVEL_2 {"ATTR": "goodbye"}, LEVEL_3 {"ATTR": "aloha"},
ATTRIBUTE {"NAME": "Property X", "VALUE": "3"}
My actual XML file is 2000 lines and contains up to 8 levels of nesting.
I have tried this so far (partial code, using the xml.etree.ElementTree
module):
def get_path(data_dictionary, val, path):
for node in data_dictionary[CHILDREN]:
if node[CHILDREN]:
if not path or node[TAG] != path[-1]:
path.append(node[TAG])
print(CR + "recursing ...")
get_path(node, val, path)
else:
for k,v in node[ATTRIB].items():
if v == val:
print("path- ",path)
print(" " + node[TAG] + " " + str(node[ATTRIB]))
I'm really not even close to getting the output I am looking for.
Python 3.2.2.
Thank you.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
In article , Tim Chase wrote: > On 2013-06-21 01:08, Steven D'Aprano wrote: > > Here's my syntax plucked out of thin air: > > > > def func(arg, x=expression, !y=expression): > > ... > > > > where y=expression is late-bound, and the above is compiled to: > > > > def func(arg, x=expression, y=None): > > if y is None: > > y = expression > > ... > > I think it would have to translate to something like > > _temp_semaphore = object() > def func(arg, x=expression, y=_temp_semaphore): > if y is _temp_semaphore: > y = expression > > ... > > because there are times you want to be able to pass None as a legit > value in such a case (speaking from the trenches after getting stung > by exactly that case on multiple occasions). You can go around and around on that one. Whatever distinguished value you set aside to mean "no argument passed", somebody will come up with a use case for why they might want to pass that as a real value. If you really want to avoid then, then you need to go to something like: def func(arg, **kwargs): if 'x' not in kwargs: kwargs['x'] = expression and so on. But that's klunky enough, I'm willing to accept the in-band signalling consequences of using None as a sentinel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On 2013-06-20 21:40, Roy Smith wrote: > In article , > Tim Chase wrote: > > > On 2013-06-21 01:08, Steven D'Aprano wrote: > > > Here's my syntax plucked out of thin air: > > > > > > def func(arg, x=expression, !y=expression): > > > ... > > > > > > where y=expression is late-bound, and the above is compiled to: > > > > > > def func(arg, x=expression, y=None): > > > if y is None: > > > y = expression > > > ... > > > > I think it would have to translate to something like > > > > _temp_semaphore = object() > > def func(arg, x=expression, y=_temp_semaphore): > > if y is _temp_semaphore: > > y = expression > > > > ... > > You can go around and around on that one. Whatever distinguished > value you set aside to mean "no argument passed", somebody will > come up with a use case for why they might want to pass that as a > real value. That's why I suggested using an "is" test against a custom/local(ish) semaphore instance that is only used for the particular invocation in which the "def" statement occurs. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
rusi於 2013年6月21日星期五UTC+8上午1時12分01秒寫道： > You know Rick, you are good at python, you are better at polemics. > > If only you would cut the crap I would (be able to) agree with you. > > See below > > > > On Jun 20, 7:49 pm, Rick Johnson wrote: > > > On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote: > > > > Every language has gotchas. This is one of python's. > > > > > > So are we purposely injecting illogic into our language just > > > to be part of some "cool crowd" of programming languages with > > > gotchas. > > > > > > "You thought intuitiveness was a virtue? Haha, we gotcha!" > > > > > > Python (and all the other 'cool' languages) dont have gotchas because > > someone malevolently put them there. > > In most cases, the problem is seen too late and the cost of changing > > entrenched code too great. > > Or the problem is clear, the solution is not etc etc. > > > > > > > > Or maybe this is reminiscent of the fraternity hazing rituals > > > of days gone by: > > > > > > *POP* > > > "Thank you Sir, may i have another?" > > > > > > > If you are a beginning python programmer, really the best > > > > answer is: Just dont do it! Dont do what? Dont use > > > > mutable arguments as function defaults. Once you cross the > > > > noob stage you can check that its a standard gotcha: Just > > > > run a search for 'python gotcha default []' > > > > > > > And when you feel that you need to, use Steven's trick: > > > > use a immutable indicator 'None' for the mutable []. Once > > > > you cross the noob stage you can check that its a standard > > > > gotcha: Just run a search for 'python gotcha default []' > > > > Its even been discussed repeatedly on the python-ideas > > > > list > > > > > > Your attempting to excuse an inexcusable language flaw by > > > pointing out that the effects of the flaw can be avoided by > > > using a workaround. And, to add insult to injury, you > > > provide no good reason for the flaw to exist: > > > > > > "Just do x, y, and z and shut up. Yes we made a mistake > > > but we are not about to admit our mistake and the onerous > > > will be on all the noobs to re-invent the workaround each > > > time" > > > > > > To me that is unacceptable. > > > > > > > Heres a correction suggestion: [...] Here's Terry Reedy's > > > > nicely explaining the 'why-of-the-how' : [...] FWIW here > > > > is a conceptual/philosophical explanation of your > > > > confusion: There are 2 fundamental ways for approaching > > > > the programming task -- functional and imperative. > > > > > > All these "explanations" ignore a fundamental fact about > > > subroutines[1]. > > > > > > > > A call to a subroutine should exists as a unique transaction > > > within the entire program. It is expected to optionally take > > > inputs, and optionally return an output (depending on the > > > definition). > > > > > > When the subroutine is completed, all inputs and local > > > variables are expected to be destroyed. If the programmer > > > wants a return value, he need simply ask. Data persistence > > > is not a function of subroutines! Finally, a subroutine > > > should never have side effects UNLESS the programmer > > > explicitly ask for a side effect. > > > > > > However, the Python flaw of allowing mutable sequence > > > arguments to persist between successive calls of a > > > subroutine is breaking the entire definition of a > > > subroutine, and for what noble purpose i ask? What purpose > > > is SO important that you change a well established interface > > > in a totally unintuitive manner? > > > > > > If your answer is that recursion is easier, then i say that > > > is foolish because a programmer can keep a reference > > > to a mutable sequence OUTSIDE the subroutine and you can > > > save the "gotchas" for Guido's next birthday party. > > > > > > [1]:http://en.wikipedia.org/wiki/Subroutine > > > > > > You are saying in different language what I said: Functional > > programming is a good idea, imperative programming is a bad idea. > > From the invention of subroutines (ie 50 years) PL designers are > > hearing this truth but somehow or other fail to listen; for more > > details see > http://blog.languager.org/2012/11/imperative-programming-lessons-not.html Well, that was the story of the expensive memory era.the In 198X -2000 the auto GC of LISP was beaten by practical engineers using C, C++, PASCAL, and object pascal. But now it is different in 201X. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thu, 20 Jun 2013 10:12:01 -0700, rusi wrote: > Python (and all the other 'cool' languages) dont have gotchas because > someone malevolently put them there. > In most cases, the problem is seen too late and the cost of changing > entrenched code too great. > Or the problem is clear, the solution is not etc etc. And sometimes the gotcha is unavoidably in the nature of the problem. This is remarkably common in real life, so much so that in English there is even a proverb for it: "You can't have your cake and eat it too", or to put it another way, you can't save your cake for later and eat it now at the same time. For default arguments, you cannot simultaneously have them evaluated once *and* evaluated each time they are needed. Whichever choice you make, there will be situations that lead to a gotcha. Even if Python supported syntax for both, there would be cases where people used the wrong syntax, not knowing any better, and would trip over unexpected behaviour. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't feed the troll...
On Thu, Jun 20, 2013 at 3:41 AM, Antoon Pardon wrote: > There are two problems with your reasoning. The first is that you > are equivocating on "expect". "Expect" can mean you will be surprised > if it doesn't happen but it can also mean you will feel indignant or > disappointed or something similar when it doesn't happen. Perhaps I am, but it doesn't change my argument in any way. When a troll shows up I am not happy about it, but I am not disappointed either, because Trolls Happen. I am disappointed when members of the community act in ways that are detrimental to the community. Better? > The second problem is that I find it a one sided view. If you want > a courteous, respectful, welcoming and enjoyable to participate in > list, shouldn't you also be careful in not encouraging trollish > behaviour? Being courteous to or cooperating with someone behaving > trollishly, is IMO enabling that kind of behaviour and so those > doing so, seem to already throw those priciples out the window because > they are cooperating with the troll who is making this list less > courteous, respectful, welcoming and enjoyable to participate in > for a significant number of people. You'll note that I haven't engaged Nikos at all in some time. That's because I think he's a troll. I think though that those who are continuing to help him do so because they do not think that he is a troll. I am not going to try to thrust my own opinion of who is or is not a troll and who can or cannot be given help upon the list -- that is their opinion, they are entitled to it, and maybe they see something in the exchange that I don't. That is different in my eyes from somebody who does identify Nikos as a troll and then goes on to egg him on anyway, whether it be courteous or belligerent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Default Value
On Thursday, June 20, 2013 7:57:28 PM UTC-5, Steven D'Aprano wrote: > On Thu, 20 Jun 2013 11:05:32 -0700, Rick Johnson wrote: > > Python functions are objects that take arguments, of > > which (the arguments) are then converted to attributes > > of the function object. > Arguments in general are *not* converted to attributes. If > you call a function func(x=1, y=2), arguments 1 and 2 are > not stored as attributes anywhere. That would be silly, > since 1 and 2 become local variables and there is no point > in storing them for later use since they don't get used > later. Only default values for parameters are stored for > later use. Obviously you've lost the ability to recognize sarcasm. :( > They have to be stored *somewhere*, and Python chooses to > store them as an attribute of the function object, where > they can be easily inspected, rather than by storing them > inside some undocumented and hidden location locked up in > a binary blob. I like how that last sentence implicitly argues against an argument i never made, whilst explicitly supporting your argument. But, by all means Steven, proceed. > Even if Python chose late binding instead of early binding > for function defaults, the default would *still* need to > be stored somewhere. No, if your passing in a symbol, then the object it points to must exist *somewhere*. OTOH if your passing in a literal, or an expression, then the subroutine will need to "store" the resulting object. Yes. > The only difference is that with early binding, the > default value is calculated once, and the object stored, > while with late binding the default value is re-calculated > over and over again, every time it is needed, and a piece > of code that calculates the default value is stored. And that is *ONLY* the case using the currently broken system. You're arguing that the status-quo is better because the only alternative would be to re-evaluate the argument every time, when in fact, i provided three code examples that will not require re-evaluation of the mutable and i did so without sacrificing readability. Your argument is weak. > > Ah-Ha! Urm, but wait! We already have a method to define > > Objects. Heck, I can even create my own callable objects > > if i want! > > > [snip] > Yes, you can create callable objects by defining a > __call__ method. That's okay. It is pure slander, invented > by Perl programmers, that Python gives you "only one way > to do it". Python has functions for 99% of your subroutine > needs, and for more complex cases where your subroutine > needs to store permanent data and make them available to > the caller, you have class-based callables. But really, > using a class-based callable is a PITA. You have to define > a class, write an __init__ method, write a __call__ > method, instantiate the class, store the instance, and > call it. Mother of GOD call the authorities because a little girly man has been violated! That mean old Rick and his insistence on readability is causing a pandemic of carpal tunnel and PTSD syndrome. Haul him away, lock him up, and throw away the keys! Psst: That was sarcasm. > > But then, i can even do it WITHOUT creating an object > > definition: > > py> mutable = [] > > py> def expandMutable(arg): > > ... mutable.append(arg) > > ... > [...] > The biggest, most obvious problem with the expandMutable > approach is that it relies on a global variable. I find it > implausible that you, an experienced programmer, is > unaware of the dangers of global variables. I am quite aware of the dangers of globals, and i abhor their use in 99 percent of the cases. But we're talking about Python here *giggle*. The limits of a Python "global" are the module for which it is declared. Plus, this is quite amusing that you are now seemingly preferring the OOP style; how many times have you made snide remarks about my penchant for OOP? I dunno because i stopped counting after i ran out of fingers! Yes i can only count to ten, there, i beat you to the joke. Now we can focus again. > > ANY of those approaches are much less confusing than the > > current flaw > Confusing for whom? Beginners, who don't know the first > thing about Python? Of course programming noobs are going to be confused by this. > Programmers who are experienced with > some other language but have no clue about what these > weird __init__ and __call__ methods do? So now your going to argue that experienced programmers are going to intuit an IMPLICIT and unconventional subroutine data persistence, but they cannot intuit EXPLICIT words like "init" and "call"? Oh Please! > Programmers with > 40 years experience who don't know anything about object- > oriented code? Even those old dogs who refuse to use GUI's and code in the OOP style deserve a little more credit than you are giving them Steven. They might be dinosaurs but they're not stupid. Hardheaded, yes. Incapable of accepting change, yes. But stupid, no no no. > People who have been immerse
Re: Finding all instances of a string in an XML file
Jason Friedman wrote:
> I have XML which looks like:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The "Property X" string appears twice times and I want to output the
> "path"
> that leads to all such appearances. In this case the output would be:
>
> LEVEL_1 {}, LEVEL_2 {"ATTR": "hello"}, ATTRIBUTE {"NAME": "Property X",
> "VALUE": "2"}
> LEVEL_1 {}, LEVEL_2 {"ATTR": "goodbye"}, LEVEL_3 {"ATTR": "aloha"},
> ATTRIBUTE {"NAME": "Property X", "VALUE": "3"}
>
> My actual XML file is 2000 lines and contains up to 8 levels of nesting.
That's still small, so
xml = """
"""
import xml.etree.ElementTree as etree
tree = etree.fromstring(xml)
def walk(elem, path, token):
path += (elem,)
if token in elem.attrib.values():
yield path
for child in elem.getchildren():
for match in walk(child, path, token):
yield match
for path in walk(tree, (), "Property X"):
print(", ".join("{} {}".format(elem.tag, elem.attrib) for elem in path))
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finding all instances of a string in an XML file
Jason Friedman writes: > I have XML which looks like: > > > > > > > > > > > > > > > > > The "Property X" string appears twice times and I want to output the "path" > that leads to all such appearances. You could use "lxml" and its "xpath" support. This is a high end approach: you would use a powerful (and big) infrastructure (but one which could also be of use for other XML applications). There are more elementary approaches as well (e.g. parse the XML into a DOM and provide your own visitor to find the elements you are interested in). -- http://mail.python.org/mailman/listinfo/python-list
Re: Debugging memory leaks
"writeson" wrote in message news:09917103-b35e-4728-8fea-bcb4ce2bd...@googlegroups.com... > Hi all, > > I've written a program using Twisted that uses SqlAlchemy to access a > database using threads.deferToThread(...) and SqlAlchemy's > scoped_session(...). This program runs for a long time, but leaks memory > slowly to the point of needing to be restarted. I don't know that the > SqlAlchemy/threads thing is the problem, but thought I'd make you aware of > it. > > Anyway, my real question is how to go about debugging memory leak problems > in Python, particularly for a long running server process written with > Twisted. I'm not sure how to use heapy or guppy, and objgraph doesn't tell > me enough to locate the problem. If anyone as any suggestions or pointers > it would be very much appreciated! > > Thanks in advance, > Doug You have received lots of good advice, but there is one technique that I have found useful that has not been mentioned. As you are probably aware, one of the main causes of a 'memory leak' in python is an object that is supposed to be garbage collected, but hangs around because there is still a reference pointing to it. You cannot directly confirm that an object has been deleted, because invoking its '__del__' method causes side-effects which can prevent it from being deleted even if it is otherwise ok. However, there is an indirect way of confirming it - a 'DelWatcher' class. I got this idea from a thread on a similar subject in this forum a long time ago. Here is how it works. class DelWatcher: def __init__(self, obj): # do not store a reference to obj - that would create a circular reference # store some attribute that uniquely identifies the 'obj' instance self.name = obj.name print(self.name, 'created') def __del__(self): print(self.name, 'deleted') class MyClass: def __init__(self, ...): [...] self._del = DelWatcher(self) Now you can watch the objects as they are created, and then check that they are deleted when you expect them to be. This can help to pinpoint where the memory leak is occurring. HTH Frank Millman -- http://mail.python.org/mailman/listinfo/python-list
